IPスプーフィング攻撃を防ぐ方法

配送経路を確認することと、誰を入れるか決めることは別の作業です。送信元検証と認証には、それぞれの制御が必要です。

受付では、配達物が想定された経路を通って来たかを確認できます。それを受け取る人は、建物に誰を入れるかを別途判断しなければなりません。ネットワークも同じように役割が分かれています。トラフィックがどこから来たと主張しているかを検証し、その後でサービスへのアクセスを認証します。

最初のチェックを送信元の近くに置く

ネットワーク運用者は、顧客の接続にどのアドレス範囲が到着すべきかを把握しています。関係のない送信元を主張するパケットは、先へ進む前にそこで拒否できます。これはBCP 38で説明される送信元検証の方法です。

企業ネットワークでは、外部から到着するトラフィックだけでなく、インターネットへ向けて出ていくトラフィックも確認してください。同じ境界が、あるネットワークからの出口であると同時に、別のネットワークへの入口でもあります。正当に委任された範囲を含め、各接続で想定される送信元を定義し、どこでも一律の規則を適用しないようにします。

範囲チェックは、パケットの背後にいる人を特定しません。許可された範囲内での偽造の余地も残ります。有用な境界制御として扱い、身元を証明する証明書とは考えないでください。

逆引き経路チェックを実際の経路に合わせる

ユニキャスト逆方向経路転送（uRPF）は、パケットの送信元をルーティング情報と比較します。厳格モードでは、受信インターフェースが選択された戻り経路と一致しなければなりません。経路が予測可能な場所では、うまく機能します。

しかし、正当なトラフィックが一方の接続から到着し、最適な戻り経路は別の接続を使うことがあります。非対称ルーティングや複数プロバイダーを使うネットワークで起こる状況です。その場合、厳格なチェックは有効なトラフィックを破棄してしまいます。RFC 3704は、このトレードオフを説明しています。実行可能経路方式は許可された代替経路を考慮し、ルーズチェックは一般に経路が存在するかを尋ねるため、より弱い検査になります。フェイルオーバーを含む実際のトポロジーに照らしてモードを選び、検証してください。

サービスとユーザーを認証する

アドレス制限が役立つ場所では維持しつつ、機密アクセスの身元証明をそれだけに任せないでください。ウェブサービスには適切に検証されたTLSを、管理やネットワークピアには適切に認証されたプロトコルを使います。アカウント認証と権限管理にも、それぞれの役割があります。

TLS 1.3はサーバーを認証し、クライアントも認証でき、アプリケーションのトラフィックを保護します。ただし、すべてのIP送信元アドレスを証明したり、リンクを枯渇させるフラッドを防いだりはしません。暗号化と送信元検証は、異なるものを守ります。

リフレクションの機会を減らす

再帰DNSを運用しているなら、サービスを意図したクライアントに限定してください。これは、ドメインについて一般公開の問い合わせに応答する必要がある権威DNSとは異なります。RFC 5358は、オープンな再帰がサーバーをリフレクターに変えてしまう理由を説明しています。

他の外部公開サービスについても、不要な到達性や過大な応答がないか確認してください。インシデント前に上流のDDoS支援を計画しておきます。トラフィックが到達する前に接続が飽和してしまえば、自分のサーバーでのフィルタリングでは復旧できません。

IPv6でも同じ判断が必要

IPv6へ移行しても、暗号化が自動的に有効になったり、送信元スプーフィングが防がれたりするわけではありません。IPsecには意図的な設定と鍵管理が必要で、両方のIPバージョンで使用できます。IPv6の運用セキュリティガイダンスでは、必要な実際の制御を説明しています。デュアルスタックネットワークでは、両方の経路を評価しテストしてください。

サービスを壊さず保護が機能するか確認する

想定される範囲と経路を記録し、許可されたトラフィックとフェイルオーバーをテストしたうえで、破棄されたパケットとサービスの健全性を調べます。侵入検知システムはパターンを警告できますが、ブロックには防止機能か運用者の対応が必要です。ログは何が起きたかを説明するのに役立つものであり、申告された送信元を身元とみなすものではありません。

一般のインターネット利用者としては、更新、認証済み接続、アカウントセキュリティに重点を置いてください。必要ならプロバイダーに送信元フィルタリングを尋ねましょう。ブラウザーから上流のパケット検証を修正することはできません。背景を知るには、偽造された送信元がどのように機能するか、または各制御がどの攻撃パターンに対応するかを読んでください。