ラックアタック・イニシャライザー
概要
Rack AttackはRack::Attackとしても知られ、GitLabを保護するためのRuby gemで、スロットリングのカスタマイズやユーザーIPアドレスのブロックが可能です。
大量のリクエストを行うIPアドレスからのリクエストをスロットリングすることで、ブルートフォースパスワード攻撃、スクレイパー、その他の犯罪者を防ぐことができます。 スロットリングだけでは不正なクライアントから保護しきれない場合、Rack AttackはIPホワイトリスト、ブラックリスト、Fail2banスタイルのフィルタリング、トラッキングを提供します。
これらのオプションの使用方法についてはRack Attack READMEを参照してください。
行動
以下の「設定」セクションで説明するように設定すると、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_whitelist
GitLab 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.rb
NET で確認できます。 が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経由でブロックを削除します。