diff options
Diffstat (limited to 'doc/security')
| -rw-r--r-- | doc/security/index.md | 1 | ||||
| -rw-r--r-- | doc/security/reset_user_password.md | 8 | ||||
| -rw-r--r-- | doc/security/responding_to_security_incidents.md | 65 | ||||
| -rw-r--r-- | doc/security/ssh_keys_restrictions.md | 2 | ||||
| -rw-r--r-- | doc/security/two_factor_authentication.md | 2 | ||||
| -rw-r--r-- | doc/security/user_file_uploads.md | 2 |
6 files changed, 73 insertions, 7 deletions
diff --git a/doc/security/index.md b/doc/security/index.md index da3fa761f3f..73ac5028db5 100644 --- a/doc/security/index.md +++ b/doc/security/index.md @@ -26,6 +26,7 @@ type: index - [CI/CD variables](../ci/variables/index.md#cicd-variable-security) - [Token overview](token_overview.md) - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md) +- [Responding to security incidents](responding_to_security_incidents.md) ## Securing your GitLab installation diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md index 1940c5be73a..06934b187c1 100644 --- a/doc/security/reset_user_password.md +++ b/doc/security/reset_user_password.md @@ -74,11 +74,13 @@ If you know the username, user ID, or email address, you can use the Rails conso user = User.find_by(email: 'user@example.com') ``` -1. Reset the password: +1. Reset the password by setting a value for `user.password` and `user.password_confirmation`. For example, to set a new random + password: ```ruby - user.password = 'secret_pass' - user.password_confirmation = 'secret_pass' + new_password = ::User.random_password + user.password = new_password + user.password_confirmation = new_password ``` 1. Optional. Notify the user that an administrator changed their password: diff --git a/doc/security/responding_to_security_incidents.md b/doc/security/responding_to_security_incidents.md new file mode 100644 index 00000000000..b3bce785695 --- /dev/null +++ b/doc/security/responding_to_security_incidents.md @@ -0,0 +1,65 @@ +--- +stage: Manage +group: Authentication and Authorization +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +type: reference, howto +--- + +# Responding to security incidents **(FREE SELF)** + +When a security incident occurs, you should follow the processes defined by your organization. However, you might consider some +additional steps. These suggestions are intended to supplement existing security incident response processes within your organization. + +## Suspected compromised user account + +If you suspect that a user account or bot account has been compromised, consider taking the following steps: + +- [Block the user](../user/admin_area/moderate_users.md#block-a-user) to mitigate any current risk. +- [Review the audit events](../administration/audit_events.md) available to you to identify any suspicious account behavior. For + example: + - Suspicious sign-in events. + - Creation or deletion of personal access tokens, project access tokens, and group access tokens. + - Creation or deletion of SSH or GPG keys. + - Creation, modification, or deletion of two-factor authentication. + - Changes to repositories. + - Changes to group or project configurations. + - Addition or modification of runners. + - Addition or modification of webhooks or Git hooks. +- Reset any credentials the user might have had access to. For example, users with at least the Maintainer role can view protected + [CI/CD variables](../ci/variables/index.md) and [runner registration tokens](token_overview.md#runner-registration-tokens). +- [Reset the user's password](reset_user_password.md). +- Get the user to [enable two factor authentication](../user/profile/account/two_factor_authentication.md) (2FA), and consider [enforcing 2FA at the instance or group level](two_factor_authentication.md) +- After completing an investigation and mitigating impacts, unblock the user. + +## Suspected compromised instance **(FREE SELF)** + +Self-managed GitLab customers and administrators are responsible for: + +- The security of their underlying hosts. +- Keeping GitLab itself up to date. + +It is important to [regularly update GitLab](../policy/maintenance.md), update your operating system and its software, and harden your +hosts in accordance with vendor guidance. + +If you suspect that your GitLab instance has been compromised, consider taking the following steps: + +- [Review the audit events](../administration/audit_events.md) available to you for suspicious account behavior. +- [Review all users](../user/admin_area/moderate_users.md) (including the Administrative root user), and follow the steps in [Suspected compromised user account](#suspected-compromised-user-account) if necessary. +- Review the [Credentials Inventory](../user/admin_area/credentials_inventory.md), if available to you. +- Change any sensitive credentials, variables, tokens, and secrets. For example, those located in instance configuration, database, + CI/CD pipelines, or elsewhere. +- Upgrade to the latest version of GitLab and adopt a plan to upgrade after every security patch release. + +In addition, the suggestions below are common steps taken in incident response plans when servers are compromised by malicious actors. + +WARNING: +Use these suggestions at your own risk. + +- Save any server state and logs to a write-once location, for later investigation. +- Look for unrecognized background processes. +- Check for open ports on the system. +- Rebuild the host from a known-good backup or from scratch, and apply all the latest security patches. +- Review network logs for uncommon traffic. +- Establish network monitoring and network-level controls. +- Restrict inbound and outbound network access to authorized users and servers only. +- Ensure all logs are routed to an independent write-only datastore. diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md index 2e4a737f9aa..03bc0207cf5 100644 --- a/doc/security/ssh_keys_restrictions.md +++ b/doc/security/ssh_keys_restrictions.md @@ -39,7 +39,7 @@ Hovering over this icon tells you why the key is restricted. ## Default settings By default, the GitLab.com and self-managed settings for the -[supported key types](../ssh/index.md#supported-ssh-key-types) are: +[supported key types](../user/ssh.md#supported-ssh-key-types) are: - RSA SSH keys are allowed. - DSA SSH keys are forbidden ([since GitLab 11.0](https://about.gitlab.com/releases/2018/06/22/gitlab-11-0-released/#support-for-dsa-ssh-keys)). diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index cab9f6a957e..ae13881fe6f 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -114,7 +114,7 @@ FLAG: On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. The feature is not ready for production use. This feature flag also affects [session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled). Two-factor authentication can be enforced for Git over SSH operations. However, we recommend using -[ED25519_SK](../ssh/index.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../ssh/index.md#ecdsa_sk-ssh-keys) SSH keys instead. +[ED25519_SK](../user/ssh.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../user/ssh.md#ecdsa_sk-ssh-keys) SSH keys instead. The one-time password (OTP) verification can be done using a command: diff --git a/doc/security/user_file_uploads.md b/doc/security/user_file_uploads.md index e8b0c08e240..dcdd18a9f0b 100644 --- a/doc/security/user_file_uploads.md +++ b/doc/security/user_file_uploads.md @@ -7,8 +7,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w # User File Uploads **(FREE)** -> - In GitLab 14.8 and later, [authorization checks are enforced](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) on media uploads. This change is being [rolled out incrementally](https://gitlab.com/gitlab-org/gitlab/-/issues/352291) on GitLab.com in 14.9. - Images that are attached to issues, merge requests, or comments do not require authentication to be viewed if they are accessed directly by URL. This direct URL contains a random 32-character ID that prevents unauthorized |