ドキュメントに関する現在のご利用体験についてお聞かせください。アンケートにご協力ください。

不正利用と認証失敗の利用停止

一部の保護機能は、リクエストを遅くするのではなく、一定期間クライアントをブロックします。

Gitおよびコンテナレジストリに対する認証失敗による利用停止

デフォルトでは、単一のIPアドレスから1分間に10回の認証失敗リクエストが受信された場合、GitLabはHTTPステータスコード403を1時間返します。これら3つの値はすべて設定可能です。これは、次の組み合わせにのみ適用されます:

この制限は、次のようになります。

利用停止が開始されるまで、認証に成功したリクエストによってリセットされます。たとえば、9回の認証失敗リクエストの後に1回の認証成功リクエストがあり、さらに9回の認証失敗リクエストが続いても、利用停止はトリガーされません。
利用停止が開始されると、認証によって解除することはできません。利用停止は認証情報より先にチェックされるため、利用停止されたIPは、利用停止期間が終了するまで、有効な認証情報であっても403を受け取ります。
gitlab-ci-tokenで認証されたJSON Webトークンリクエストには適用されません。
デフォルトでは無効になっています。

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

レート制限を回避するには、次のことができます:

設定情報については、Linuxパッケージ設定オプションを参照してください。

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

nginx[real_ip_trusted_addresses]を設定します。これにより、ユーザーのIPがロードバランサーのIPとしてリストされるのを防ぎます。
ロードバランサーのIPアドレスを許可リストに追加します。
GitLabを再設定します:
shell
```
sudo gitlab-ctl reconfigure
```

ブロックされたIPを削除するには:

本番環境ログでブロックされたIPを見つけます:
shell
```
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
```
拒否リストはレート制限Redisインスタンスに保存されているため、それに対してredis-cliを開く必要があります。インスタンスを分離しないインストールでは、これがデフォルトのRedisです:
shell
```
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
```
gitlab_rails['redis_rate_limiting_instance']を設定している場合は、代わりにそのインスタンスに接続してください。誤ったインスタンスからキーを削除しても成功したように見え、利用停止は解除されません。
次の構文を使用してブロックを削除できます。<ip>を実際に拒否リストに追加されているIPに置き換えてください:
```
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
```
IPアドレスを持つキーが表示されなくなったことを確認します:
```
keys *rack::attack*
```
デフォルトでは、keysコマンドは無効です。
オプションで、IPを許可リストに追加して、再度拒否リストに追加されるのを防ぎます。

Was this page helpful?