Commit bf926010 authored by Matt Penna's avatar Matt Penna Committed by Mike Lewis

Various edits to security documentation

Edits to conform with CE epic 1280 SSOT standards, other improvements
parent fc925583
...@@ -13,13 +13,13 @@ authenticated web session, allowing the launching of further attacks. ...@@ -13,13 +13,13 @@ authenticated web session, allowing the launching of further attacks.
## Description ## Description
The TLS Protocol CRIME Vulnerability affects compression over HTTPS, therefore The TLS Protocol CRIME Vulnerability affects systems that use data compression
it warns against using SSL Compression (for example gzip) or SPDY which over HTTPS. Your system might be vulnerable to the CRIME vulnerability if you use
optionally uses compression as well. SSL Compression (for example, gzip) or SPDY (which optionally uses compression).
GitLab supports both gzip and [SPDY][ngx-spdy] and mitigates the CRIME GitLab supports both gzip and [SPDY][ngx-spdy] and mitigates the CRIME
vulnerability by deactivating gzip when HTTPS is enabled. You can see the vulnerability by deactivating gzip when HTTPS is enabled. The sources of the
sources of the files in question: files are here:
- [Source installation NGINX file][source-nginx] - [Source installation NGINX file][source-nginx]
- [Omnibus installation NGINX file][omnibus-nginx] - [Omnibus installation NGINX file][omnibus-nginx]
...@@ -49,8 +49,8 @@ SPDY support earlier than version 4 is advertised. ...@@ -49,8 +49,8 @@ SPDY support earlier than version 4 is advertised.
``` ```
From the report above it is important to note that Nessus is only checking if From the report above it is important to note that Nessus is only checking if
TLS advertises the SPDY protocol earlier than version 4, it does not perform an TLS advertises the SPDY protocol earlier than version 4. It does not perform an
attack nor does it check if compression is enabled. With just this approach, it attack nor does it check if compression is enabled. The Nessus scanner alone
cannot tell that SPDY's compression is disabled and not subject to the CRIME cannot tell that SPDY's compression is disabled and not subject to the CRIME
vulnerability. vulnerability.
...@@ -65,3 +65,15 @@ vulnerability. ...@@ -65,3 +65,15 @@ vulnerability.
[ngx-spdy]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html [ngx-spdy]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html
[nessus]: https://www.tenable.com/plugins/index.php?view=single&id=62565 [nessus]: https://www.tenable.com/plugins/index.php?view=single&id=62565
[wiki-crime]: https://en.wikipedia.org/wiki/CRIME [wiki-crime]: https://en.wikipedia.org/wiki/CRIME
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
--- ---
type: concepts type: concepts
--- ---
# Information exclusivity # Information exclusivity
Git is a distributed version control system (DVCS). Git is a distributed version control system (DVCS). This means that everyone
This means that everyone that works with the source code has a local copy of the complete repository. who works with the source code has a local copy of the complete repository.
In GitLab every project member that is not a guest (so reporters, developers and maintainers) can clone the repository to get a local copy.
After obtaining this local copy the user can upload the full repository anywhere, including another project under their control or another server. In GitLab every project member that is not a guest (reporters, developers, and
The consequence is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code. maintainers) can clone the repository to create a local copy. After obtaining
This is an inherent feature of a DVCS and all git management systems have this limitation. a local copy, the user can upload the full repository anywhere, including to
Obviously you can take steps to prevent unintentional sharing and information destruction, this is why only some people are allowed to invite others and nobody can force push a protected branch. another project that is under their control, or onto another server.
\ No newline at end of file
Therefore, it is impossible to build access controls that prevent the
intentional sharing of source code by users that have access to the source code.
This is an inherent feature of a DVCS. All git management systems have this
limitation.
You can take steps to prevent unintentional sharing and information
destruction. This is the reason why only certain people are allowed to invite
others and why no user can force push a protected branch.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
--- ---
type: reference, howto type: reference, howto
--- ---
# Custom password length limits # Custom password length limits
If you want to enforce longer user passwords you can create an extra Devise initializer with the steps below. If you want to enforce longer user passwords you can create an extra Devise
initializer with the steps below.
If you do not use the `devise_password_length.rb` initializer the password length is set to a minimum of 8 characters in `config/initializers/devise.rb`. If you do not use the `devise_password_length.rb` initializer the password
length is set to a minimum of 8 characters in `config/initializers/devise.rb`.
```bash ```bash
cd /home/git/gitlab cd /home/git/gitlab
sudo -u git -H cp config/initializers/devise_password_length.rb.example config/initializers/devise_password_length.rb sudo -u git -H cp config/initializers/devise_password_length.rb.example config/initializers/devise_password_length.rb
sudo -u git -H editor config/initializers/devise_password_length.rb # inspect and edit the new password length limits sudo -u git -H editor config/initializers/devise_password_length.rb # inspect and edit the new password length limits
``` ```
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: reference, howto
---
# Rack Attack # Rack Attack
Rack Attack, also known as Rack::Attack, is [a rubygem](https://github.com/kickstarter/rack-attack) Rack Attack, also known as Rack::Attack, is [a rubygem](https://github.com/kickstarter/rack-attack)
that is meant to protect GitLab with the ability to customize throttling and that is meant to protect GitLab with the ability to customize throttling and
blocking user IPs. to block user IP addresses.
You can prevent brute-force passwords attacks, scrapers, or any other offenders You can prevent brute-force passwords attacks, scrapers, or any other offenders
by throttling requests from IP addresses making large volumes of requests. by throttling requests from IP addresses that are making large volumes of requests.
In case you find throttling is not enough to protect you against abusive clients, If you find throttling is not enough to protect you against abusive clients,
Rack Attack offers IP whitelisting, blacklisting, Fail2ban style filtering and Rack Attack offers IP whitelisting, blacklisting, Fail2ban style filtering, and
tracking. tracking.
**Note:** Starting with 11.2, Rack Attack is disabled by default. To continue **Note:** Starting with 11.2, Rack Attack is disabled by default. To continue
using this feature, please enable it by [configuring `gitlab.rb` as described in Settings](#settings). using Rack Attack, please enable it by [configuring `gitlab.rb` as described in Settings](#settings).
By default, user sign-in, user sign-up (if enabled), and user password reset is By default, user sign-in, user sign-up (if enabled), and user password reset is
limited to 6 requests per minute. After trying for 6 times, the client will limited to 6 requests per minute. After trying for 6 times, the client will
have to wait for the next minute to be able to try again. have to wait for the next minute to be able to try again.
If you installed or upgraded GitLab by following the [official guides](../install/README.md) If you installed or upgraded GitLab by following the [official guides](../install/README.md),
this should be disabled by default. If your instance is not exposed to any incoming Rack Attack should be disabled by default. If your instance is not exposed to any incoming
connections, it is recommended to leave Rack Attack disabled. connections, it is recommended that you leave Rack Attack disabled.
For more information on how to use these options check out For more information on how to use these options check out
[rack-attack README](https://github.com/kickstarter/rack-attack/blob/master/README.md). [rack-attack README](https://github.com/kickstarter/rack-attack/blob/master/README.md).
...@@ -27,7 +31,7 @@ For more information on how to use these options check out ...@@ -27,7 +31,7 @@ For more information on how to use these options check out
**Omnibus GitLab** **Omnibus GitLab**
1. Open `/etc/gitlab/gitlab.rb` with you editor 1. Open `/etc/gitlab/gitlab.rb` with your editor
1. Add the following: 1. Add the following:
```ruby ```ruby
...@@ -53,7 +57,7 @@ The following settings can be configured: ...@@ -53,7 +57,7 @@ The following settings can be configured:
For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3"]`. For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3"]`.
- `maxretry`: The maximum amount of times a request can be made in the - `maxretry`: The maximum amount of times a request can be made in the
specified time. specified time.
- `findtime`: The maximum amount of time failed requests can count against an IP - `findtime`: The maximum amount of time that failed requests can count against an IP
before it's blacklisted (in seconds). before it's blacklisted (in seconds).
- `bantime`: The total amount of time that a blacklisted IP will be blocked (in - `bantime`: The total amount of time that a blacklisted IP will be blocked (in
seconds). seconds).
......
---
type: howto
---
# How to reset your root password # How to reset your root password
Log into your server with root privileges. Then start a Ruby on Rails console. To reset your root password, first log into your server with root privileges.
Start the console with this command: Start a Ruby on Rails console with this command:
```bash ```bash
gitlab-rails console production gitlab-rails console production
...@@ -38,3 +41,15 @@ user.save! ...@@ -38,3 +41,15 @@ user.save!
``` ```
Exit the console and try to login with your new password. Exit the console and try to login with your new password.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: reference, howto
---
# Restrict allowed SSH key technologies and minimum length # Restrict allowed SSH key technologies and minimum length
`ssh-keygen` allows users to create RSA keys with as few as 768 bits, which `ssh-keygen` allows users to create RSA keys with as few as 768 bits, which
...@@ -25,3 +28,15 @@ An icon will be visible to the user of a restricted key in the SSH keys section ...@@ -25,3 +28,15 @@ An icon will be visible to the user of a restricted key in the SSH keys section
![Restricted SSH key icon](img/ssh_keys_restricted_key_icon.png) ![Restricted SSH key icon](img/ssh_keys_restricted_key_icon.png)
Hovering over this icon will tell you why the key is restricted. Hovering over this icon will tell you why the key is restricted.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: howto
---
# Enforce Two-factor Authentication (2FA) # Enforce Two-factor Authentication (2FA)
Two-factor Authentication (2FA) provides an additional level of security to your Two-factor Authentication (2FA) provides an additional level of security to your
...@@ -55,3 +58,15 @@ sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_EN ...@@ -55,3 +58,15 @@ sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_EN
CAUTION: **Caution:** CAUTION: **Caution:**
This is a permanent and irreversible action. Users will have to This is a permanent and irreversible action. Users will have to
reactivate 2FA from scratch if they want to use it again. reactivate 2FA from scratch if they want to use it again.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: howto
---
# How to unlock a locked user # How to unlock a locked user
Log into your server with root privileges. Then start a Ruby on Rails console. To unlock a locked user, first log into your server with root privileges.
Start a Ruby on Rails console with this command:
Start the console with this command:
```bash ```bash
gitlab-rails console production gitlab-rails console production
...@@ -29,3 +33,15 @@ user.unlock_access! ...@@ -29,3 +33,15 @@ user.unlock_access!
``` ```
Exit the console, the user should now be able to log in again. Exit the console, the user should now be able to log in again.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: howto
---
# User email confirmation at sign-up # User email confirmation at sign-up
GitLab admin can enable email confirmation on sign-up, if you want to confirm all GitLab can be configured to require confirmation of a user's email address when
user emails before they are able to sign-in. the user signs up. When this setting is enabled, the user is unable to sign in until
they confirm their email address.
In the Admin area under **Settings** (`/admin/application_settings`), go to section In the Admin area under **Settings** (`/admin/application_settings`), go to section
**Sign-up Restrictions** and look for **Send confirmation email on sign-up** option. **Sign-up Restrictions** and look for the **Send confirmation email on sign-up** option.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: reference
---
# User File Uploads # User File Uploads
Images attached to issues, merge requests or comments do not require authentication Images that are attached to issues, merge requests, or comments
to be viewed if someone knows the direct URL. This direct URL contains a random do not require authentication to be viewed if they are accessed directly by URL.
32-character ID that prevents unauthorized people from guessing the URL to an This direct URL contains a random 32-character ID that prevents unauthorized
image containing sensitive information. We don't enable authentication because people from guessing the URL for an image, thus there is some protection if an
these images need to be visible in the body of notification emails, which are image contains sensitive information.
often read from email clients that are not authenticated with GitLab, like
Outlook, Apple Mail, or the Mail app on your mobile device.
Note that non-image attachments do require authentication to be viewed. Authentication is not enabled because images must be visible in the body of
notification emails, which are often read from email clients that are not
authenticated with GitLab, such as Outlook, Apple Mail, or the Mail app on your
mobile device.
>**Note:**
Non-image attachments do require authentication to be viewed.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
---
type: concepts, reference, howto
---
# Webhooks and insecure internal web services # Webhooks and insecure internal web services
If you have non-GitLab web services running on your GitLab server or within its local network, these may be vulnerable to exploitation via Webhooks. If you have non-GitLab web services running on your GitLab server or within its
local network, these may be vulnerable to exploitation via Webhooks.
With [Webhooks](../user/project/integrations/webhooks.md), you and your project maintainers and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way. With [Webhooks](../user/project/integrations/webhooks.md), you and your project
maintainers and owners can set up URLs to be triggered when specific things
happen to projects. Normally, these requests are sent to external web services
specifically set up for this purpose, that process the request and its attached
data in some appropriate way.
Things get hairy, however, when a Webhook is set up with a URL that doesn't point to an external, but to an internal service, that may do something completely unintended when the webhook is triggered and the POST request is sent. Things get hairy, however, when a Webhook is set up with a URL that doesn't
point to an external, but to an internal service, that may do something
completely unintended when the webhook is triggered and the POST request is
sent.
Because Webhook requests are made by the GitLab server itself, these have complete access to everything running on the server (`http://localhost:123`) or within the server's local network (`http://192.168.1.12:345`), even if these services are otherwise protected and inaccessible from the outside world. Because Webhook requests are made by the GitLab server itself, these have
complete access to everything running on the server (`http://localhost:123`) or
within the server's local network (`http://192.168.1.12:345`), even if these
services are otherwise protected and inaccessible from the outside world.
If a web service does not require authentication, Webhooks can be used to trigger destructive commands by getting the GitLab server to make POST requests to endpoints like `http://localhost:123/some-resource/delete`. If a web service does not require authentication, Webhooks can be used to
trigger destructive commands by getting the GitLab server to make POST requests
to endpoints like `http://localhost:123/some-resource/delete`.
To prevent this type of exploitation from happening, starting with GitLab 10.6, all Webhook requests to the current GitLab instance server address and/or in a private network will be forbidden by default. That means that all requests made to 127.0.0.1, ::1 and 0.0.0.0, as well as IPv4 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and IPv6 site-local (ffc0::/10) addresses won't be allowed. To prevent this type of exploitation from happening, starting with GitLab 10.6,
all Webhook requests to the current GitLab instance server address and/or in a
private network will be forbidden by default. That means that all requests made
to 127.0.0.1, ::1 and 0.0.0.0, as well as IPv4 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16 and IPv6 site-local (ffc0::/10) addresses won't be allowed.
This behavior can be overridden by enabling the option *"Allow requests to the local network from hooks and services"* in the *"Outbound requests"* section inside the Admin area under **Settings** (`/admin/application_settings/network`): This behavior can be overridden by enabling the option *"Allow requests to the
local network from hooks and services"* in the *"Outbound requests"* section
inside the Admin area under **Settings**
(`/admin/application_settings/network`):
![Outbound requests admin settings](img/outbound_requests_section.png) ![Outbound requests admin settings](img/outbound_requests_section.png)
>**Note:** >**Note:**
*System hooks* are exempt from this protection because they are set up by admins. *System hooks* are exempt from this protection because they are set up by
admins.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment