HTTP 脆弱性スキャン対策

• HTTP 保護について
• HTTP 保護を有効にする
• 検出ルール
• 詳細設定

RdpGuard は、Microsoft IIS、Apache HTTP Server、nginx のアクセスログを監視し、存在しないページへの反復リクエストや、公開された認証情報・リポジトリファイルの探索など、脆弱性スキャンの兆候を検出します。同じ IP の検出回数がしきい値に達すると、一時的にブロックします。

HTTP 保護は検出ルールで不審なリクエストを識別します。標準ルールから始め、サイトのパスやアプリケーションに合わせて調整してください。リバースプロキシの背後では、元のクライアントを特定・ブロックできるよう、プロキシ設定も確認します。

1. RdpGuard ダッシュボードを開き、監視対象のプロトコルの HTTP をクリックします。

   

   HTTP 保護設定ダイアログが開きます:

   

2. HTTP 保護を有効にするをオンにし、Web サーバーを選択します: Microsoft IIS、Apache HTTP Server、nginx。

3. 追加...をクリックし、アクセスログのフォルダーを選びます。複数追加できます。項目を選択して編集...または削除もできます。

4. 標準ルールを使う場合は、標準の検出ルールを上書きをオフのままにして、保存をクリックします。監視エラーは表示, イベントログを表示で確認してください。

IIS ログフォルダー

C:\inetpub\logs\LogFiles\W3SVC1 など、サイトごとのフォルダーを選びます。W3SVC の後の数字は IIS サイト ID です。親の LogFiles ではなく、ログファイルを含むフォルダーを選んでください。サブフォルダーは検索しません。

IIS の W3C ログを有効にします。標準ルールには Client IP Address (c-ip)、URI Stem (cs-uri-stem)、HTTP Status (sc-status) が必要です。カスタムルールでは、後述する他のフィールドも必要になる場合があります。

Apache アクセスログフォルダー

C:\Apache24\logs など、Apache に設定したフォルダーを選びます。サブフォルダーは検索しないため、個別に追加してください。Common と Combined 形式に対応し、先頭フィールドには数値のクライアント IP が必要です。Referer と User-Agent を使うルールには、これらを含む Combined が必要です。Apache ログのドキュメントを参照してください。

nginx アクセスログフォルダー

Web サーバーに nginx を選び、C:\nginx\logs などのログフォルダーを追加します。サブフォルダーは検索しません。先頭フィールドに数値のクライアント IP を含む、nginx 既定の combined 形式を使ってください。HTTP ルールに対応する全フィールドを含みます。

access_log logs/access.log combined;

nginx 既定の \xXX エスケープは、UTF-8 テキストを含めて処理できます。フィールドの追加・並べ替えを行う独自形式、JSON ログ、圧縮ファイルには対応しません。nginx ログのドキュメントを参照してください。

変更するには標準の検出ルールを上書きをオンにします。カスタムルールは標準ルールに追加されるのではなく、置き換えます。必要な標準ルールを残すか、上書きをオフにして既定値へ戻してください。

1 行に 1 つのルールを入力します。# で始まる行はコメントです。各ルールにはカンマ区切りの条件を記述し、一致に =、除外に != を使います。値は大文字と小文字を区別します。* は任意の文字列、? は任意の 1 文字です。

Uri=/*.zip,Uri!=/download/*

この例は /download/ 配下以外の ZIP ファイルを検出します。行内の全条件が一致 (AND) する必要があり、いずれかのルールに一致 (OR) すると検出します。1 つのリクエストが複数ルールに一致すると、それぞれで数えるため、重複ルールで検出回数が増える場合があります。

対応フィールドと IIS W3C のフィールド名:

• Method - HTTP メソッド。例: GET、POST (cs-method)。
• Uri - クエリ文字列を含まないリクエストパス (cs-uri-stem)。
• Query - 先頭の ? を除いたクエリ文字列 (cs-uri-query)。
• UserName - 認証済みユーザー名 (cs-username)。
• UserAgent - クライアントの User-Agent (cs(User-Agent))。
• Referer - 参照元 URL (cs(Referer))。
• Status - HTTP ステータスコード。例: 404 (sc-status)。

ルールが使用するフィールドをログに含めてください。Apache Common には Referer と User-Agent がないため、これらが必要な場合は Combined を使います。

しきい値

Threshold がない場合、一致するリクエストごとに、そのルールの検出を 1 回数えます。正の整数を指定すると、同じ IP の複数回の一致を 1 回の検出にまとめます。例:

Status=404,Threshold=15

このルールは、同じ IP の HTTP 404 応答 15 回につき 1 回検出します。15 回で即ブロックするものではなく、RdpGuard のブロックしきい値に従います。しきい値が 3 で他のルールの寄与がなく、カウンターがリセットされなければ、45 回の一致が必要です。

しきい値を設けると、偶発的なリンク切れをスキャンと判断するのを避けられます。正規の用途がないパスでは、しきい値なしのルールも選べます。ブロック上限とリセット時間は、ツール, オプションの全般タブで設定します。

ルールの例

以下は現在の標準ルールです。圧縮ファイルと WordPress のチェックはコメントアウトされています。正規の訪問者をブロックしないよう、サイト上でそれらのパスをスキャンとみなす場合だけ有効にしてください。

# Count every 15 HTTP 404 responses as one detection
Status=404,Threshold=15

# Scan for secrets, environment files and repository metadata
Uri=*/.aws*
Uri=*/.env*
Uri=*/.git*
Uri=*/.hg/*
Uri=*/.svn*
Uri=*/.vscode*

# Optional: archive scans (check your legitimate downloads first)
#Uri=/*.bz2
#Uri=/*.tar.gz
#Uri=/*.tgz
#Uri=/*.7z
#Uri=/*.zip,Uri!=/download/*
#Uri=/*.rar

# Optional: WordPress scans (leave disabled if you use WordPress)
#Uri=*/wp-content/*
#Uri=*/wp-admin/*
#Uri=*/wp-includes/*
#Uri=*/wp-json/*
#Uri=*/wp-config*
#Uri=*/wp-login.php*

HTTP 保護の詳細設定...から HTTP の詳細設定を開きます。以下の X-Forwarded-For 設定は IIS ログに適用されます。

X-Forwarded-For フィールドからクライアント IP を読み取る

既定では、IIS ログの Client IP Address (c-ip) を読み取ります。リバースプロキシの背後では、通常はプロキシの IP です。この設定で X-Forwarded-For を使用できます。複数のアドレスがある場合は最初のものを使います。

信頼するプロキシで実際の IP を渡し、クライアントがヘッダーの先頭アドレスを偽装できないよう設定してください。プロキシを迂回できないよう IIS への直接アクセスも制限します。ログ設定はプロキシ経由の IIS 設定を参照してください。

X-Forwarded-For がない場合は接続元 IP を使用

X-Forwarded-For がない場合に c-ip を使います。すべてのリクエストがプロキシ経由の場合は、プロキシ自体をブロックする恐れがあるため、オフにしてください。

OK をクリックし、HTTP 保護設定で保存をクリックして適用します。

Apache では各ログ行の先頭フィールドの IP を使い、これらの X-Forwarded-For 設定は適用しません。たとえば mod_remoteip を使用し、信頼するプロキシ経由の元の IP が先頭に記録されるよう設定してください。

nginx でも先頭フィールド (標準 combined 形式の $remote_addr) を使い、X-Forwarded-For のチェックボックスは適用しません。プロキシ経由では、信頼関係を設定し、このフィールドに元のクライアント IP を記録してください。

X-Forwarded-For を使うリクエストのブロック

X-Forwarded-For はクライアントの特定に使えますが、ブロックする場所は変わりません。接続元がリバースプロキシの場合、クライアント IP に対する Windows ファイアウォールのルールでは、中継された接続を遮断できません。

プロキシ側でクライアントをブロックしてください。IIS では、以下のように IP Address and Domain Restrictions、Proxy Mode、RdpGuard のカスタムアクションを組み合わせる方法もあります。

RdpGuard のカスタムアクションの設定

この例は、IIS サイトの IPv4 拒否項目を追加・削除します。両方のコマンドの Your Web Site を、IIS マネージャーのサイト名に置き換えてください。

1. 必要に応じて IIS の役割サービス IP Address and Domain Restrictions をインストールします。
2. IIS Manager でサイトを選択し、IP Address and Domain Restrictions を開きます。Edit Feature Settings... で Enable Proxy Mode をオンにします。IIS 8.0 以降が必要です。Microsoft の IP Security ドキュメントを参照してください。
3. RdpGuard ダッシュボードを管理者として実行し、ツール, カスタムアクション / 通知から以下の 2 つのアクションを追加します。

IP ブロックアクション

• イベント: IP Blocked
• タスク: Execute program
• パス:C:\Windows\System32\inetsrv\appcmd.exe

引数:

set config "Your Web Site" /section:system.webServer/security/ipSecurity /+"[ipAddress='%IP%',allowed='false']" /commit:apphost

IP ブロック解除アクション

• イベント: IP Unblocked
• タスク: Execute program
• パス:C:\Windows\System32\inetsrv\appcmd.exe

引数:

set config "Your Web Site" /section:system.webServer/security/ipSecurity /-"[ipAddress='%IP%']" /commit:apphost

アクションを保存します。ローカル検出でブロックされた後、サイトに拒否項目が追加され、プロキシ経由のクライアント要求が拒否されることを確認してください。ブロック解除時には、2 つ目のアクションが項目を削除します。

これらは今後のローカル検出による IP BlockedとIP Unblockedを処理します。既にブロック済みのリストや、IP Cloud のみによるブロックは同期しません。