こんにちは、Habrasociety。
最近では、DDoS攻撃の関連性については説明しません。
統計を見てください。 アクティビティのタイプごとに頻繁に攻撃を受けます。LinuxやFreeBSDサーバーでのSYNフラッドなど、DDoSに対する動的な保護のアイデアが生まれました。 SNMPを介したSYNフラッド監視の実装も提案されています。
それはすべて下にあります。
TCPオプション
オペレーティングシステムは、TCPプロトコルを使用してネットワーク上で作業するための設定を微調整する機能を提供します。 UNIXでは、これはカーネルパラメーター値を変更することによって行われます。 以下は、SYN要求キューの処理に影響するパラメーターです。 デフォルト値は括弧内に示されています。
- net.core.somaxconn-接続キューの最大値（128）
- tcp_syn_retries-正常に接続を確立するためにSYNを渡す試行回数（5）
- tcp_synack_retries -SYN要求へのSYN、ACK応答の送信試行回数（5）
- tcp_keepalive_intvl-各キープアライブプローブ応答を待機する時間（75秒）
- tcp_keepalive_probes-接続が失われたと判断する前に送信する必要があるTCPキープアライブサンプルの数（9）
- tcp_keepalive_time-接続キープアライブパケットが現在使用されていない場合に維持するためにTCPキープアライブパケットを送信する必要がある頻度（7200秒）
FreeBSDの同様のオプションが
ブログで提供されて
います。
再送信試行の値とその間隔は非常に大きいことがわかります。 アイデアはそれらを減らすことであり、新しいものではありません。 しかし、システムのブート段階で静的に行う価値はありますか？ 今日、モバイルインターネット加入者の数は急速に増加していますが、CIS諸国では、ほとんどがEDGE（またはGPRS）を介してアクセスします。 したがって、そのようなサイト訪問者の場合、カーネルにハード値を設定する必要はありません-攻撃がなくても、サービスを拒否できるのはこのためだけです。 理想的なオプションは、攻撃がない場合に値がデフォルトに近い場合（接続の成功に寄与する）、および攻撃の条件で値が（キューの長さを除いて）減少する場合です。
パラメータの動的な変更で言及されたアイデアが訪れました。 これが本当に役立つかどうか、およびシステムブートの段階で値を静的に設定するかどうかには疑問があります。 この問題については
ブログで説明しました。 この問題について読者の意見を聞いてうれしいです。
別に、SYNリクエストのキューについて
キュー128のデフォルト値は、特に攻撃に適している場合、ロードされたシステムでは非常に小さいため、当然増加させる必要があります。 ただし、この増加を制限する制限があります。
まず、キュー内の各エントリには600バイトのRAMが必要です。
次に、net.core.somaxconnの長さの個別のキューが、TCPポートでリッスンする各サービスに割り当てられます。
これらの考慮事項に基づいて、net.core.somaxconnの値は次の式で計算できます。
somaxconn =（MEMfree-MEMres）/ 600 * N、ここで
MEMfree-現在の空きRAM
MEMres-システムおよび他のプログラム用に予約されているメモリ
600バイト-各エントリをキューに入れます
N-TCPポートでリッスンするサービスの数
SNMPの拡張機能の実装
このアイデアはスクリプトとして実装されています。 また、設定ファイルが付属しています。このファイルでは、システムの作業を自由にカーネルパラメータの変更の追加/削除まで設定できます。 このスクリプトをSNMPの拡張として使用します。 LinuxおよびFreeBSDのバージョンがあります。
質問：可能であれば王冠でSNMP経由でスクリプトをプルするのはなぜですか？
回答：これにより、カーネルパラメータを即座に変更できるだけでなく、SNMPで実行されている監視システムと統合することもできます-アラートの設定など 個人的には、Cacti RRDのフロントエンドを使用して、SYNキューのロードスケジュールを取得します。 Cactiのテンプレートは、サイトからダウンロードできます。 この質問は原則の問題ではなく、保護およびSNMP拡張機能を異なるスクリプトに割り当てることができます。
セキュリティテスト
システムは、1台の100Mb L2スイッチに接続されたデスクトップとラップトップでテストされました。 hpingでテスト済み。
Cactiリアルタイムグラフの結果：
動的保護モードでは、特徴的なピークが観察されます。 それらは、攻撃がしきい値-しきい値によって監視されるという事実のために発生します。 将来的には、充填の頻度を監視し、これらのピークを減らす予定です。
グラフでピークに気づいた場合、カーネルパラメータがハード値に設定され、キューの長さによって変化しない場合、強制保護を手動で設定できます。 グラフでは、キューの値がほぼ0に近いことがわかります。
備考
1.ビジーなサーバーでは、キュー0の値は実際には存在しません。 通常モードでは0〜40の範囲であるため、しきい値を選択する必要があります。
2. HTTPフラッド中にSYNリクエストのキューは確実に増加するため、キューのしきい値による攻撃の検出は完全に正しいとは限りません。 干渉は有用ではありませんが。
サイト
慣れと構成を簡単にするために、サイト
synflood-defender.netを作成しました。 既存および計画中の機能、ダウンロードリンク、段階的なセットアップ手順、および便利なDDoS関連のエントリが定期的に表示されるブログを備えています。
最近、このスクリプトはブラジルの友人1人のサーバーを保護するのに役立ちました。 感謝の気持ちで、彼
は How to useページの
ポルトガル語訳を公開しました。 したがって、ポルトガル語での読書がより快適なhabrachitateliは、不快感を感じることはありません;）