正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

送信リクエストをフィルタリングする

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

データ損失や漏洩のリスクから保護するため、GitLabの管理者は、送信リクエストフィルタリング制御を使用して、GitLabインスタンスが行う特定の送信リクエストを制限できるようになりました。

安全なWebhookとインテグレーション

メンテナーまたはオーナーロールを持つユーザーは、プロジェクトまたはグループで特定の変更が発生したときにトリガーするWebhookを設定できます。トリガーされると、POST HTTPリクエストがURLに送信されます。Webhookは通常、特定の外部ウェブサービスにデータを送信するように設定されており、そのサービスはデータを適切な方法で処理します。

ただし、Webhookは外部ウェブサービスの代わりに内部ウェブサービスのURLで設定できます。Webhookがトリガーされると、GitLabサーバーまたはそのローカルネットワークで実行されているGitLab以外のウェブサービスが脆弱な状態になる可能性があります。

WebhookリクエストはGitLabサーバー自体によって行われ、認可のためにユーザートークンやリポジトリ固有のトークンではなく、フックごとに単一のオプションのシークレットトークンを使用します:

  • ユーザートークン。
  • リポジトリ固有のトークン。

その結果、これらのリクエストは意図されたよりも広範なアクセス権を持つ可能性があり、Webhookをホストするサーバー上で実行されているすべてへのアクセスを含みます:

  • GitLabサーバー。
  • API自体。
  • 一部のWebhookでは、そのWebhookサーバーのローカルネットワーク内の他のサーバーへのネットワークアクセスが可能であり、これらのサービスが外部から保護され、アクセス不能であっても同様です。

Webhookは、認証を必要としないウェブサービスを使用して、破壊的なコマンドをトリガーするために使用できます。これらのWebhookにより、GitLabサーバーはリソースを削除するエンドポイントに対しPOST HTTPリクエストを行うことができます。

Webhookとインテグレーションからのローカルネットワークへのリクエストを許可する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

脆弱な内部ウェブサービスの悪用を防ぐため、以下のローカルネットワークアドレスへのすべてのWebhookおよびインテグレーションリクエストは許可されていません:

  • 現在のGitLabインスタンスサーバーアドレス。
  • プライベートネットワークアドレス（127.0.0.1、::1、0.0.0.0、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、およびIPv6サイトローカル（ffc0::/10）アドレスを含む）。

これらのアドレスへのアクセスを許可するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開します。
  4. ウェブフックとインテグレーションからローカルネットワークへの要求を許可するチェックボックスを選択します。

システムフックからのローカルネットワークへのリクエストを防ぐ

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

システムフックはデフォルトでローカルネットワークへのリクエストを行うことができます。システムフックからのローカルネットワークへのリクエストを防ぐには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開します。
  4. システムフックからのローカルネットワークへのリクエストを許可するチェックボックスをオフにします。

DNSリバインディング攻撃の保護を実施する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

DNS rebindingは、悪意のあるドメイン名を内部ネットワークリソースに解決することで、ローカルネットワークアクセス制限をバイパスするための手法です。GitLabでは、この攻撃に対する保護がデフォルトで有効になっています。この保護を無効にするには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開します。
  4. DNSリバインディング攻撃の保護を実施するチェックボックスをオフにします。

リクエストをフィルタリングする

前提条件:

  • GitLabインスタンスへの管理者アクセス権が必要です。

多数のリクエストをブロックしてリクエストをフィルタリングするには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開します。
  4. 許可リストで定義されているIPアドレス、IP範囲、およびドメイン名を除くすべてのリクエストをブロックチェックボックスを選択します。

このチェックボックスが選択されている場合でも、以下へのリクエストはブロックされません:

  • Git、GitLab Shell、Gitaly、PostgreSQL、Redisなどのコアサービス。
  • オブジェクトストレージ。
  • 許可リスト内のIPアドレスとドメイン。

この設定が有効になっている場合、GitLabはリリースリンクなどの他のオブジェクトに含まれるURLに対してDNS解決を実行する場合があります。DNS解決が失敗すると、リクエストは失敗します。この問題を解決するには、GitLabがそのホストへの送信接続を行う必要がない場合でも、ホスト名を許可リストに追加します。

この設定は主要なGitLabアプリケーションのみによって尊重されるため、Gitalyなどの他のサービスは依然としてルールに違反するリクエストを行うことができます。さらに、GitLabの一部領域は送信フィルタリングルールを尊重しません。

既存のバグ（#544821）のため、GeoリージョンURLは送信許可リストに追加する必要があります。

特定のIPアドレスとドメインへの送信リクエストを許可する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

特定のIPアドレスとドメインへの送信リクエストを許可するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開します。
  4. フックとインテグレーションがアクセスできる、ローカルIPアドレスとドメイン名に、IPアドレスとドメインを入力します。

エントリは以下のとおりです:

  • セミコロン、カンマ、または空白（改行を含む）で区切ることができます。
  • ホスト名、IPアドレス、IPアドレス範囲など、さまざまな形式を使用できます。IPv6をサポートしています。Unicode文字を含むホスト名には、Internationalized Domain Names in Applications（IDNA）エンコードを使用する必要があります。
  • ポートを含めます。たとえば、127.0.0.1:8080は127.0.0.1上のポート8080への接続のみを許可します。ポートが指定されていない場合、そのIPアドレスまたはドメイン上のすべてのポートが許可されます。IPアドレス範囲は、その範囲内のすべてのIPアドレス上のすべてのポートを許可します。
  • 各エントリは255文字以下で、エントリ数は1000以下です。
  • ワイルドカード（例: *.example.com）を含めないでください。

例:

example.com;gitlab.example.com
127.0.0.1,1:0:0:0:0:0:0:1
127.0.0.0/8 1:0:0:0:0:0:0:0/124
[1:0:0:0:0:0:0:1]:8080
127.0.0.1:8080
example.com:8080

トラブルシューティング

送信リクエストをフィルタリングする際に、以下のイシューに遭遇する可能性があります。

設定されたURLがブロックされる

設定されたURLがブロックされない場合にのみ、許可リストで定義されているIPアドレス、IP範囲、およびドメイン名を除くすべてのリクエストをブロックチェックボックスを選択できます。そうでない場合、URLがブロックされたことを示すエラーメッセージが表示されることがあります。

この設定を有効にできない場合は、以下のいずれかを実行してください:

  • URL設定を無効にします。
  • 別のURLを設定するか、URL設定を空のままにします。
  • 設定されたURLを許可リストに追加します。

パブリックRunnerリリースURLがブロックされる

ほとんどのGitLabインスタンスでは、public_runner_releases_urlがhttps://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-runner/releasesに設定されており、これによりリクエストのフィルタリングが妨げられる可能性があります。

この問題を解決するには、GitLabがGitLab.comからRunnerリリースバージョンデータをフェッチするのを停止するようにGitLabを設定します。

GitLabサブスクリプション管理がブロックされる

リクエストをフィルタリングすると、GitLabサブスクリプション管理がブロックされます。

この問題を回避するには、customers.gitlab.com:443を許可リストに追加します。

GitLabドキュメントがブロックされる

リクエストをフィルタリングすると、Help page documentation base url is blocked: Requests to hosts and IP addresses not on the Allow List are deniedというエラーが表示される場合があります。このエラーを回避するには、次の手順に従います。

  1. エラーメッセージHelp page documentation base url is blockedが表示されなくなるように変更を元に戻します。
  2. docs.gitlab.com、またはリダイレクトヘルプドキュメントページURLを許可リストに追加します。
  3. 変更を保存を選択します。

GitLab Duoの機能がブロックされる

リクエストをフィルタリングすると、GitLab Duo機能を使用しようとしたときに401エラーが表示される場合があります。

このエラーは、GitLabクラウドサーバーへの送信リクエストが許可されていない場合に発生する可能性があります。このエラーを回避するには、次の手順に従います。

  1. https://cloud.gitlab.com:443を許可リストに追加します。
  2. 変更を保存を選択します。
  3. GitLabがクラウドサーバーにアクセスした後、ライセンスを手動で同期します。

詳細については、コード提案またはコード提案（クラシック）のトラブルシューティングドキュメントを参照してください。