IPスプーフィング攻撃の種類

求めていないアドレスへ、複数のサービスが返信を送ることがあります。リフレクションは、関係のない受信者へ負荷を向けます。

「スプーフィング」と呼ばれる攻撃のすべてがIPアドレスを変えるわけではなく、偽造アドレスを使うトラフィックだけが洪水のように押し寄せるわけでもありません。インシデントを理解する最も明確な方法は、二つの問いを立てることです。何の情報が偽造されたのか、そしてトラフィックはどこへ向かったのか。

リフレクション：返信が別の人へ届く

関係のない一人のアドレスを返信先として付けたリクエストを、複数のサービスへ送る場面を想像してください。サービスはその人へ返信します。サービスがリフレクターで、望まない返信を受け取る人が被害者です。

ネットワークでは、サービスが、送信者が申告されたアドレスでトラフィックを受け取れることを事前に確認せず返信すると、偽造された送信元IPによってこの効果が生じることがあります。小さなリクエストが大きな応答を引き起こすなら、リフレクションはトラフィックも増幅します。RFC 5358は、オープンな再帰DNSサーバーがこのように悪用される仕組みを説明しています。リフレクションは返信の方向の問題で、増幅は大きさの問題です。関連していますが、同じものではありません。

直接フラッディング：過剰なトラフィックが標的へ届く

直接フラッドは、接続状態、処理能力、帯域幅を消費させるため、標的そのものへトラフィックを送ります。偽の送信元アドレスを使うフラッドもあります。侵害された端末が実際のアドレスを使って送るものもあります。

「分散型サービス拒否」、つまりDDoSは、複数の送信元から来て可用性を妨げる攻撃を指します。送信元が偽造されていなければならない、という意味ではありません。ボットネットは侵害された端末の集合であり、IPスプーフィングとは別の種類です。偽の送信元を遮断することは助けになりますが、すべてのDDoSトラフィックを止めるわけではありません。

信頼された送信元になりすます

トラフィックが見慣れたアドレスから来たように見えるため、サービスが権限を与えることがあります。偽造された送信元は、その信頼を悪用するうえで関係しますが、利用可能なセッションを自動的に確立するわけではありません。攻撃者はプロトコルの接続確認や、アプリケーションの認証にも直面します。

説明によっては、送信者が交換を観測できる攻撃と「ブラインド」攻撃を区別します。役立つ区別は可視性です。オフパス攻撃者は通常、返信を見ることができませんが、オンパス攻撃者は自分の位置を通過するトラフィックを観測できます。同じローカルネットワークにいることは一つの状況であって、すべてのオンパス攻撃の定義ではありません。誰かがパケットを観測できる場合でも、適切に認証された暗号化は重要です。

ARPスプーフィングとDNSスプーフィングは異なる情報を変える

ARPは、ローカルネットワーク上でIPv4アドレスをリンク層アドレスに結び付けます。偽のARP情報は、ローカル配送を誤った方向へ向ける可能性があります。DNSは名前をアドレスを含むレコードへ対応付けます。偽のDNS応答は、名前解決を誤った方向へ向けることがあります。どちらも、単にIPパケットの送信元フィールドを変更する行為ではありません。

これらの仕組みが一つのインシデントに同時に現れることはありますが、必要な制御は異なります。ローカルネットワークの保護は、偽のARP対応付けに対処します。DNSSECは、信頼チェーンが有効な場合に署名済みDNSデータを検証します。詳しくはRFC 4033を参照してください。送信元フィルタリングは、IPトラフィックがどこから来たと主張しているかを確認します。一つの制御が三つすべての役割を果たすわけではありません。

実際に見えているトラフィックから始める

多数のサービスから求めていない返信が届くなら、リフレクションのパターンが疑われます。直接のリクエストを受けているビジーなサーバーは、別の問題に直面しているかもしれません。意外な名前解決やローカルアドレス対応付けには、それぞれの調査が必要です。ログにあるアドレスは調べるべき証拠であって、人の身元を証明するものではありません。

基本的な説明は、IPスプーフィングが変えるものと変えないものを読んでください。これらの区別を防御に結び付けるには、送信元検証、認証、サービス保護へ進んでください。