devinblack001/ddos-reduction-system行動ベースのトラフィック分析、Random Forest分類、およびカーネルレベルのipset/iptables適用を使用した適応型2段階Layer 4 DDoS緩和ゲートウェイ。
First Line Of Defense
適応型二段階レイヤー4ボリューメトリックDDoS緩和ゲートウェイ。
作者: Abdullah Armiyao
プロジェクト: Adaptive Two Stage Framework for Near Real Time Layer 4 Volumetric DDoS Mitigation Using Behavioral Traffic Analysis
ほとんどのDDoS緩和は固定しきい値を使用します。1秒あたりのパケット数がハードコードされた数値を超えるものをすべてブロックするというものです。これは両方向で失敗します。繁忙期に正当なトラフィックが急増すると実際のユーザーがブロックされたり、攻撃者がしきい値のすぐ下に留まって通過してしまったりします。
FLODはあなたの通常のトラフィックがどのようなものかを学習し、検出境界をそれに合わせて移動させます。しきい値を手動で調整することなく、DDoSフラッドとフラッシュクラウド(正当な急増)を区別します。
トラフィック送信元と保護対象ホストの間のゲートウェイ上にインラインで配置され、問題のある送信元をカーネル内でドロップまたはスロットリングします。
ダッシュボードはブロックしたアドレスを攻撃者として明示するため、ネットワーク構成を事前に知らない人でもどの送信元が敵対的だったかを判別できます。スロットリングされたアドレスは別途一覧表示されます。スロットリングは予防措置としても使用され、グループ全体に一度に適用されるためです。
ステージ1はパケットパス上のRustセンサーです。保護対象ホスト宛てのすべてのパケットをキャプチャし、短いウィンドウでレートと送信元の多様性を計算し、自身が維持するベースラインと比較します。算術演算のみを行うため、トラフィックの妨げになりません。
ステージ2はPythonサービスです。ウィンドウごとにステージ1からサマリーを受信し、Random Forestで分類し、ipsetとiptablesを介してカーネルレベルの強制措置を発行します。Isolation Forestがすべてのウィンドウで並行して実行され、どちらのモデルも学習していないトラフィックにフラグを立て、強制措置を駆動するのではなく、別個のAnomalous状態として表面化します。ステージ2はWebダッシュボードも提供します。
両者はUnixドメインソケットで接続されています。
モデルはキャプチャされラベル付けされたトラフィックでトレーニングされ、デプロイメントはさらにキャプチャを続けます。Isolation Forestが未知と判断したウィンドウ、およびRandom Forestが自信を持ってDDoSと判定したウィンドウは、キャプチャファイルに書き込まれます。定期的なジョブがそれらをRandom Forestと、別の方法で構築された2番目のモデルで再スコアリングし、両方が高い信頼度で同じクラスを選択し、かつ両方がその行のキャプチャ後にトレーニングされた場合にのみ、トレーニング用の行をステージングします。ダッシュボードのレビューページにはステージングされた行が1ページ500件表示され、担当者がトレーニングデータにマージするか破棄するかを決定します。トレーニングセットに自動的に到達するものはありません。
FLODはパケットヘッダーだけで観測できるレイヤー4ボリューメトリックフラッドで機能します。レート、送信元IPエントロピー、プロトコルミックス、およびトラフィックが最も忙しい送信元にどれだけ集中しているかです。実際には、これは大量かつ集中したフラッドが、有限の実アドレス集合から到着することを意味します。
1つは明示的に適用範囲外であり、もう1つは部分的に対処されています:
アプリケーション層攻撃。 リクエストコンテンツは解析されないため、低速で少量のリクエストフラッドや接続枯渇は、ヘッダーのみの特徴量セットが観測できる範囲外です。
ランダム化された送信元スプーフィング。 パケットごとに新しい送信元アドレスを偽造すると、エントロピーが低下するのではなく上昇し、アドレスベースの特徴量が探すシグナルが反転します。送信元ポートエントロピー、TTL分散、TCP SYNフィンガープリントの多様性はアドレス偽造に対して不変であり、この検出の盲点を埋めますが、スプーフィングされたフラッドの検出は、それを停止するよりも狭い問題です。偽造アドレスをブロックすることは、実際にそのアドレスを所有する者を罰することになるため、このクラスに対する安全な強制措置は依然として未解決です。DetectionとExplainerを参照してください。
git clone https://github.com/DevInBlack001/ddos-reduction-system.git
cd ddos-reduction-system
sudo bash scripts/install.sh --interface <IFACE> --victim-ips <IP1>,<IP2>
sudo systemctl enable --now ddos-stage2
sudo systemctl enable --now ddos-stage1
インストーラーは Stage 1 をビルドし、その後 Stage 2 のコードと仮想環境を /opt/flod/stage2（root 所有）にコピーし、そこで管理アカウントを設定します。これは Stage 2 が root として実行され、非特権アカウントがまだ書き込めるチェックアウトから何も実行してはならないためです。可変状態、データベース、JSON 設定、学習済みモデルは /var/lib/flod に置かれます。チェックアウト自体はここから先は単なるソースにすぎません。scripts/install.sh または scripts/update.sh を再実行すると、そこからインストール済みのコピーが更新されます。理由については Security を参照してください。
ダッシュボードはポート 8000 で提供され、インストーラーの自己署名証明書が配置されると HTTPS 経由になります。これが依存するネットワークレイアウトを含む完全な手順は wiki にあります。
インストーラーはまた、可能な場合は eBPF ビルドツールチェーンを、お使いのディストリビューションが提供する LLVM に合わせてセットアップします。この部分は任意です。これがなくてもセンサーは libpcap 上でビルドおよび実行できます。
センサーには 2 つのキャプチャバックエンドがあります。libpcap がデフォルトで、どこでも動作します。ツールチェーンが整っていれば、--capture-mode kernel は代わりに XDP と TC を介してドライバパスでパケットをカウントし、パケットごとではなくウィンドウごとに 1 回ユーザー空間を起床させます。検出結果はどちらでも同一です。
検出のチューニングは推測ではなく計測によって行われます。scripts/calibrate.py はセンサー自身のログを読み、通常のトラフィックをサンプリングし、あなたのネットワークにおいて異常境界がどこにあるべきかを割り出します。
何もインストールせずに試すには、作業コピーから実行してください:
sudo bash scripts/run.sh
必要な値をそれぞれ尋ね、すべてにデフォルト値を用意し、Stage 2 も開始するかどうかを尋ねます。何も尋ねられずにすべてを受け入れるには --defaults を追加します。
テストスイートを実行するには:
scripts/test.sh
Wiki、システムの実行方法:
| ページ | 内容 |
|---|---|
| インストール | 要件、ネットワーク配置、初回ログイン |
| 設定 | センサーフラグ、適用のチューニング、アラート |
| ダッシュボードガイド | コンソール内のすべてのページ |
| トラブルシューティング | 何かが動作していないとき |
docs/、システムを理解または変更するために:
| ドキュメント | 内容 |
|---|---|
| アーキテクチャ | パイプライン、スレッディング、キャプチャのチューニング、外向き通信の測定 |
| 検出 | Welford、EWMA、エントロピー、異常境界、ベースラインの永続化 |
| 解説 | すべての用語とすべてのワイヤフォーマットのフィールドを、非技術者向けに解説 |
| IPC | 特徴ベクトルのワイヤフォーマット |
| 適用 | 分類、4つの緩和ティア、NAT の扱い |
| プレイブック | 4つのティアの上に重ねる、オペレーター定義のトリガー/ステージシーケンス |
| アラート | Discord、メール、Telegram、およびその他すべてのための汎用 webhook |
| トレーニング | ラベル付きデータのキャプチャとモデルのトレーニング |
| テスト | 両方のテストスイートの実行 |
| セキュリティ | ハードニングの実施と脅威モデル |
| ロードマップ | 完了済みおよび計画中のバージョン |
| ベンチマーク結果 | FLOD 対固定しきい値: ハードウェア、方法論、完全な出力 |
| ライブベンチマーク | デプロイ済みゲートウェイに対する7フェーズのトラフィックキャンペーン |
| バックエンドベンチマーク | スループット、CPU、レイテンシ、切り替えにおけるカーネルと libpcap の比較 |
| 教訓 | 開発中に見つかった実際のバグ、一般化できる点を残すために保存 |
CONTRIBUTING.md は開発環境のセットアップと規約を扱っています。 SECURITY.md は脆弱性の報告を扱っています。
このプロジェクトは私自身のものです。コンセプト、アーキテクチャ、2段階設計、 検出アプローチ、適用ポリシー、特徴セット、そしてすべてのバージョンにわたる あらゆる機能上の決定は、私に由来します。私はこれをネットワークセキュリティ、 統計的検出、システムプログラミングの学習課題として構築し、その設計と進化を 一貫して主導しました。
実装中は AI をコーディングアシスタントとして使用し、私の仕様に従ってコードを 書いたりリファクタリングしたりし、設計上のトレードオフを検討する際の相談相手 としても活用しました。何を、なぜ構築するか、そしてシステムがどう振る舞うべきか についての決定は私のものでした。
個人的なオープンソースプロジェクトであり、動作するシステムですが、本番の セキュリティ製品に必要な敵対的テストを経たものではありません。 ラボネットワーク、あるいは誤動作しても許容できる場所にデプロイしてください。
ダッシュボードには3つの選択可能なデザインファミリーがあり、V10 時点で オペレーター定義のプレイブックも備えています。詳しくはロードマップを参照してください。
LICENSE を参照してください。