debian-mirror-gitlab/doc/security/rack_attack.md

196 lines
6.4 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
2021-01-29 00:20:46 +05:30
stage: none
group: unassigned
2021-02-22 17:27:13 +05:30
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
2019-09-04 21:01:54 +05:30
type: reference, howto
---
2019-09-30 21:07:59 +05:30
2019-10-12 21:52:04 +05:30
# Rack Attack initializer
2019-09-04 21:01:54 +05:30
[Rack Attack](https://github.com/kickstarter/rack-attack), also known as Rack::Attack, is a Ruby gem
2018-03-17 18:26:18 +05:30
that is meant to protect GitLab with the ability to customize throttling and
2019-09-04 21:01:54 +05:30
to block user IP addresses.
2018-03-17 18:26:18 +05:30
You can prevent brute-force passwords attacks, scrapers, or any other offenders
2019-09-04 21:01:54 +05:30
by throttling requests from IP addresses that are making large volumes of requests.
If you find throttling is not enough to protect you against abusive clients,
Rack Attack offers IP whitelisting, blacklisting, Fail2ban style filtering, and
2018-03-17 18:26:18 +05:30
tracking.
2014-09-02 18:07:02 +05:30
2019-10-12 21:52:04 +05:30
For more information on how to use these options see the [Rack Attack README](https://github.com/kickstarter/rack-attack/blob/master/README.md).
2021-02-22 17:27:13 +05:30
NOTE:
2020-07-28 23:09:34 +05:30
See
2019-10-12 21:52:04 +05:30
[User and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md)
for simpler limits that are configured in the UI.
2021-02-22 17:27:13 +05:30
NOTE:
2020-07-28 23:09:34 +05:30
Starting with GitLab 11.2, Rack Attack is disabled by default. If your
2019-10-12 21:52:04 +05:30
instance is not exposed to the public internet, it is recommended that you leave
Rack Attack disabled.
## Behavior
If set up as described in the [Settings](#settings) section below, two behaviors
2021-02-22 17:27:13 +05:30
are enabled:
2019-10-12 21:52:04 +05:30
2021-02-22 17:27:13 +05:30
- Protected paths are throttled.
- Failed authentications for Git and container registry requests trigger a temporary IP ban.
2019-10-12 21:52:04 +05:30
### Protected paths throttle
GitLab responds with HTTP status code `429` to POST requests at protected paths
that exceed 10 requests per minute per IP address.
By default, protected paths are:
2020-05-24 23:13:21 +05:30
- `/users/password`
- `/users/sign_in`
- `/api/#{API::API.version}/session.json`
- `/api/#{API::API.version}/session`
- `/users`
- `/users/confirmation`
- `/unsubscribes/`
- `/import/github/personal_access_token`
- `/admin/session`
2019-10-12 21:52:04 +05:30
2021-03-08 18:12:59 +05:30
See [User and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md#response-headers) for the headers responded to blocked requests.
2019-10-12 21:52:04 +05:30
For example, the following are limited to a maximum 10 requests per minute:
- User sign-in
- User sign-up (if enabled)
- User password reset
After 10 requests, the client must wait a minute before it can
try again.
### Git and container registry failed authentication ban
GitLab responds with HTTP status code `403` for 1 hour, if 30 failed
authentication requests were received in a 3-minute period from a single IP address.
2018-11-18 11:00:15 +05:30
2019-10-12 21:52:04 +05:30
This applies only to Git requests and container registry (`/jwt/auth`) requests
(combined).
2014-09-02 18:07:02 +05:30
2019-12-04 20:38:33 +05:30
This limit:
- Is reset by requests that authenticate successfully. For example, 29
failed authentication requests followed by 1 successful request, followed by 29
more failed authentication requests would not trigger a ban.
- Does not apply to JWT requests authenticated by `gitlab-ci-token`.
2014-09-02 18:07:02 +05:30
2019-10-12 21:52:04 +05:30
No response headers are provided.
2014-09-02 18:07:02 +05:30
2018-03-17 18:26:18 +05:30
## Settings
2014-09-02 18:07:02 +05:30
2018-03-17 18:26:18 +05:30
**Omnibus GitLab**
2014-09-02 18:07:02 +05:30
2019-09-04 21:01:54 +05:30
1. Open `/etc/gitlab/gitlab.rb` with your editor
2018-03-17 18:26:18 +05:30
1. Add the following:
2014-09-02 18:07:02 +05:30
2019-09-30 21:07:59 +05:30
```ruby
gitlab_rails['rack_attack_git_basic_auth'] = {
'enabled' => true,
'ip_whitelist' => ["127.0.0.1"],
'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
}
```
2014-09-02 18:07:02 +05:30
2019-02-15 15:39:39 +05:30
1. Reconfigure GitLab:
2014-09-02 18:07:02 +05:30
2020-04-08 14:13:33 +05:30
```shell
2019-09-30 21:07:59 +05:30
sudo gitlab-ctl reconfigure
```
2014-09-02 18:07:02 +05:30
2018-03-17 18:26:18 +05:30
The following settings can be configured:
2014-09-02 18:07:02 +05:30
2018-11-18 11:00:15 +05:30
- `enabled`: By default this is set to `false`. Set this to `true` to enable Rack Attack.
2019-09-30 21:07:59 +05:30
- `ip_whitelist`: Whitelist any IPs from being blocked. They must be formatted as strings within a Ruby array.
CIDR notation is supported in GitLab v12.1 and up.
For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"]`.
2018-03-17 18:26:18 +05:30
- `maxretry`: The maximum amount of times a request can be made in the
2019-09-30 21:07:59 +05:30
specified time.
2019-09-04 21:01:54 +05:30
- `findtime`: The maximum amount of time that failed requests can count against an IP
2019-09-30 21:07:59 +05:30
before it's blacklisted (in seconds).
2021-02-22 17:27:13 +05:30
- `bantime`: The total amount of time that a blacklisted IP is blocked (in
2019-09-30 21:07:59 +05:30
seconds).
2018-03-17 18:26:18 +05:30
**Installations from source**
These settings can be found in `config/initializers/rack_attack.rb`. 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:
2019-09-30 21:07:59 +05:30
```ruby
config.middleware.use Rack::Attack
```
2018-03-17 18:26:18 +05:30
1. Restart GitLab:
2020-03-13 15:44:24 +05:30
```shell
2019-09-30 21:07:59 +05:30
sudo service gitlab restart
```
2018-03-17 18:26:18 +05:30
If you want more restrictive/relaxed throttle rules, edit
`config/initializers/rack_attack.rb` and change the `limit` or `period` values.
2021-02-22 17:27:13 +05:30
For example, you can set more relaxed throttle rules with
`limit: 3` and `period: 1.seconds`, allowing 3 requests per second.
2018-03-17 18:26:18 +05:30
You can also add other paths to the protected list by adding to `paths_to_be_protected`
2019-10-12 21:52:04 +05:30
variable. If you change any of these settings you must restart your
2018-03-17 18:26:18 +05:30
GitLab instance.
## Remove blocked IPs from Rack Attack via Redis
In case you want to remove a blocked IP, follow these steps:
1. Find the IPs that have been blocked in the production log:
2020-03-13 15:44:24 +05:30
```shell
2019-09-30 21:07:59 +05:30
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
```
2018-03-17 18:26:18 +05:30
2019-02-15 15:39:39 +05:30
1. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
2018-03-17 18:26:18 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-09-30 21:07:59 +05:30
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
```
2018-03-17 18:26:18 +05:30
2019-02-15 15:39:39 +05:30
1. You can remove the block using the following syntax, replacing `<ip>` with
2018-03-17 18:26:18 +05:30
the actual IP that is blacklisted:
2020-04-22 19:07:51 +05:30
```plaintext
2019-09-30 21:07:59 +05:30
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
```
2018-03-17 18:26:18 +05:30
2019-02-15 15:39:39 +05:30
1. Confirm that the key with the IP no longer shows up:
2018-03-17 18:26:18 +05:30
2020-04-22 19:07:51 +05:30
```plaintext
2019-09-30 21:07:59 +05:30
keys *rack::attack*
```
2018-03-17 18:26:18 +05:30
2019-02-15 15:39:39 +05:30
1. Optionally, add the IP to the whitelist to prevent it from being blacklisted
2018-03-17 18:26:18 +05:30
again (see [settings](#settings)).
## Troubleshooting
### Rack attack is blacklisting the load balancer
Rack Attack may block your load balancer if all traffic appears to come from
2021-02-22 17:27:13 +05:30
the load balancer. In that case, you must:
2018-03-17 18:26:18 +05:30
1. [Configure `nginx[real_ip_trusted_addresses]`](https://docs.gitlab.com/omnibus/settings/nginx.html#configuring-gitlab-trusted_proxies-and-the-nginx-real_ip-module).
2021-02-22 17:27:13 +05:30
This keeps users' IPs from being listed as the load balancer IPs.
2019-02-15 15:39:39 +05:30
1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
1. Reconfigure GitLab:
2018-03-17 18:26:18 +05:30
2020-04-08 14:13:33 +05:30
```shell
2019-09-30 21:07:59 +05:30
sudo gitlab-ctl reconfigure
```
2018-03-17 18:26:18 +05:30
2019-02-15 15:39:39 +05:30
1. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)