送信メール
そのようなサービスに登録して、彼からメールで登録の手紙を受け取りましょう。 手紙のソースを開き、以下を参照してください。
Received: from mxfront8j.mail.yandex.net ([127.0.0.1]) by mxfront8j.mail.yandex.net with LMTP id c0MIOzBI for <mymail@yandex.ru>; Sun, 10 May 2015 15:58:47 +0300 Received: from srv1.example.com (srv1.example.com [xxx.xx.xx.xxx]) by mxfront8j.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id FpRuMcFeJH-wksakWfe; Sun, 10 May 2015 15:58:46 +0300 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) Received: from srv1.example.com (localhost [127.0.0.1]) by srv1.example.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t4ACvd6T026304 for <mymail@yandex.ru>; Sun, 10 May 2015 15:57:39 +0300 Received: (from www-data@localhost) by srv1.example.com (8.14.3/8.14.3/Submit) id t4ACvdQX026302; Sun, 10 May 2015 15:57:39 +0300
さて、プロキシではなく、このDCのこのサーバーのサブネットで車を見つけました。 ここにあります：srv1.example.com、xxx.xx.xx.xxx。 高い確率で、このマシンはwwwサーバーと同じDCおよび同じサブネットにあります。 通常、このようなプロジェクトには/ 24以下の大規模なネットワークはありません。 グリッドをスキャンして、80 / tcpポートが開いているすべてのマシンを見つけましょう。 Noobは素晴らしいです。マシンのリストがあります-各ブラウザに行きましょう。 アドレスxxx.xx.xx.xxyのマシンで、 www.example.comへのリダイレクトが発生しました-これは同じマシンであり、プロキシディフェンダーにリダイレクトされました。
これで、この車を安全に攻撃できます。 マシンのチャネルが1GBを超えることはまずありませんが、4つのインターフェースを備えたネットワークカードがすぐに組み込まれているマザーボードがあります。 したがって、攻撃は4GBのマージンで行われます。 アプリケーションへの攻撃やnginxへの攻撃は開始しません-単にチャネルをトラフィックであふれさせることができます。 さらに、サーバーへの着信方向のみを入力するという事実は怖くありません。 ユーザーからのリクエストもインバウンド方向です。 これはDDoS攻撃に対して4 GBを大量に使用しますか？ 数えましょう。 モスクワでは、多くの人が自宅でインターネットを利用しています-最低40MB。 4 GB / 40 MB = 100台。 これらはボットを備えた100台のマシンです-そのようなボットネットは非常に迅速に編成でき（適切なスキルがあれば）、DDoSに常に関与している人にとっては、これはまったく問題ありません。 最新のボットネットは数千の感染したマシンです。
自分を守る方法は？
簡単な解決策は、DCの外側と戦闘サブネットの外側にメールマシンを配置することです。これは、メールリレーとして動作し、「受信」全体を遮断します。 これは難しくありません。同じ接尾辞にはcontent_filterオプションがあり、コンテンツをフィルタリングするためにSMTPプロキシを指定できます。 どの言語でも、smtp-proxyを簡単かつ簡単に記述できます。これにより、不要な文字がすべて削除されます。 正直なところ、完成したツールはわかりませんが、私にとっては、pythonまたはrubyでsmtp-proxyを作成するタスクは数時間のタスクです。
DNSゾーンを盗む
アクセスしにくいですが、実際の方法でもあります。 DNSゾーンを削除すると、その中にマシン名とIPアドレスが見つかります。通常、マシンの技術名は同じゾーンに保持されます。 srv1.example.com IN A xxx.xx.xx.xxxのようなもの。
それは非常に簡単に保護されます-すべての技術的なDNS-sは別のサブドメインで取り出され、より慎重に保護されます。 srv1.servers.example.com-そのようなもの。
間接攻撃
統計のないサイトが機能しないと結論付けることは難しくありません。 通常、DDoSからの保護のためのサービスはトラフィックにお金を請求するため、メインドメインからの統計はCDNに転送されます。 CDNでトラフィックをあふれさせることは、その分布のために非常に難しいタスクです。 ただし、サイトにはどのような静的なものが残っているかを確認できます。 ああ！ 左のサービスからバナーが表示され、彼は代理ディフェンダーに座っていません-これは単なる運です。 チャンネルをバナーシステムにアップロードできます。jsはロードされず、DOM Readyは発生しません-サイトに多くのjsがある場合、それを使用することはほとんど不可能です。
これは普遍的な方法ではありませんが、jsのないサイトが原則として機能しない場所に行くことができます。 これに対する保護も可能な限り愚かです-バナーへの非同期js。 できませんでした
金融攻撃
そのため、CDNに興味深いファイルcdn-1.example.com/static/video/hardporn.flvが見つかりました。 重さは最大140 MBです。 プロキシ支持者はトラフィックに課金することを覚えています。 また、CDNはこのファイルをどこで取得しますか？ www.example.com/static/video/hardporn.flvの単純な場合。 彼が与えられていることを確認してください。 まあ、素晴らしい。 単純なケースでは、このファイルを数日間単純にダウンロードする非常に小さなボットネットが必要です。負荷が大きくなく、プロキシの防御者の注意を引くことはありません。 もちろん、これは過剰なプリペイドトラフィックになり、サイトの会社所有者は非常に悲しくなります。
このような攻撃を少し台無しにすることができます-XSSを見つけて、自動再生と表示でhtml5ビデオをそこに貼り付けます：なし。 外側では、何も変化していませんが、各ユーザーは多くのトラフィックを集めています。 ボットネットとは異なり、各ユーザーを除外することはできません。
一般に、金融攻撃はバインダーにとって最も危険です。 ビジネスがサイトを機能させるために膨大なトラフィックにお金を払う（さらにトラフィックを増やす）か、料金を支払わずにサービスが停止するかのいずれかです。
これに対する保護はばかげているのは簡単です-静的から403をCDN以外の全員に返します。
モバイルAPI攻撃
サイトにモバイルアプリケーションもある場合-これは今流行です、それは現代のサイトを意味します。 モバイルアプリケーションがある場合、通常、サイトにはモバイルAPIもあります。 アプリケーションを自分でインストールし、tcpdump番目のトラフィックを収集した後（PCでWi-Fiをポイントツーポイントで上げるのは難しくありません）、api-mobile.example.comを見つけることができます。 おそらく、彼も保存したいという願望のために、代理防御者の背後にいるのではなく、サーバーを直接見るでしょう。 さて、私たちが必要とするIPは焼き付けられました。
既に理解しているように、保護は簡単です-APIのトラフィックはプロキシディフェンダーを通過する必要があります。
おわりに
上記の方法はすべて簡単です。 サイトの詳細な調査は必要ありません-つまずくだけで、シェルを置く必要さえありません。 すべての方法がすべてのサイトで現実的であるとは限りませんが、ほとんどのサイトでは、少なくとも1つの方法が機能します。
防御サービスを介したDDoS攻撃に対する保護は優れており、経済的および技術的に正当化されます。 サイト管理者向けのタスクがありました-IPをスリープさせないでください！