|
少し前、上海のゲーム・エンターテインメント企業のウェブサイトが、ページリクエストに基づくDDOS分散型サービス拒否攻撃を受けた。ウェブサイトは完全に麻痺し、ハッカーからの匿名の手紙で最大10万元の脅迫を受けた。脅迫の過程で、ハッカーはテンセントQQなどのウェブサイトを攻撃するとも述べた。その後、QQの「サーバーメンテナンス」が数日間実施された。 12月5日には、グローバルBitTorrentサーバーも深刻なDDOS攻撃を受け、一時的に麻痺状態に陥った。最も一般的で強力なDDOS攻撃は、ページベースのDDOSと、この攻撃理論を最大限に活用した攻撃ツールCCです。この記事では、CCの作者にCCの関連する攻撃原理と防止方法を共有してもらい、より多くの友人がこの攻撃方法を理解し、防止できるようになることを願っています。 CCの書き方と予防法についての私の考え
文/キキ
多くの友人は樽理論を知っています。バケツの水の最大容量は、バケツの最高点ではなく最低点によって決まります。サーバーについても同じことが言えます。サーバーのセキュリティも、サーバーの最も脆弱な点によって決まります。最も脆弱な点が危険であればあるほど、サーバーは危険になります。 DDOS についても同様です。サーバー上に大量のリソースを消費する場所があり、制限が不十分であれば、すぐに他人の DDOS のターゲットになってしまいます。たとえば、SYN-FLOOD は、サーバーの半接続状態は完全接続状態よりも多くのリソースを消費するのに対し、SYN イニシエーターはパケットを継続的に送信するだけで、多くのリソースをまったく必要としないという事実を利用します。 優れた DDOS 攻撃は、自身のリソースをほとんど消費せずに、相手に多くのリソースを消費させる必要があります。そうでない場合、たとえば、ICMP-FLOOD と UDP-FLOOD は他のものと同じ帯域幅を必要とし、相手のサーバーが消費するのと同じだけのリソースを支払わなければなりません。これは非常に非効率的で、簡単に発見できます。基本的に、現在これを使用する人はいません。
攻撃の原則
CC は主にページを攻撃するために使用されます。私たちは皆、このような経験をしたことがあるでしょう。フォーラムを訪問したとき、フォーラムが大きく、訪問者が多いと、ページが開くのが遅くなりますよね? ！一般的に言えば、訪問者数が増えると、フォーラムのページ数が増え、データベースが大きくなり、アクセス頻度も増え、システム リソースの占有量も増えます。これで、多くのスペース サービス プロバイダーがフォーラム、チャット ルームなどをアップロードしないように勧めている理由がお分かりいただけたと思います。
静的ページは、サーバーから多くのリソースを必要としません。メモリから直接読み取って送信することもできます。しかし、フォーラムの場合は異なります。投稿を読む場合、システムはデータベースにアクセスして、投稿を読む権限があるかどうかを判断する必要があります。権限がある場合は、投稿の内容を読み取って表示します。ここでは、データベースに少なくとも 2 回アクセスします。データベースのサイズが 200 MB の場合、システムはおそらくこの 200 MB のデータ領域を検索します。これには、どのくらいの CPU リソースと時間が必要ですか?キーワード検索の場合は、さらに時間がかかります。これは、以前の検索が、ユーザー権限はユーザーテーブルのみをチェックし、投稿コンテンツは投稿テーブルのみをチェックするなど、非常に狭い範囲に制限され、検索が見つかった直後にクエリを停止できる一方で、検索ではすべてのデータに対して必ず判断が行われるため、かなりの時間が消費されるためです。
CC はこの機能を最大限に活用して、複数のユーザー (スレッドの数はユーザーの数) が継続的にページにアクセスする (大量のデータ操作、つまり大量の CPU 時間を必要とするページにアクセスする) ことをシミュレートします。多くの友人が、なぜプロキシを使うのかと尋ねました。プロキシは事実上その ID を隠し、すべてのファイアウォールをバイパスできるため、基本的にすべてのファイアウォールは同時 TCP/IP 接続の数を検出し、特定の数と頻度を超えると接続フラッドと見なされます。 プロキシ攻撃を使用すると、接続を非常にうまく維持することもできます。ここでデータを送信すると、プロキシがそれを相手側のサーバーに転送するのに役立ちます。すぐに切断しても、プロキシは相手側との接続を維持し続けます (2,000 個のプロキシを使用して 350,000 個の同時接続を生成したという記録を知っています)。
たぶん、多くの友人はまだそれをよく理解できないでしょうから、説明させてください。サーバー A が Search.asp を処理するのに 0.01 秒かかると仮定します (マルチスレッドは単なる時間分割であり、結果には影響しません)。つまり、1 秒間に 100 人のユーザーの検索要求を保証できます。サーバーが許可する最大接続時間は 60 秒であるため、CC を使用して 120 人のユーザーの同時接続をシミュレートします。1 分後、サーバーは 7200 回要求され、6000 回処理されるため、処理されていない同時接続が 1200 残ります。友達の中には「接続が切れた！」と言う人もいるでしょう。接続が失われました!問題は、サーバーが先着順にそれらを破棄することです。これらの 1200 は、過去 10 秒間に開始されました。これらを破棄しますか? ！まだ早い段階です。計算すると、サーバーが完全にロードされ、接続がドロップし始めると、キューには 7200 の同時接続があるはずです。その後、サーバーは 120/秒で接続をドロップし始めます。開始する接続も 120/秒です。サーバーはすべての接続の処理を完了することはありません。サーバーの CPU は 100% で、長時間維持されます。その後、サーバーは 60 秒間の接続ドロップを処理できないと判断し、新しい接続を処理できなくなります。このようにして、サーバーは超ビジー状態になります。
Butterfly: サーバーが検索を処理するのにかかる時間は 0.01 秒、つまり 10 ミリ秒だけであると想定しています (この速度は、営業時間を表示するさまざまなフォーラムで確認できます)。使用するスレッドは 120 個だけです。多くのサーバーの接続が失われる時間は 60 秒よりもはるかに長くなっています。私たちは 120 個よりもはるかに多くのスレッドを使用しています。それがどれほどひどいかは想像がつくでしょう。さらに、クライアントが切断を送信する限り、プロキシによって接続が維持され、サーバーが SQL 要求を受信すると、接続が切断されているかどうかに関係なく、必ずキューに入ります。さらに、サーバーは同時実行であり、順次実行ではないため、より多くの要求がメモリ要求に入り、サーバーに大きな負荷がかかります。
もちろん、CC はこの方法を使用して FTP を攻撃し、TCP-FLOOD を実装することもできます。これらはテスト済みで効果があることが証明されています。
予防方法 攻撃の原理について説明したので、誰もが間違いなく、どのように防御すればよいのかと尋ねるでしょう。ページ アクセスを完全にブロックしない限り、ハードウェア ファイアウォールを使用してこれを防ぐ方法はわかりません。私のアプローチは、ページを記述して防御を実装することです。
1. Cookie認証を使用します。このとき、友人は、CC でも Cookie が許可されているが、ここでの Cookie はすべての接続に使用されるので、IP + Cookie 認証を有効にするだけでよいと言っていました。
2. セッションを使用します。この判断は Cookie よりも便利です。IP 認証だけでなく、リフレッシュ モードの防止もできます。ページがリフレッシュされたかどうかを判断できます。リフレッシュされた場合はアクセスできません。リフレッシュ シンボルがない場合は、リフレッシュ シンボルが付与されます。サンプルコードをいくつか示します。セッション:
1 その後
セッション("リフレッシュ") = セッション("リフレッシュ") + 1
レスポンス.リダイレクト "index.asp"
終了の場合
この方法では、ユーザーの最初の訪問では Refresh=1 になり、2 回目の訪問では通常の状態になり、3 回目の訪問ではリフレッシュと見なされてアクセスが許可されなくなります。時間パラメータを追加して、アクセスに許可される時間を設定できます。これにより、時間のかかるページへのアクセスが制限され、通常の顧客にはほとんど影響がありません。
3. プロキシによって送信された HTTP_X_FORWARDED_FOR 変数を使用して、プロキシ攻撃を使用しているマシンの実際の IP アドレスを特定します。この方法では、攻撃を開始した人物を完全に見つけることができます。もちろん、すべてのプロキシ サーバーがこのパラメータを送信するわけではありませんが、多くのプロキシが送信します。詳細コード:
これにより、CCLog.txt が生成されます。その記録形式は、実際の IP [プロキシ IP] 時間です。どの実際の IP がより多く出現するかを調べることで、誰が攻撃しているかがわかります。このコードを Conn.asp ファイルに追加し、データベースに接続するファイルを置き換えます。こうすることで、すべてのデータベース要求がこのファイルに接続されるため、攻撃者をすぐに見つけることができます。
4. 別の方法としては、リダイレクトの後にデータを照会する必要があるステートメントを配置し、相手が最初に判断ページにアクセスしてからそこにリダイレクトするようにします。
5. 複数のステーションを持つサーバーでは、各ステーションに許可される IP 接続数と CPU 使用時間を厳密に制限することが非常に効果的な方法です。
CC の防御はコードから始める必要があります。実際、優れたページ コードでは、侵入ツールであるだけでなく、DDOS の抜け穴でもある SQL インジェクションだけでなく、これらのことにも注意を払う必要があります。コードでは誰もがこれに注意を払う必要があります。たとえば、サーバーが 5,000 行の CC 攻撃を開始したが、データベース アクセス要求はすべてセッション内にランダム パラメータを持つ必要があり、すべてが静的ページであるため、まったく応答がなかったため、効果はありませんでした。突然、外部サーバーへの接続要求があり、時間がかかり、認証も行われていないことがわかりました。 800 行の攻撃を開始したところ、サーバーがすぐに過負荷になりました。 コード層の防御は少しずつ行う必要があります。スクリプト コードのエラーはサイト全体、さらにはサーバー全体に影響を及ぼす可能性があります。注意してください。 | 
