☰

ファイアウォールは IP スプーフィング攻撃の軽減にどのように貢献しますか?

tag-icon • tag-icon firewall
ファイアウォールは IP スプーフィング攻撃の軽減にどのように貢献しますか?

特定の IP アドレスからのサーバーへのアクセスのみを許可するファイアウォールを実装できることは理解していますが、TCP パケット内の送信元 IP アドレスを偽装することはできないのでしょうか? これによって、悪意のあるユーザーがサーバーにアクセスするのを実際にどのように防ぐのでしょうか?

答え1

デュードが言ったことはあなたが求めている答えです。

あなたが考えているのは次のようなことだと思います:

SERVER.......................CLIENT
............[FIREWALL].........|
..|............................|
..|_>___[CHECK FOR AUTHORITY]_<_|

この図では、サーバーとクライアントの両方にファイアウォールがあることを前提としています (通常はそうなっています)。

権限が失敗した場合、サーバー/クライアントへの呼び出しは無視されます。

したがって、サーバーの IP が xxx.xxx.xxx.1 で、クライアントが xxx.xxx.xxx.2 で、クライアントが許可なしにコマンドを送信してサーバーにアクセスしようとすると、サーバーのログは次のようになります。xxx.xxx.xxx.2 [認証に失敗しました - 無視]

xxx.xxx.xxx.2 が、サーバーにアクセスする権限を持つ xxx.xxx.xxx.3 として IP を偽装した場合、次のようになります。xxx.xxx.xxx.3 -> コマンド パケットを xxx.xxx.xxx.1 に送信します。xxx.xxx.xxx.1 -> コマンドに応答し、パケットを xxx.xxx.xxx.3 に送信します。

したがって、xxx​​.xxx.xxx.1 は取得されたコマンドを取得できません。

おそらくあなたが考えているのはそれはどのように安全ですか?

実際、ほとんどのサーバーはこのように動作します。

SERVER..............................CLIENT
..|______________[CONNECT]___________<_|
............|
...[TEST AUTHORIZATION]
...........|
......[PASSED]
..........|
...........[SEND CONNECTED RESPONSE]...|

したがって、クライアントが承認され、サーバーに呼び出しを行うと、サーバーは接続応答で応答し、クライアントに返します。クライアントがこの応答を受け取ると、サーバーはこれが正しいクライアントであることを認識します。

答え2

確かに、誰かが IP アドレスを偽装して TCP/IP パケットを送信できますが、パケットは偽装した IP アドレスに送信されるので、応答を受け取ることはできません。したがって、この方法は双方向通信を確立したい人にとっては役に立ちません。

答え3

送信者を偽装するだけでは不十分であり、何か役に立つことを行うには返答も受け取る必要があることが指摘されています。そのため、完全な中間者攻撃を行う必要があります。

ただし、ファイアウォールは通常、送信元 IP に基づいて多くのことを「許可」することはありません。

ファイアウォールは主にブロッキング、ただし認可ではない。

つまり、信頼できない IP は VPN が存在することすら知らず、VPN サービスに接続することもできません。また、簡単に攻撃することもできません。しかし、主なセキュリティ機能は VPN 自体にあります。

IPベースのフィルタリングは安価なので、第一防衛線ファイアウォールでパケットを拒否すると、背後のサービスが対処しなければならない「攻撃」（およびその他のノイズ）が大幅に少なくなります。ファイアウォールに対して DDoS を実行するのは、リクエストを処理するサーバーの CPU ではなく、インターネット接続をいっぱいにする必要があるため、実際のサービスに対して DDoS を実行するよりも困難です。

答え4

確かに、一方向の接続（UDP などのステートレス プロトコルなど）で害を及ぼす可能性はありますが、結局のところ、IP ベースの（安全でない）認証を回避することになります。

TCP

TCP は、接続を確立するには発信元ホストにパケットを送り返す必要があるため、通常は影響を受けません。その仕組みは次のとおりです。

アリスは承認済みホストのリストに含まれています。

  • アリスはボブにSYNパケットを送信します。
  • ボブはアリスにSYN-ACKを返し、アリスが先に進むことができることを知らせる。
  • アリスは ACK パケットを続行し、目的のペイロードを続行します。

チャーリーはサービスに接続しようとします。

  • チャーリーはボブにSYNパケットを送信します。
  • ファイアウォールがパケットをブロックし、ボブは何も受信しません (または、チャーリーがボブに接続しようとしたという警告がログに記録されます)。
  • チャーリーは、自分のリクエストが拒否されたことを知るかもしれないし、知らないかもしれない（ファイアウォールの設定によっては、リクエストがタイムアウトするか、ボブが明示的に ICMP 拒否/到達不能パケットを送信するかのいずれか）。

チャーリーは、アリスがサービスにアクセスできることを何らかの形で知っています。

  • チャーリーはアリスを装ってボブに SYN パケットを送信します。
  • パケットはファイアウォールを通過し、ボブはアリスに SYN-ACK を返します。
  • アリスはボブからの応答を期待していなかったため、RST-ACK (リセット確認応答) または ICMP 到達不能を応答します。
  • チャーリーは、そのリクエストが通ったかどうかさえ知ることはないでしょう。

さて、接続がすでに確立されている場合はどうなるでしょうか? これがシーケンス番号の目的です。シーケンス番号は他者によって予測できず (予測すべきではありません)、両方の当事者はシーケンスが常に 1 ずつ増加することを期待します。

  • 接続が確立されると、双方はランダムなシーケンス番号を選択します。
  • 送信するパケットごとに、シーケンス番号が 1 ずつ増加します。これにより、受信側は間違ったシーケンス番号を持つパケットを拒否し、受け入れられるウィンドウ内のパケットを並べ替えることができます。

チャーリーはシーケンス番号を予測できないため、アリスとボブの間の既存の接続にパケットを「挿入」する方法がなく、チャーリーのパケットはボブによって拒否され、ログに警告または通知が記録される可能性があります。

UDPI

プロトコルが UDP の場合、ピアがインターネット上で偽装パケットを挿入できるため、スプーフィングの影響を非常に受けやすく、そのためトランスポート層ではなくアプリケーション層で認証または暗号化メカニズムを追加する必要があります。

緩和

ISP は IP アドレスのスプーフィングを防止するための対策を追加します。これは、ISP 自身のネットブロックに一致しないすべてのパケットがルーターから出ることを拒否し、ISP のネットブロックに一致するパケットが ISP のネットワークに入ることを拒否するだけの簡単なものかもしれません。

ローカル ネットワークでは、なりすましを防止するメカニズムがあまりないため、なりすましが非常に簡単に実行されてしまうことがよくあります。

関連情報