IPアドレスは「偽造するのは簡単」ですか？

Googleの新しいパブリックDNSサービスに関するいくつかのメモを読んでいた：

• パフォーマンスの利点
• セキュリティ上の利点

セキュリティのセクションでこの段落に気付きました：

DNSSEC2プロトコルなど、DNSの脆弱性に対するシステム全体の標準的なソリューションが普遍的に実装されるまで、オープンDNSリゾルバーは、既知の脅威を軽減するためにいくつかの対策を個別に講じる必要があります。多くの手法が提案されています。IETF RFC 4542：ほとんどの概要については、偽造された回答に対するDNSの回復力を高める手段を参照してください。Google Public DNSでは、次のアプローチを実装しており、推奨しています。

• リゾルバ自体への直接的なDoS攻撃から保護するためのマシンリソースのオーバープロビジョニング。IPアドレスは攻撃者が偽造するのは簡単なので、IPアドレスまたはサブネットに基づいてクエリをブロックすることは不可能です。そのような攻撃に対処する唯一の効果的な方法は、単純に負荷を吸収することです。

それは気のめいるような実現です。Stack Overflow / Server Fault / Super Userでも、あらゆる種類の禁止とブロックのベースとしてIPアドレスを頻繁に使用しています。

「才能のある」攻撃者が自分の望むIPアドレスを簡単に使用し、好きなだけユニークな偽のIPアドレスを合成できると考えるのは本当に怖いです！

だから私の質問：

• それは本当にその攻撃者が野生でのIPアドレスを偽造しやすいですか？
• その場合、どのような軽減策が可能ですか？

他の多くの人が述べているように、IPヘッダーは、応答の受信を気にしない限り、簡単に偽造できます。TCPが3ウェイハンドシェイクを必要とするため、これが主にUDPで見られる理由です。注目すべき例外の1つは、SYNフラッドです。これは、TCPを使用して、受信ホストのリソースを拘束しようとします。この場合も、返信が破棄されるため、送信元アドレスは重要ではありません。

攻撃者が送信元アドレスをスプーフィングする能力の特に厄介な副作用は、後方散乱攻撃です。そこ優れた記述であるここでは、しかし、簡単に、それは伝統的なDDoS攻撃の逆です。

1. ボットネットの制御を獲得します。
2. 悪意のあるパケットに同じソースIPアドレスを使用するようにすべてのノードを構成します。このIPアドレスが最終的な被害者になります。
3. すべての制御対象ノードからインターネット上のさまざまなアドレスにパケットを送信します。一般的に開いていないポートをターゲットにするか、既存のトランザクションの一部であると主張する有効なポート（TCP / 80）に接続します。

（3）で述べたいずれかの場合、多くのホストは、ICMP到達不能またはTCPリセットで応答し、悪意のあるパケットの送信元アドレスをターゲットにします。攻撃者は、偽造された送信元IPアドレスを使用して、ネットワーク上に潜在的に何千もの妥協のないマシンを持ち、選択した被害者に対してDDoS攻撃を実行する可能性があります。

軽減の観点から見ると、このリスクは実際にはISP（および特にトランジットではなく顧客アクセスを提供するISP）のみが対処できるリスクです。これを行うには、主に2つの方法があります。

1. イングレスフィルタリング -ネットワークに着信するパケットが、着信インターフェイスの反対側にあるアドレス範囲から送信されるようにします。多くのルーターベンダーは、ルーターのルーティングおよび転送テーブルを使用して、着信パケットの送信元アドレスのネクストホップが着信インターフェイスであることを確認するユニキャストリバースパス転送などの機能を実装しています。これは、ネットワークの最初のレイヤー3ホップ（つまり、デフォルトゲートウェイ）で最適に実行されます。

2. 出力フィルタリング -ネットワークを離れるパケットが、所有するアドレス範囲からのみ送信されるようにします。これは、イングレスフィルタリングの自然な補完であり、基本的に「良い隣人」であることの一部です。ネットワークが悪意のあるトラフィックによって侵害された場合でも、そのトラフィックがピアリングしているネットワークに転送されないようにします。

これらの手法はどちらも最も効果的であり、クライアントがプロバイダーとインターフェイスする「エッジ」または「アクセス」ネットワークで行うと最も簡単に実装できます。複数のパスと非対称ルーティングの複雑さにより、アクセスレイヤーの上に入力/出力フィルタリングを実装することはより困難になります。

これらの手法（特にイングレスフィルタリング）がエンタープライズネットワーク内で大きな効果を発揮するのを見てきました。おそらく、より多くのサービスプロバイダーの経験を持つ人が、インターネット全体でイングレス/エグレスフィルタリングを展開する際の課題についてより多くの洞察を与えることができるでしょう。ハードウェア/ファームウェアのサポートは大きな課題であり、他の国のアップストリームプロバイダーに同様のポリシーの実装を強制することはできないと思います...

攻撃者が実際にIPアドレスを偽造するのは本当に簡単ですか？

確かに、実際に応答を受信することに関心がなければ、好きなソースアドレスを使用して非常に簡単にパケットを送信できます。多くのISPには適切な出力ルールがないため、一般的に偽造したものはすべて配信されます。

攻撃者が実際に双方向通信を必要とする場合、非常に困難になります。双方向通信が必要な場合は、何らかのプロキシを単純に使用する方が簡単になる傾向があります。自分が何をしているのかを知っていれば、これは非常に簡単に設定できます。

サイトは双方向通信を必要とするhttp / httpsを使用しているため、IPアドレスによる人の禁止はSF / SO / SUで中程度に効果的です。

Zordecheの回答の概念実証（ubuntuを使用）：

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

次に、別のコンソールで：

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

はい、些細なことですが、11.10.10.20にアクセスできるか、www.google.comと11.10.10.20の間のスニファーを持っている場合を除き、前述のように返信を受け取りませんパケットのルートを予測できないので、どちらかの端の）。また、スプーファーのゲートウェイ（ISP）は、何らかのIP検査が行われていて、ソースが悪臭を放っていることがわかった場合、そのパケットをドアから出さないかもしれません。

IPアドレスは、一方向のUDPトラフィックに対して簡単に偽造できます。TCPパケットの場合、SYNパケットでハーフオープンTCP接続を取得するためにのみ偽造できます。これは、一種のDOS攻撃の基礎でもあります。ただし、スプーフィングされたアドレスでHTTP接続を偽造することはできません（たとえば、セッションをフィルタリングして同じIPアドレスを使用する場合）。はい、パケットのIPアドレスをスプーフィングできますが、それは特定の種類のサービス拒否攻撃にのみ役立ちます。

GOOGの記事では、明示的にDNSについて議論していました。DNSはUDPパケットとTCPパケットの両方を使用します。UDPのものは偽造できますが、TCPは偽造できません。TCPには3方向のハンドシェイクが必要です。TCPパケットのIPアドレスが偽造された場合、偽造コンピューターは応答を受信せず、接続は失敗します。UDPは、他の回答で述べたように、「火と忘れ」であり、応答通信を必要としません。この理由から、DoS攻撃はほとんど例外なくUDPパケットの形式で行われます。

Stack Overflowおよびファミリサイトのコンテキストでは、Takaun Daikonによって提起された問題は非常に有効です。ISPから新しいIPアドレスを取得する方法はたくさんあります。MACアドレスの変更は明らかに最も簡単で、多くのISPで機能します。さらに、馬鹿げている人の多くは、パブリックプロキシまたはTORを使用している可能性があります。これらのパケットの発信元IPを明確にブロックすると、プロキシまたはTOR終端ノードがブロックされます。

ブロックIPアドレスは有効ですか？地獄はい、そうです。しかし、エラーが発生します。実際に問題の原因ではないIP（プロキシなど）をブロックします。また、IPを変更してブロックを回避する人もいます。後で禁止されたIPを取得するほど不運な人は、SOファミリーのサイトにアクセスできません。しかし、エラー率は小さいはずです。IPの巨大なセットをブロックしていない限り。ただし、1日に1つか2つをブロックしている場合は、問題ないはずです。

ブロックするが、1年などの期間だけ、少し洗練されたスキームを導入することもできます。ネットワークが帯域幅調整または接続制限に対応している場合は、サイトでApache Benchmarksを実行する潅水バッグが非常に限られた帯域幅のケージに入れられるだけのスキームを検討することもできます。

ISPが遅延しているため、IPスプーフィングは継続します。

私のISPは、私が特定のアドレス、または少なくとも私がいるサブネットにいることをよく知っています。それでも、任意の送信元アドレスを使用できます。何故ですか？単に、費用。

あちこちでいくつかのアドレスを偽造しても、ISPの費用はかかりません。私のISPのすべてのユーザーが1時から2時の間に1つのパケットを偽造したとしても、それはまだほとんど目立ちません。ただし、ボットネットが多くのISPの多くのホストから多くのスプーフィングパケットを送信すると、ターゲットマシンまたはネットワークがフォールオーバーします。

経済的な現実は、あなたが攻撃されない限り、なりすましの費用はかかりません。顧客の近くにフィルタリングを実装するには費用がかかり、お金を費やした人は、彼らが良いネットワーク市民であることを知っている以外にほとんど利益を得ません。

UDPとICMPは偽造が最も簡単ですが、TCPも可能です。予測可能なシーケンス番号を使用して悪用する安全でないリモートOSが必要です。シーケンス番号を変更して予測可能にするのは、負荷分散マシンである場合があります。そのため、TCPは可能ですが、より困難です。

DNSスプーフィング防止は、誰かが再帰的なリゾルバーに誤った回答を送信するのを防ぐというセキュリティ側に主に焦点を当てています。UDPのフラッディングの側面は、単一の小さなクエリ（「。」など）がかなり大きな応答を引き起こすこと以外はDNS固有ではありません。したがって、素晴らしい増幅ベクターになります。他にも多くのUDPプロトコルが機能していますが、どこでもDNSが使用されており、攻撃を増幅するために使用するマシンを簡単に見つけることができます。

DNSSECはこれをさらに悪化させ、サイズが4kに達するUDPパケットを使用します。

IPアドレスは、DNSベースの（D）DOS攻撃に関する限り偽造するのは簡単です。これは、通常、UDPパケットが攻撃されて忘れられるためです。HTTPトラフィックの場合はそうではないため、Webサーバーと同じローカルネットワーク上にある必要があります（もちろん、サイトがホストされている場所に応じて完全に可能）、または中間ルーターを制御する必要があります。

誰にでも手紙を送ることができ、封筒に返信先住所を入れない（または間違ったものを入れる）と、世界中のすべての迷惑メールフィルターを雇うことができ、メッセージを開かずにフィルターで除外することはできません（処理） それ。

ただし、送信者が応答を必要とする場合は、返信先アドレスが正しいか、正しいアドレスを取得するためのアプリケーション層メカニズムが必要になります。だから、あなたはナナからの手紙を開いていると思わせることができますが、たとえ手紙の内容をだましていたとしても、ナイジェリアのいくつかの住所にCASHに送られた小切手をナナに送るつもりはありません（ナナがナイジェリア人でない限り） ）。あなたがミドル・イン・ザ・ミドルでもない限り、チャレンジ/レスポンスは効果的な防御です。

データグラムに任意のソースIPアドレスを設定できます。
私のISPがそのようなパケットを荒らしているのかどうかは別の質問です。

これは確かに対処する必要がある現実ですが、根本的な問題は本当に技術的ではありません。悪意を持った人々が悪意のあることをしようとしています。したがって、実際のソリューションも非技術的でなければなりません。

Stackoverflowが行ったことは、第2の防衛線を処理するためのまさに正しいソリューションだと思います：何らかのレベルの「信頼性」を達成する前に、プラットフォームと対話する能力を制限するさまざまな方法で潜在的なスパムユーザーを制限する技術

これらの手法は、サイトの全体的な品質の向上に役立つだけでなく、実際にユーザーがより深く関与し、より信頼できる/信頼できる回答を提供するよう奨励します。

技術的な観点からすると、Googleが提案するように、行うべき最善のことは、追加の負荷を吸収/処理するだけで効率的であることです。

素晴らしい仕事と改善を続けてください！

UDPは、これが簡単な理由の主要な部分です。実際、SkypeとSlingboxは、UDPでIPアドレスを簡単に偽造する機能を利用して、NAT を「パンチ」し、ピアツーピアを可能にします。

TCPは完全なSYN / ACKサイクルを必要とするため、より難しくなりますが、多くのホップでIPアドレスに行くSYNパケットをサーバーにフラッディングし、その過程で膨大な数のルーターを本質的に拘束する可能性があります。

上記のように、プロキシの使用は簡単で、非常に多くのオープンな匿名プロキシが利用可能です。

プロキシを使用しなくても、ファイアウォールのMACアドレスを任意の新しい任意の値に設定し、ケーブルモデムをリセットすると、ISPからまったく新しいIPアドレスが割り当てられます。

そして、それは初心者向けです。IPの禁止を回避する方法は他にもたくさんあります。

その場合、どのような軽減策が可能ですか？

受信側でできることはあまりありません。

偽造者のISPは、顧客が異なるネットワークからのIPをスプーフィングできないように、発信トラフィックをフィルタリングする必要があります。

それはルーター設定のほんの数行ですので、それをしないことの良い言い訳はありません。

攻撃者を追跡する方法はありますが、アップストリームプロバイダーの協力が必要です：http ://www.cymru.com/Documents/dos-and-vip.html

他の人が指摘しているように、UDPは偽造するのはかなり簡単であり、TCPはそれほど多くありません。

望ましい防御策ですが、残念ながら普遍的に展開されていないのは、出力フィルターです。

DSLなどのサービスを実行しているISPの場合、各仮想回線はip verify unicast reverse-path、ソースIPアドレスがその回線にルーティングされることがわかっている範囲内にないパケットをブロックする（またはシスコ以外の同等物で）設定する必要があります。

おそらくVisual Basicを使用して90年代後半にソケットプログラミングを行ったことを思い出すことができ、接続にソースIPを設定できました。私がそれを試したとき、netstat -anは実際のソースIPを示したが、ApacheログはスプーフィングされたIPを示したことを漠然と覚えています。そして私は、ApacheがスプーフィングされたIPをperlモジュールなどに渡していたと思います。