VPN サーバーへの受信アラート：観測点を読む

VPN の背後にあるサーバーは公開サービスのエントリを保持し続けており、人々はそれを見つけ続けている。アラートキューに届くのは一つの発見ではなく、三つの可能性であり、それぞれ意味が異なる。最初の仕事は、露出したサービスと露出した資格情報を切り分けることだ。

観測点を順にたどり、証拠のカテゴリが変わった時点で止める。次の段階は別の問いに答えるからだ。

第一段階：キャプチャが実際に見たもの

パケットキャプチャは、経路上のその地点で見えていたものを記録する。その地点は、後段のフィルタリング判断より前に位置することがある。捕捉されたパケットは、トラフィックがそこまで届いたことを証明する。その後に何が起きたかについては何も証明しない。

インターフェースにも注目する。公開アダプターでのキャプチャとトンネル内でのキャプチャは異なる到達点を記述しており、誤った方を引用したアラートは誤った結論に導く。

Windows はスタックの複数層でもフィルタリングするため、キャプチャツールが二層目、ファイアウォールが三層目という整ったモデルは実製品との接触では通用しない。Windows Filtering Platform の概要はスタック層をまたぐフィルタリングを説明しており、だからこそ観測の順序は仮定ではなく確認によって定める必要がある。

第二段階：ドロップ記録が確定するもの

ドロップ記録は、ポリシーの境界がそのパケットを拒否したと述べる。これは強い証拠だ。同時に、一つの境界での一つの判断しか覆わないという狭い証拠でもある。スタック内の他の何も、それでは説明されない。

タプルとタイムスタンプで相関させる。同じ送信元、同じ宛先、同じポート、同じ秒のうちに。この一致がなければ、別のログにある似た事象は単に別の事象であり、組み合わせれば誰も弁護できない物語になる。

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

閉じたポートとドロップされたパケットは、外から見れば同一に見え、この二つの出力ではまったく異なる。その違いこそが、ローカル記録を読む理由のすべてだ。

第三段階：認証イベントが証明するもの

認証イベントは、ある構成要素が結果を記録するまで要求を処理したと述べる。三段階のうちアイデンティティに触れるのはこれだけであり、その前に何個のパケットが届いたかについては何も語らない。

イベントの実際の文脈を読む。存在しないアカウントへのログオン失敗はスキャンのノイズだ。実在するアカウントへの、もっともらしい送信元からのログオン失敗は別の優先度だ。成功したセッションはまったく別のインシデント区分である。

プロトコル名にも注意する。RPC と RDP は別々のポートを持つ別々のサービスだ。片方だけを監視する検出器は、もう片方をカバーしていない。ネットワーク活動を要約するツールは、どちらがイベントを生んだかを常に示すわけではない。

相関した一つのサンプルはダッシュボードに勝る

許可されたテストを一つ選び、意図的に実行して、端から端まで追跡する。宛先アドレスとインターフェース、真の送信元アドレス、サービスポート、有効なファイアウォールプロファイルと規則、対応するサービス結果に加え、上流のマッピングやクラウドファイアウォールもその連鎖に含めるべきであり、そこでの許可規則が整ったローカル規則を上書きしうるからだ。

次に二つの義務を分ける。管理を VPN 経由のみとするなら、承認済みの復旧経路を保ちながら、公開経路とトンネル経路の両方でそれを強制する。拒否された試行を監視することは、サーバーが何を受け入れるべきかを決めることと同じ作業ではない。

地理規則や無関係なプロトコルのブロックは、観測された入口とそれが受けた判断を見つけることの代わりにはならない。VPN も同様であり、トンネルを通して送信トラフィックを流しても受信の認可については何も記録されない。