ラックアタック・イニシャライザー

概要

Rack AttackはRack::Attackとしても知られ、GitLabを保護するためのRuby gemで、スロットリングのカスタマイズやユーザーIPアドレスのブロックが可能です。

大量のリクエストを行うIPアドレスからのリクエストをスロットリングすることで、ブルートフォースパスワード攻撃、スクレイパー、その他の犯罪者を防ぐことができます。スロットリングだけでは不正なクライアントから保護しきれない場合、Rack AttackはIPホワイトリスト、ブラックリスト、Fail2banスタイルのフィルタリング、トラッキングを提供します。

これらのオプションの使用方法についてはRack Attack READMEを参照してください。

注：UIで設定されるよりシンプルな制限については、ユーザーおよびIPレート制限を参照してください。

注意：GitLab 11.2以降、Rack Attackはデフォルトで無効になっています。インスタンスが公開されていない場合は、Rack Attackを無効にしておくことをお勧めします。

行動

以下の「設定」セクションで説明するように設定すると、2つの動作が有効になります：

保護されたパスはスロットルされます。
git とコンテナ・レジストリ・リクエストの認証に失敗すると、一時的に IP が禁止されます。

プロテクトパススロットル

GitLab は、保護されたパスでの POST リクエストが IP アドレスあたり毎分 10 リクエストを超えた場合、HTTP ステータスコード429 で応答します。

デフォルトでは、保護されたパスは

/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

このヘッダーはブロックされたリクエストに対する応答に含まれます：

Retry-After: 60

例えば、以下のリクエストは1分間に最大10件に制限されています：

ユーザーサインイン
ユーザー登録（有効な場合）
ユーザーパスワードのリセット

10回リクエストすると、クライアントは再試行できるまで1分待たなければなりません。

git とコンテナレジストリの認証禁止に失敗しました。

GitLabは、1つのIPアドレスから3分間に30回の認証失敗リクエストを受信した場合、HTTPステータスコード403 、1時間応答します。

これは、git リクエストとコンテナレジストリ (/jwt/auth) リクエスト (を合わせたもの) にのみ適用されます。

この限界：

例えば、29の認証失敗リクエストの後に1つの認証成功リクエストがあり、さらに29の認証失敗リクエストがあったとしても、BANのトリガーにはなりません。
gitlab-ci-tokenによって認証されたJWTリクエストには適用されません。

応答ヘッダは提供されません。

設定

オムニバス GitLab

エディタで/etc/gitlab/gitlab.rb を開きます。

以下を追加してください：

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
}

GitLabを再設定します：
```
sudo gitlab-ctl reconfigure
```

以下の設定が可能です：

enabledデフォルトではfalseに設定されています。true に設定すると Rack Attack が有効になります。
ip_whitelistGitLab v12.1以降ではCIDR表記がサポートされています。例えば、["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"].
maxretry指定された時間内にリクエストできる最大回数。
findtime失敗したリクエストがブラックリストに登録されるまでの最大時間 (秒単位)。
bantimeブラックリストに登録されたIPがブロックされる合計時間（秒）。

ソースからのインストール

これらの設定はconfig/initializers/rack_attack.rb. config/initializers/rack_attack.rbNET で確認できます。がconfig/initializers/rack_attack.rb見つからない config/initializers/rack_attack.rb場合は、GitLab インスタンスの保護を有効にするために以下の手順を実行する必要があります：

config/application.rb で以下の行を探し、コメントを外します：
```
config.middleware.use Rack::Attack
```
GitLabを再起動します：
```
sudo service gitlab restart
```

より制限的/緩和的なスロットルルールが必要な場合は、config/initializers/rack_attack.rb を編集し、limit またはperiod の値を変更します。例えば、limit: 3 とperiod: 1.seconds を設定すると、より緩和的なスロットルルールになります (これは 1 秒あたり 3 リクエストを許可します)。また、paths_to_be_protected変数を追加することで、他のパスを保護リストに追加することもできます。これらの設定を変更した場合は、GitLab インスタンスを再起動する必要があります。

Redis経由でRack AttackからブロックされたIPを削除

ブロックされたIPを削除したい場合は、以下の手順に従ってください：

本番ログでブロックされたIPを検索します：

grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log

ブラックリストはRedisに保存されているので、redis-cli：

/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket

<ip> 、ブラックリストに登録されている実際のIPに置き換えて、次の構文を使用してブロックを削除できます：
```
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
```
IPを持つキーが表示されなくなったことを確認します：
```
keys *rack::attack*
```
オプションで、IPが再びブラックリストに載らないようにホワイトリストに追加します（設定を参照）。

トラブルシューティング

ラックの攻撃はロードバランサーのブラックリスト化

すべてのトラフィックがロードバランサから来るように見える場合、Rack Attackはロードバランサをブロックすることがあります。その場合、次のことが必要になります：

nginx[real_ip_trusted_addresses]を設定します。これでユーザーのIPがロードバランサーのIPとして表示されなくなります。
Rack Attack設定でロードバランサーの IP アドレスをホワイトリストに登録します。
GitLabを再設定します：
```
sudo gitlab-ctl reconfigure
```
Redis経由でブロックを削除します。

クリエーションラインについて

私たちクリエーションラインは、日本で最も古く2017年にGitLabサービスの提供を開始し、2022年には「Asia-Pacific Partner of the Year」も獲得。GitLabのサブスクリプション販売やテクニカルサポートだけでなく、GitLab Enterpriseの導入支援やGitLabトレーニングなど多様なサービスを提供し、エンタープライズを中心に豊富な実績を誇ります。GitLabに関するお悩みがありましたら、ぜひお気軽にお問い合わせください。日本で唯一、3度にわたるMVPを獲得したGitLabエバンジェリストをはじめとしたエキスパートチームが、あなたの課題解決をご支援します。