http DDoSを扱う簡単かつ同時に効果的な方法をご紹介します。 Xeon 2.5GHz / 4Gb RAM / SASサーバーに基づいて、最大約300 Mbit / sの攻撃を撃退できます（値は外挿によって取得されました）。
実施方法
システムパラメータの微調整。 そのため、北は、サーバーへのチャネルがスキップできるよりも多くのボットネットからの接続に耐えることができます。
応用分野
専用サーバーまたはUPUでのHttp DDoSとの戦い。 DDoS攻撃を阻止するための最大可能電力は、サーバーの物理機能とチャネルの帯域幅によって制限されます。
DDoS下のSEO
攻撃中にサイトのインデックスが正しく作成されるため、検索エンジンの結果で位置を維持できます。 特に、SEO予算が大きいサイトに関連します。
コストと効率
攻撃中、サイト上のサービスの一部を放棄する必要があります。 チャネル帯域を拡張し、サイトをより強力なサーバーに転送する必要がある場合があります。 効率は、システムのスケーラビリティ係数を最大化することにより達成されます。 攻撃力を高めながら、ハードウェアリソースを急速に増加させます。
メソッドの説明
http DDoS攻撃との戦いの実際のケースに基づいて、メソッドの適用と達成された結果についてお話します。
私が自由に使えるのは、2台のXeon 2.5GHz / 4Gb RAM / SASサーバーで、1台目はPHPの下、2台目はデータベースの下にありました。 すべての設定は、最初のサーバーで行われましたOS-Debian 4、サイトは約60kのトラフィックでした。 フロントエンドはnginxでした。 システムカーネルはデフォルトで設定されています。 IPの標準禁止ツール-特定の場合のiptablesは、最大7Kのサイズのボットネット攻撃に対処します。
より強力な攻撃の場合、ipsetをインストールする必要があります。
DDoSとの戦いの歴史
初日。 ネットワークスタックオーバーフロー
DOSで割り当てられたIPアドレスは、リクエスト（ping、http、ssh）への応答を停止しますが、残りのIPサーバーは引き続き正常に動作します。 サーバーに複数のIPがある場合、DOSの下のサイトは横になり、サーバーおよびssh上の他のサイトの動作は中断されません。
デフォルトでは、Debianおよびその他のオペレーティングシステムは、ボットネットによって作成された膨大な数の接続をサポートできません。 TCP / IPスタックを強化するには、カーネル設定を変更する必要があります。 カーネルの構成については詳しく説明しませんが、そのような構成の例を示します。
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.core.rmem_max = 996777216
net.core.wmem_max = 996777216
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_mem= 786432 1048576 996777216
net.ipv4.tcp_wmem = 4096 87380 4194304
net.ipv4.tcp_max_orphans = 2255360
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 494967295
kernel.shmall = 268435456
net.core.somaxconn= 16096
debian.telenet.ru/doc/sysctl.confなどのドキュメントのパラメーターの詳細を読むことができますが、このトピックに関する最新の記事をgoogle.comで検索することをお勧めします。
カーネル構成を慎重に変更し、サーバーを再起動してください...
など。 私たちのシステムは、ボットの猛攻撃に耐えることができます。 しかし、勝利を祝うことはまだ非常に早いです。 膨大な数の接続が原因で、PHPおよびデータベースプロセスはメモリおよびプロセッサリソースを完全に「消費」するため、負荷平均値は100ポイントを超えます。
偽の接続を切断する必要があります
netstatでボットを見つけることの欠点
私が問題に対処した反dos管理者は、netstatコマンドでボットを見つける方法を提案しました。 この方法を適用する過程で、いくつかの重大な欠点に気付きました。 それらを詳細に検討しましょう。
1.ブラックリストの作成には時間がかかるため、ブラックリストを頻繁に更新することはできません
2.効果的なボット検索は、Webサーバーが停止している場合にのみ可能です。 現時点では、顧客はサイトにアクセスできず、検索エンジンによるサイトの誤ったインデックス作成の脅威があります
3.検索ロボットのIPはブラックリストに入りますが、これは受け入れられません
提案された方法の非効率性を認識して、私は自分の検索方法を作成し、ボットを禁止する必要がありました
1. Webサーバー（サイト）の一定した安定した動作を確保する
2.検索ロボットのブラックリストで最小の確率を保証します
二日目。 サーバーハードウェア機能+ nginx
Xeon Server 2.5GHz / 4Gb RAM / SAS DoS with GET / HTTP / 1.1リクエスト。
- 実験A. Webサーバー（この場合はnginx）は停止しています
着信トラフィック6085.2 kbit /秒
発信トラフィック5342.1 kbit /秒 - B. Nginx実験は空のHTMLを返します（戻り値444;）
56 Mbpsの着信トラフィック
54 Mbpsのアウトバウンドトラフィック - 実験B. Nginxは約2 KBのHTMLを提供します-これは、「サイトの中断についてごめんなさい」のような小さなメッセージのあるページです
着信トラフィック57 Mbps
発信トラフィック353 Mbps
<...> *
実験に基づいて、次の結論を導き出すことができます。
a）十分なチャネル容量があり、着信/発信トラフィックの比率がない場合、フィルタリングを完全に放棄することができます。
あなたのサイトは、巨大な偽のトラフィックを犠牲にして顧客に利用可能になります。
フィルタリングを完全に放棄するという軽薄な決定。 攻撃者はDoSの能力を高めて、ギガビットチャネルが「嘘をつく」ことができます。
b）絶対にすべてのボットを禁止すると、ボットネットからの偽のトラフィックはわずか5 Mbpsになります。 また、すべてのボットを禁止することは不可能であり、多くのリソースが必要になります。 さらに、検索ロボットが禁止される可能性が高くなります。
最後のケースの発信トラフィックが100 Mbit / sを超えたという事実にも注意を払う必要があります。 つまり、100 Mbpsポートに接続されたサーバーは、チャネルの全負荷のために、sshを介したアクセスが非常に難しくなります。 このような迷惑を回避するために、ボットフィルタリングの設定を完了する前に、空のHTMLを返すように設定するか、nginxで444を返すことをお勧めします。
nginxツールを使用してボットを検索する
この場合、サーバーはリクエストリクエスト「GET / HTTP / 1.1」で攻撃されます。
良い顧客は、サイトのメインページに同時に2つ以上のリクエストを行うことはないと想定しています。 3つ以上の同時接続を開いたクライアントは、ボットを攻撃し、ファイアウォールでIPアドレスを禁止するとみなします。
仮定は実験的に確認されました。 120,000個のIPアドレスからの1日あたりのhttp要求のログの分析に基づいて、19個のIPで2つ以上の同時要求が行われました。
ボット検索を実装するために、特別なリクエスト処理を作成します
リクエスト： nginxの「GET / HTTP / 1.1」 。
error_log /var/log/nginx/error.log;
<…>
location =/ {
limit_conn one 3;
root /home/www/site.ru;
}
3つ以上の同時接続が開かれたIPアドレスは、ゾーンごとに接続を制限するメッセージとともにerror.logに記録されます。 エラーログに基づいて、攻撃しているボットネットのブラックリストIPを構築できます。
iptablesでのボットのフィルタリング
注意することが重要です。 IPtablesは、多数のアドレスのフィルタリングには適していません。 チェーン数> 2K iptablesで、ksoftirqdプロセスはCPUの100％を消費し始め、信じられないほどのサーバー負荷につながります。 この問題は、ipsetをインストールするか、iptablesのルールの数を減らすことで解決します。
この場合、緊急時にipsetのインストールが遅れました。 サーバーには組み込みのKVMがなく、カーネルの再構築は危険でした。
ブラックリストの作成を始めましょう。 禁止では、iptablesを過負荷にしないために、最も攻撃的なボットのみを配置します。
#
cat /var/log/nginx/error.log | grep "limiting connections by zone" | grep "request: \"GET / HTTP/1.1"| awk '{print $12}'| awk -F"," '{print $
1}'| sort | uniq -c | sort -nr > /tmp/botnet.blacklist
#
cat /dev/null > /tmp/iptables_ban.sh
# DROP 50
awk '{print "iptables -A INPUT -p tcp --dport 80 -s " $2 " -j DROP" }' botnet.blacklist | head -n 50 >> /tmp/iptables_ban.sh
# blacklist
bash /tmp/iptables_ban.sh
#
cat /dev/null > /home/www/nginx_log/error.log
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
数分の頻度で冠にスクリプトを追加します。 経験的に周波数を選択します。 5分ごとにやった。
*/5 * * * * /root/script/ban.sh
その結果、iptablesには新しいボットが補充されます。
ろ過スキーム
三日目 まとめ
この方法により、クライアントはサイトに安定してアクセスできました。 PSの正しいインデックスは、サイトが発行においてその位置を保持しているという事実によって確認されました。 サーバーの負荷は、合理的な制限を超えて6〜7ポイントを超えませんでした。 サーバーからの送信トラフィックは100 Mbpsを超えませんでした。 攻撃を撃退するには、7Kボットネット機能iptablesで十分です。
DDoSは自然災害であり、損害は避けられません。
一部の顧客は、サービスの失敗中に競合他社に行きます。
プログラマー、管理者の処理、または追加機器の購入にいくらかの費用が発生します。
あなたのリソースはPS（yandex、google）で積極的に宣伝されています。これは、誤ったインデックス作成のリスクが重要であり、その結果、結果の位置が失敗することを意味します。
主なタスクは、DDoSによる被害を最小限に抑えることです。
私の場合、DDoS攻撃はフィルタリングの開始の翌日に停止しました。 DoSの顧客は、攻撃を増やすためにより多くのお金を費やす準備ができていませんでした。
ほとんどの場合、DDoSはネット上の競争力のある武器です。 クライアントは、リソースに障害が発生した場合、ほぼ瞬時に競合他社にアクセスできます。
私は、DDoSとの戦いはボットの浴場ではなく、攻撃によるあなたの総損害がイニシエーターのコストに匹敵する状況を作り出していると信じています。 顧客は、たとえば50,000ルーブルを費やす必要があります。 50,000ルーブルの損害を引き起こすために、競合他社がそのような攻撃を組織することは経済的に実行不可能です。
この記事で説明する方法は万能薬ではなく、DoSを撃退する一連の手段の一部にすぎません。 大規模なサービス開発計画では、リスクを考慮し、攻撃の悪影響を軽減するための対策を提案する必要があります。
私の記事がWebアプリケーションの開発者と管理者のコミュニティに役立つことを願っています。
___
*テキストから約300 Mbpsの段落を削除しました。 それは合理的に苦情を提起します。
「300 Mbit / sを超える」「限界に達します...」-これは、HDDがビデオ/オーディオを出力する場合に当てはまります。 「重い」ファイル。 HTMLファイルの場合、このステートメントは不公平です。
削除された段落のテキスト：
「実験の結果によると、サーバーが最大約300 Mbpsの攻撃の増加に耐えることができることは明らかです。 300 Mbit / sを超えると、SASディスクのランダム読み取りの制限に「達する」ことになります。 そのため、お客様にはWebサービスの可用性を維持しながら、十分な安全マージンと攻撃を効果的に反映する高い確率があります。」