DNSの更新中に、戦場の初期のブラックボックス評価を行いました。
ximaera@endeavour:14#487:~$ nc habrahabr.ru 80 <<EOF
> GET / HTTP/1.1
> Host: habrahabr.ru
>
> EOF
^C
real 0m19.020s
user 0m0.000s
sys 0m0.024s
ximaera@endeavour:14#488:~$ ping habrahabr.ru
64 bytes from ***: icmp_req=1 ttl=54 time=53.5 ms
64 bytes from ***: icmp_req=2 ttl=54 time=53.1 ms
64 bytes from ***: icmp_req=3 ttl=54 time=53.1 ms
^C
--- *** ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 53.126/53.300/53.598/0.340 ms
ximaera@endeavour:14#489:~$
そのため、サーバーは許容可能な時間を担当しますが、接続は確立されません。 明らかに、攻撃はTCPプロトコルまたはアプリケーション層に行きます。 最近の50ギガビット攻撃の後、困難な顧客のために検疫を取得しましたが、この場合は使用しないことにしました-おそらくトラフィックはごくわずかです。
夕方7時半、DNSが切り替わりました。
このグラフィックはキツネを示しています。 稼働中のWebリソースの場合、発信トラフィックの量は着信トラフィックの量を1桁超えます。 それらが数十パーセント異なる場合-トラブル。
Habrが最後に私たちの保護下にあったのは、うーん、長い間。 正当なユーザーの行動の履歴はほとんど蓄積されていないため、フィルターを手動で制御する必要があります。 最初に、TCP接続オートマトンの大まかな分析を含めます。
タイムアウトした接続とリクエストの割合が高いと攻撃していることがわかります。 もちろん、接続の追跡は地獄に落ち、データベースも悪かった。 ボットは大量にブロックされます。
Habraserverは死んでいるよりも生き延びています。 しかし、ごみのリクエストがあり、それは目に見えます。
裁判と事件の間、臨界質量が分類器に蓄積されました。 遷移分析を実行します。 すぐに「レッドゾーン」で、これらの要求を実行するIPアドレスのクラウドが飛びます。
178.120.56.144 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.live.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.0)" [habrahabr.ru]
85.173.219.240 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.alexa.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0)" [habrahabr.ru]
178.94.52.22 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.google.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.1)" [habrahabr.ru]
46.36.130.136 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.live.com/" "Opera/7.51 (Windows NT 5.2; U) [en]" [habrahabr.ru]
46.7.52.14 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.live.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.2)" [habrahabr.ru]
クエリは常に同じです：GET / search？Q = intel。 リファラーは異なります：Google、Ask.com、その他の検索エンジン。 これらの不正なリクエストの作成者はブロックされます。
心配する必要はありません。その時点でGoogleから「intel」というクエリを使用してHabrの検索ページにアクセスしても、すぐに禁止されることはほとんどありません。 ユーザーの正当性の計算は、多くのクエリに基づいています。
注：偽のトラフィックが除外されると、正当なユーザーが生成したトラフィックはすぐにわずかに増加し（サイトのみが機能している場合）、送信トラフィックはすぐに目覚めました。 ゼロからの保護を有効にしてから1時間以内に、サイトは完全に動作可能な状態になりました。
HTTP QRATOR 503を生き延びました！
この時点で、攻撃は基本的に停止しました。 それに反して動作するサイトに偽のトラフィックを保持することは意味がありません。他の誰かにお金を稼ぐ方が良いです。
攻撃力を推定します。 次の有害なコンポーネントが利用可能です。
-接続の数。
-データベースへのクエリの数。
したがって、着信トラフィックの量や攻撃IPアドレスの数を評価するのは無意味です。主なことは、単位時間あたりの開いている接続の数です。 攻撃のピーク時には、約9000件のリクエスト/秒が作成されました。これは実際、攻撃の力です。 各要求は、個別のTCP接続で実行されました。 したがって、Linuxのデフォルト値CONNTRACK_MAX（サーバーに1 GBを超えるRAMがあると仮定）は、攻撃から7.29以降に使い果たされることに注意してください。 プラスベースの負荷。
ご存知のように、問題は単独では発生しません。 いずれにせよ、この領域ではありません。 0:20に攻撃者が再び来て、ボットネットのボリュームは19:30に比べてわずかに大きくなりました。 しかし、私たちはすでにこれに対応しており、攻撃は自動的に停止しました。 攻撃の再発は非常に一般的なことです。オーガナイザーは、参加者が「手放し」始めるとすぐに、サイトの動作を特別に監視し、ボットネットをアクティブにすることがあります。 ここでは簡単でした。すべてのボットがブロックされるとすぐに、最初の攻撃と同様に再攻撃が停止しました。
編集14:52文字通り、最小限の損失で、攻撃の第三の波は終わりました。 約4,500の攻撃ボット、ピーク時には4,000のリクエスト。 感染したマシンは現在、IntelだけでなくAppleやGoogleにも関心を持っています。 引き続き開発状況を監視しています。