レート制限

レート制限は、ウェブアプリケーションのセキュリティと堅牢性を向上させるために使用される一般的な技術です。

たとえば、シンプルなスクリプトは1秒あたり数千ものウェブリクエストを行うことができます。リクエストには、次のものがあります:

• 悪意のあるもの。
• 無関心なもの。
• 単なるバグ。

お使いのアプリケーションやインフラストラクチャでは、その負荷に対応できない場合があります。詳細については、サービス拒否を参照してください。ほとんどのケースは、単一IPアドレスからのリクエストのレート制限によって軽減できます。

ほとんどのブルートフォース攻撃も、レート制限によって同様に軽減されます。

設定可能な制限

これらのレート制限は、インスタンスの管理者エリアで設定できます:

• インポート/エクスポートレート制限
• イシューレート制限
• Noteレート制限
• 保護されたパス
• rawエンドポイントレート制限
• ユーザーおよびIPレート制限
• パッケージレジストリレート制限
• Git LFSレート制限
• Git SSHオペレーションに対するレート制限
• ファイルAPIレート制限
• 非推奨APIレート制限
• GitLab Pagesレート制限
• パイプラインレート制限
• インシデント管理レート制限
• プロジェクトAPIAPIレート制限
• グループAPIレート制限
• ユーザーAPIレート制限
• 組織APIレート制限

これらのレート制限は、ApplicationSettings APIを使用して設定できます:

• オートコンプリートユーザーのレート制限

これらのレート制限は、Railsコンソールを使用して設定できます:

• Webhookのレート制限

Gitおよびコンテナレジストリに対する認証失敗時のBAN

単一のIPアドレスから3分間に30回の認証失敗リクエストを受信した場合、GitLabは1時間HTTPステータス403を返します。これは、以下の組み合わせにのみ適用されます:

• Gitリクエスト。
• コンテナレジストリ（/jwt/auth）リクエスト。

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

• 認証に成功したリクエストでリセットされます。たとえば、29回の認証失敗リクエストの後に1回の成功リクエストが続き、さらに29回の認証失敗リクエストがあったとしても、BANはトリガーされません。
• gitlab-ci-tokenで認証されたJSON Webトークンリクエストには適用されません。
• デフォルトでは無効です。

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

レート制限されないようにするには、次の方法があります:

• 自動パイプラインの実行をずらします。
• 失敗した認証試行のために、指数バックオフと再試行を設定します。
• ドキュメント化されたプロセスとベストプラクティスを使用して、トークンの有効期限を管理します。

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

設定できない制限

リポジトリアーカイブ

リポジトリアーカイブのダウンロードに対するレート制限が利用可能です。この制限は、UIまたはAPIを通じてダウンロードを開始するプロジェクトおよびユーザーに適用されます。

レート制限は、ユーザーごとに1分あたり5リクエストです。

Webhookテスト

Webhookテストにはレート制限があり、Webhook機能の悪用を防ぎます。

レート制限は、ユーザーごとに1分あたり5リクエストです。

ユーザー登録

/users/sign_upエンドポイントには、IPアドレスごとのレート制限があります。これは、エンドポイントの悪用を軽減するためです。たとえば、使用中のユーザー名やメールアドレスの一括検出などです。

レート制限は、IPアドレスごとに1分あたり20コールです。

ユーザー名の更新

ユーザー名を変更できる頻度にはレート制限があります。これは、機能の悪用を軽減するために適用されます。たとえば、使用中のユーザー名を一括検出するなどです。

レート制限は、認証済みユーザーごとに1分あたり10コールです。

ユーザー名の存在確認

選択したユーザー名がすでに使用されているか確認するために登録時に使用される、内部エンドポイント/users/:username/existsにはレート制限があります。これは、使用中のユーザー名の一括検出などの悪用リスクを軽減するためです。

レート制限は、IPアドレスごとに1分あたり20コールです。

プロジェクトジョブAPIエンドポイント

ジョブ取得時のタイムアウトを減らすために、エンドポイントproject/:id/jobsにはレート制限が適用されます。

レート制限は、認証済みユーザーごとにデフォルトで600コールです。レート制限を設定できます。

AIアクション

GraphQL aiActionミューテーションにはレート制限があり、このエンドポイントの悪用を防ぐために適用されます。

レート制限は、認証済みユーザーごとに8時間あたり160コールです。

APIを使用したメンバーの削除

APIエンドポイント/groups/:id/membersまたは/project/:id/membersを使用してプロジェクトまたはグループメンバーを削除するにはレート制限があります。

レート制限は、1分あたり60削除です。

APIを使用したプロジェクトメンバーのリスト表示

グループまたはプロジェクト内のすべてのプロジェクトメンバーをリスト表示するためのレート制限を設定します。以下のエンドポイントでは、デフォルトで1分あたり200リクエストに制限されます:

GET /groups/:id/members/all
GET /projects/:id/members/all

管理者は、プロジェクトエンドポイントのレート制限を設定できます。

リポジトリblobおよびファイルアクセス

特定のリポジトリAPIエンドポイントを介して大きなファイルにアクセスする場合に、レート制限が適用されます。10 MBを超えるファイルの場合、レート制限は、オブジェクトごと、プロジェクトごとに1分あたり5コールです:

• リポジトリblobエンドポイント: /projects/:id/repository/blobs/:sha
• リポジトリファイルエンドポイント: /projects/:id/repository/files/:file_path

これらの制限は、APIを介して大きなリポジトリファイルにアクセスする際の過剰なリソース使用を防ぐのに役立ちます。

通知メール

プロジェクトまたはグループに関連する通知メールにはレート制限があります。

レート制限は、ユーザー、プロジェクト、またはグループごとに24時間あたり1,000通知です。

GitHubインポート

GitHubからのプロジェクトインポートをトリガーするためのレート制限があります。

レート制限は、ユーザーごとに1分あたり6回のトリガーされたインポートです。

FogBugzインポート

FogBugzからのプロジェクトインポートをトリガーするためのレート制限があります。

レート制限は、ユーザーごとに1分あたり1回のトリガーされたインポートです。

コミット差分ファイル

これは、展開されたコミット差分ファイル（/[group]/[project]/-/commit/[:sha]/diff_files?expanded=1）に対するレート制限であり、このエンドポイントの悪用を防ぐために適用されます。

レート制限は、ユーザー（認証済み）またはIPアドレス（未認証）ごとに1分あたり6リクエストです。

変更履歴の生成

エンドポイント:id/repository/changelogには、ユーザー、プロジェクトごとのレート制限があります。これは、エンドポイントの悪用を軽減するためです。レート制限は、GETアクションとPOSTアクションの間で共有されます。

レート制限は、ユーザー、プロジェクトごとに1分あたり5コールです。

トラブルシューティング

Rack Attackがロードバランサーを拒否リストに登録しています

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

1. nginx[real_ip_trusted_addresses]を設定します。これにより、ユーザーのIPがロードバランサーのIPとしてリストされるのを防ぎます。

2. ロードバランサーのIPアドレスを許可リストに登録します。

3. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

Redisを使用してRack AttackからブロックされたIPを削除する

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

1. 本番環境ログでブロックされたIPを見つけます:

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

2. 拒否リストはRedisに保存されているため、redis-cliを開く必要があります:

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

3. ブロックは、<ip>を拒否リストに登録されている実際のIPに置き換えて、以下の構文を使用して削除できます:

   del cache:gitlab:rack::attack:allow2ban:ban:<ip>

4. IPを持つキーが表示されなくなったことを確認します:

   keys *rack::attack*

   デフォルトでは、keysコマンドは無効です。

5. オプションで、IPが再度拒否リストに登録されるのを防ぐために、そのIPを許可リストに追加します。