Sockstressは、インターネットやその他のTCPベースのネットワーク上でTCP接続を受け入れるサーバーやその他のデバイスを攻撃する方法です。[ 1 ]この方法は、サービスまたはマシン全体をクラッシュさせるためにローカルリソースを枯渇させ、本質的にはサービス拒否攻撃として機能します。
Sockstressは、 Outpost24の故ジャック・C・ルイス氏によって社内で概念実証として開発されました。ルイス氏は、企業セキュリティのためにネットワークをテスト・調査するUnicornscanを使用して異常を発見し、それがSockstressの開発につながりました。[ 2 ]この概念は2008年9月に初めて実証されました。[ 3 ] [ 4 ] [ 5 ] [ 6 ]研究者たちは、攻撃を実演したフィンランドのT2カンファレンスで、より詳細な情報を発表する予定でした。[ 7 ] [ 8 ]彼らは代わりに、ベンダーおよび標準化コミュニティと緊密に協力し、より多くの時間を割くことを選択しました。ブログ記事で、彼らは「私たちはベンダーに、不十分に実装された急いで修正をリリースするよう過度のプレッシャーをかけているわけではありません」と述べています。
sockstressに似た攻撃を実証した概念実証ツールNkiller2が、Phrack ezineでFotis Chantzis(別名ithilgore)によってリリースされました。[ 9 ] Nkiller2はパケット解析技術と仮想状態を使用して完全にステートレスに動作し、TCPの固有のメカニズムであるPersist Timerを悪用することで、最小限のネットワークトラフィックで一般的なDoS攻撃を実行し、無限に延長することができます。
Sockstressは、ユーザーランドTCPソケットストレスフレームワークであり、状態追跡に伴う典型的なオーバーヘッドを発生させることなく、任意の数のオープンソケットを完了することができます。ソケットが確立されると、カウンター、タイマー、メモリプールといった特定の種類のカーネルおよびシステムリソースを標的としたTCP攻撃を送信できるようになります。ここで説明する攻撃の一部は「よく知られている」と考えられていますが、これらの攻撃の全体的な影響はあまり知られていません。さらに、まだ発見または文書化されていない攻撃も多数存在します。研究者が特定のリソースを枯渇させる方法を文書化するにつれて、攻撃モジュールがsockstressフレームワークのツリーに追加される可能性があります。
sockstress 攻撃ツールは、主に次の 2 つの部分から構成されます。
1) Fantaip: Fantaip [ 10 ]は、sockstressで使用するためにIPアドレスを偽装するプログラムです。これは、偽装されたIPを要求するホストにARP応答を送信することで実現されます。fantaipを使用するには、「fantaip -i interface CIDR」と入力します(例:「fantaip -i eth0 192.168.0.128/25」)。このARP/レイヤー2機能は、ローカルネットワークトポロジの要件に応じて、オプションで他の手段で提供することもできます。sockstressはTCPソケットをユーザーランドで完了するため、カーネルが使用するように設定されたIPアドレスでsockstressを使用することはお勧めできません。カーネルがソケットをRSTするからです。これは厳密には必須ではありません。ファイアウォールを使用してrstフラグ付きの着信パケットをドロップすることで同じ目的を達成し、カーネルが攻撃ベクトルに干渉するのを防ぐことができます。
2) Sockstress:最も基本的な使用法では、SockstressはTCPソケットを開き、指定されたTCPストレステストを送信するだけです。オプションで、アプリケーション固有のTCPペイロード(HTTPリクエストなど)を送信することもできます。デフォルトでは、攻撃後、確立されたソケット上の後続の通信を無視します。オプションで、アクティブなソケットに対してACKプローブを送信することもできます。攻撃は、ハンドシェイク後に標的が利用可能にする、公開されたリソースを悪用します。
ブログ、ニュース、ディスカッション リストで頻繁に議論されているクライアント側 Cookie は、sockstress の実装の詳細であり、これらの攻撃を実行するために厳密に必要というわけではありません。
このセクションの文体やスタイルは、Wikipedia で使用されている百科事典的な文体を反映していない可能性があります。Wikipedia( 2013年2月) |
sockstressフレームワークにおけるすべての攻撃は、攻撃対象のシステム/サービスに何らかの影響を与えます。ただし、特定のシステム/サービスの組み合わせに対しては、他の攻撃よりも効果的な攻撃もあります。
Sockstress には単純な接続フラッド攻撃を実行するための特別な攻撃モジュールはありませんが、-c-1 (最大接続数無制限) および -m-1 (最大同期数無制限) オプションを使用すると、任意の攻撃モジュールを攻撃モジュールとして使用できます。
コマンドの例:
fantaip -i eth0 192.168.1.128/25 -vvvsockstress -A -c-1 -d 192.168.1.100 -m-1 -Mz -p22,80 -r300 -s192.168.1.128/25 -vvリスニング ソケットへの接続を作成し、3 ウェイ ハンドシェイク (最後の ACK 内) 時に 0 ウィンドウを送信します。
syn -> (4k ウィンドウ) <- syn+ack (32k ウィンドウ) ack -> (0 ウィンドウ)
これで、サーバーはゼロウィンドウが開くまでクライアントを「プローブ」する必要があります。これは、攻撃の種類の中で最も理解しやすいものです。結果はコネクションフラッドに似ていますが、ソケットが潜在的に無期限に開いたままになる点が異なります(-A/ACKが有効になっている場合)。これはCPNIドキュメントのセクション2.2で説明されています。ここでのバリエーションとして、ウィンドウを0に設定する前にクライアントペイロード(つまり「GET / HTTP/1.0」)をPSH送信する方法があります。このバリエーションは、CPNIドキュメントのセクション5.1.1で説明されているものと似ています。さらにバリエーションとして、時折0より大きいTCPウィンドウをアドバタイズし、その後0ウィンドウに戻す方法もあります。
良い対戦相手:
コマンドの例:
fantaip -i eth0 192.168.1.128/25 -vvvsockstress -A -c-1 -d 192.168.1.100 -m-1 -Mz -p22,80 -r300 -s192.168.1.128/25 -vvリスニングソケットへの接続を作成し、3ウェイハンドシェイク(最後のACK内)でウィンドウサイズを4バイトに設定し、TCPペイロードを含むACK/PSHパケットを(できれば受け入れ可能な大きさのウィンドウに)作成します。このとき、ウィンドウサイズは4バイトのままです。この方法では、応答を取得して4バイト単位の小さなチャンクに分割するため、カーネルメモリが消費される可能性があります。これは、リクエストごとにメモリが消費されるという点で、接続フラッドとは異なります。この手法は、Linux/ApacheおよびLinux/sendmailシステムを確実な方法で機能停止状態に陥らせてきました。また、他のシステムにも効果があります。これは、CPNIドキュメントの17ページの最後から2番目の段落に記載されている効果と同様の効果があると予想されます。
sockstressのソースファイルにあるpayload.cファイルをご覧ください。hport switch文を探してください。このセクションでは、特定のポートに送信するペイロードを指定できます。可能な限り大きなレスポンスを生成するペイロード(例:'GET /largefile.zip')を送信するのが最も効果的です。
良い対戦相手:
コマンドの例:
fantaip -i eth0 192.168.1.128/25 -vvvsockstress -A -c-1 -d 192.168.1.100 -m-1 -Mw -p22,80 -r300 -s192.168.1.128/25 -vvリスニングソケットへの接続を作成し、3ウェイハンドシェイク(最後のACK内)で、リモートシステムから通知されたウィンドウの先頭に4バイトを送信します。次に、ウィンドウの末尾に4バイトを送信します。最後に、接続を0ウィンドウ化します。スタックによっては、リモートシステムが接続ごとにカーネルメモリの複数ページを割り当てる可能性があります。これは、接続が確立されるたびにメモリが消費されるという点で、接続フラッドとは異なります。この攻撃はLinuxを標的とするために作成されました。Windowsに対しても非常に効果的です。これは、sec-tおよびT2のデモで使用された攻撃です。これは、CPNIドキュメントのセクション5.2.2の5番目の段落およびセクション5.3で説明されているものと同様の効果をもたらすことが期待されます。
良い対戦相手:
コマンドの例:
fantaip -i eth0 192.168.1.128/25 -vvvsockstress -A -c-1 -d 192.168.1.100 -m-1 -Ms -p22,80 -r300 -s192.168.1.128/25 -vvリスニングソケットへの接続を作成します。PSHはアプリケーションペイロード(つまり「GET / HTTP/1.0」)です。接続をFINで閉じ、0ウィンドウにします。この攻撃は、標的とするスタック/アプリケーションによって結果が大きく異なります。この攻撃をCisco 1700(IOS)Webサーバーに対して行ったところ、ソケットがFIN_WAIT_1状態のまま無期限に放置されることが確認されました。このようなソケットが一定数に達すると、ルーターはTCP通信を正しく行えなくなりました。
sockstressのソースファイルにあるpayload.cファイルを見てください。hportスイッチ文を探してください。このセクションでは、特定のポートに送信するペイロードを指定できます。通信先のアプリケーションにとって、通常のクライアントのように見えるペイロードを送信する必要があります。Cisco 1700に対してこの攻撃を行う際、非常に遅い速度で攻撃することが重要でした。
コマンドの例:
fantaip -i eth0 192.168.1.128/25 -vvvsockstress -A -c-1 -d 192.168.1.100 -m-1 -MS -p80 -r10 -s192.168.1.128/25 -vvリスニングソケットへの接続を作成します。PSHはアプリケーションペイロード(つまり「GET / HTTP/1.0」)です。ACKは3回繰り返します。
sockstressのソースファイルにあるpayload.cファイルをご覧ください。hportスイッチ文を探してください。このセクションでは、特定のポートに送信するペイロードを指定できます。通信先のアプリケーションに対して、通常のクライアントのように見えるペイロードを送信する必要があります。
良い対戦相手:
コマンドの例:
fantaip -i eth0 192.168.1.128/25 -vvvsockstress -A -c-1 -d 192.168.1.100 -m-1 -MR -p22,80 -r300 -s192.168.1.128/25 -vvリスニングソケットへの接続を作成します。アプリケーションペイロードをPSHで送信します。これにより、相手側のアプリケーションはソケットを閉じます(ターゲット側はFINを送信します)。FINをACKで返します。
良い対戦相手:
攻撃によって永続的に停止した接続が開始されると、サーバーの接続テーブルが瞬く間に満杯になり、特定のサービスに対してサービス拒否状態が効果的に作り出されます。また、多くの場合、攻撃によって大量のイベントキューとシステムメモリが消費され、攻撃の影響が深刻化します。その結果、TCP通信用のイベントタイマーが機能しなくなり、システムがフリーズしたり、再起動したりといった問題が発生します。これらの攻撃は、それほど多くの帯域幅を必要としません。
単一のサービスが数秒で利用不能になるのは簡単ですが、システム全体が機能しなくなるには数分、場合によっては数時間かかることがあります。一般的に、システムのサービス数が多いほど、攻撃による壊滅的な影響(TCPの切断、システムのロック、再起動など)に早く屈してしまいます。あるいは、より多くのIPアドレスから攻撃することで、攻撃を増幅させることもできます。私たちのラボでは通常、/29から/25までのIPアドレスから攻撃を行っています。/32からの攻撃は、システム全体に障害を引き起こすのに一般的に効果が低くなります。
この攻撃では、被害者の接続テーブルを効果的に埋めるために、TCP 3ウェイハンドシェイクの成功が必要です。これにより、攻撃者は追跡を回避するためにクライアントのIPアドレスを偽装することができないため、攻撃の効果は限定的になります。
sockstress型のエクスプロイトは、攻撃マシン上のrawソケットへのアクセスも必要とします。これは、パケットをOSのconnect() APIではなくユーザー空間で処理する必要があるためです。rawソケットはWindows XP SP2以降では無効になっていますが、デバイスドライバ[ 11 ]が容易に入手可能であり、この機能をWindowsに復活させることができます。このエクスプロイトは、 *nixなどのrawソケットをサポートする他のプラットフォームでもそのまま実行可能であり、root(スーパーユーザー)権限が必要です。
攻撃者が標的に影響を及ぼすにはTCPソケットを確立する必要があるため、重要なシステムやルーター上のTCPサービスへのアクセスをホワイトリスト化することが、現時点で最も効果的な緩和策です。IPsecの使用も効果的な緩和策です。
Cisco社の回答[ 12 ]によると、現在の緩和策は、信頼できるソースからのTCPベースのサービスへのアクセスのみを許可することです。この緩和策は、特に重要なインフラ機器にとって重要です。Red Hatは、「アップストリーム側がアップデートをリリースしないという決定を下したため、Red Hatもこれらの問題を解決するためのアップデートをリリースする予定はありませんが、これらの攻撃の影響を軽減することは可能です」と述べています。Linuxでは、接続追跡とレート制限を備えたiptablesを使用することで、悪用による影響を大幅に軽減できます。[ 13 ]