diff options
Diffstat (limited to 'doc/security')
| -rw-r--r-- | doc/security/README.md | 6 | ||||
| -rw-r--r-- | doc/security/information_exclusivity.md | 9 | ||||
| -rw-r--r-- | doc/security/password_length_limits.md | 11 | ||||
| -rw-r--r-- | doc/security/rack_attack.md | 25 | ||||
| -rw-r--r-- | doc/security/webhooks.md | 13 |
5 files changed, 0 insertions, 64 deletions
diff --git a/doc/security/README.md b/doc/security/README.md deleted file mode 100644 index 49dfa6eec76..00000000000 --- a/doc/security/README.md +++ /dev/null @@ -1,6 +0,0 @@ -# Security - -- [Password length limits](password_length_limits.md) -- [Rack attack](rack_attack.md) -- [Web Hooks and insecure internal web services](webhooks.md) -- [Information exclusivity](information_exclusivity.md) diff --git a/doc/security/information_exclusivity.md b/doc/security/information_exclusivity.md deleted file mode 100644 index f8e7fc3fd0e..00000000000 --- a/doc/security/information_exclusivity.md +++ /dev/null @@ -1,9 +0,0 @@ -# Information exclusivity - -Git is a distributed version control system (DVCS). -This means that everyone that 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 masters) 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. -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. -This is an inherent feature of a DVCS and all git management systems have this limitation. -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. diff --git a/doc/security/password_length_limits.md b/doc/security/password_length_limits.md deleted file mode 100644 index d21b26a43e8..00000000000 --- a/doc/security/password_length_limits.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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 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 -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 editor config/initializers/devise_password_length.rb # inspect and edit the new password length limits -``` diff --git a/doc/security/rack_attack.md b/doc/security/rack_attack.md deleted file mode 100644 index 92066997be8..00000000000 --- a/doc/security/rack_attack.md +++ /dev/null @@ -1,25 +0,0 @@ -# Rack attack - -To prevent abusive clients doing damage GitLab uses rack-attack gem. - -If you installed or upgraded GitLab by following the official guides this should be enabled by default. - -If you are missing `config/initializers/rack_attack.rb` the following steps need to be taken in order to enable protection for your GitLab instance: - -1. In config/application.rb find and uncomment the following line: - - config.middleware.use Rack::Attack - -1. Rename `config/initializers/rack_attack.rb.example` to `config/initializers/rack_attack.rb`. - -1. Review the `paths_to_be_protected` and add any other path you need protecting. - -1. Restart GitLab instance. - -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, client will have to wait for the next minute to be able to try again. These settings can be found in `config/initializers/rack_attack.rb` - -If you want more restrictive/relaxed throttle rule change the `limit` or `period` values. For example, more relaxed throttle rule will be if you set limit: 3 and period: 1.second(this will allow 3 requests per second). You can also add other paths to the protected list by adding to `paths_to_be_protected` variable. If you change any of these settings do not forget to restart your GitLab instance. - -In case you find throttling is not enough to protect you against abusive clients, rack-attack gem offers IP whitelisting, blacklisting, Fail2ban style filter and tracking. - -For more information on how to use these options check out [rack-attack README](https://github.com/kickstarter/rack-attack/blob/master/README.md). diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md deleted file mode 100644 index 1e9d33e87c3..00000000000 --- a/doc/security/webhooks.md +++ /dev/null @@ -1,13 +0,0 @@ -# Web Hooks 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 Web Hooks. - -With [Web Hooks](../web_hooks/web_hooks.md), you and your project masters 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 Web Hook 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 web hook is triggered and the POST request is sent. - -Because Web Hook 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, Web Hooks 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, make sure that you are aware of every web service GitLab could potentially have access to, and that all of these are set up to require authentication for every potentially destructive command. Enabling authentication but leaving a default password is not enough.
\ No newline at end of file |