
行動ベースのトラフィック分析、Random Forest分類、およびカーネルレベルのipset/iptables適用を使用した適応型2段階Layer 4 DDoS緩和ゲートウェイ。
First Line Of Defense
適応型二段階レイヤー4ボリューメトリックDDoS緩和ゲートウェイ。
作者: Abdullah Armiyao
プロジェクト: 行動トラフィック分析を用いたニアリアルタイムレイヤー4ボリューメトリックDDoS緩和のための適応型二段階フレームワーク

ほとんどのDDoS緩和は固定しきい値を使用する。1秒あたりのハードコードされたパケット数を超えて送信するものはすべてブロックする。これは両方向で失敗する。繁忙期に正当なトラフィックが急増して実際のユーザーがブロックされたり、攻撃者がぎりぎりしきい値を下回って通過したりする。
FLODは、あなたの通常のトラフィックがどのようなものかを学習し、それに合わせて自身の検出境界を移動させる。誰かが手動でしきい値を調整することなく、DDoSフラッドとフラッシュクラウド(正当な急増)を区別する。
トラフィック送信元と保護対象ホストの間のゲートウェイにインラインで配置され、問題のある送信元をカーネル内でドロップまたはスロットルする。
ダッシュボードは、ブロックしたアドレスを攻撃者として明示するため、ネットワーク構成を事前に知らない人でも、どの送信元が敵対的だったかを判断できる。スロットルされたアドレスは別途リストされる。スロットルは予防措置としても使用され、グループ全体に一度に適用されるためである。
ステージ1は、パケットパス上のRustセンサーである。保護対象ホストに向かうすべてのパケットをキャプチャし、短いウィンドウでレートと送信元の多様性を計算し、自身が維持するベースラインと比較する。算術演算のみを行うため、トラフィックの邪魔にならない。
ステージ2はPythonサービスである。ウィンドウごとに1回ステージ1からサマリーを受信し、Random Forestで分類し、ipsetとiptablesを通じてカーネルレベルの強制を発行する。Isolation Forestがすべてのウィンドウで並行して実行され、どちらのモデルも学習していないトラフィックにフラグを立て、強制を駆動するのではなく、別個のAnomalous状態として表面化される。ステージ2はWebダッシュボードも提供する。
両者はUnixドメインソケットで接続されている。
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
インストーラーはステージ1をビルドし、次にステージ2のコードと仮想環境を/opt/flod/stage2(root所有)にコピーし、そこで管理アカウントを設定する。ステージ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
必要な各値を尋ね、すべてにデフォルトを提供し、ステージ2も起動するかどうかを尋ねる。--defaultsを追加すると、尋ねられずにすべてを受け入れる。
テストスイートを実行するには:
scripts/test.sh
Wiki、システムの実行用:
| ページ | 内容 |
|---|---|
| Installation | 要件、ネットワーク配置、初回ログイン |
| Configuration | センサーフラグ、強制チューニング、アラート |
| Dashboard Guide | コンソールのすべてのページ |
| Troubleshooting | 何かが動作していないとき |
docs/、理解または変更用:
CONTRIBUTING.mdは開発セットアップと規約を扱う。 SECURITY.mdは脆弱性の報告を扱う。
このプロジェクトは私自身のものである。コンセプト、アーキテクチャ、二段階設計、検出アプローチ、強制ポリシー、特徴量セット、そしてすべてのバージョンにわたるすべての機能上の決定は私に由来する。ネットワークセキュリティ、統計的検出、システムプログラミングの学習課題として構築し、その設計と進化を一貫して指揮した。
実装中はAIをコーディングアシスタントとして使用し、私の仕様に従ってコードを書き、リファクタリングし、設計上のトレードオフを検討する際の相談相手として活用した。何を、なぜ構築するか、そしてシステムがどう振る舞うべきかについての決定は私のものである。
個人的なオープンソースプロジェクトであり、動作するシステムであるが、本番のセキュリティ製品が必要とする敵対的テストを経たものではない。ラボネットワーク、または間違っても許容できる場所にデプロイすること。
LICENSEを参照。
| ドキュメント | 内容 |
|---|
| Architecture | パイプライン、スレッディング、キャプチャチューニング、出力測定 |
| Detection | Welford、EWMA、エントロピー、異常境界、ベースラインの永続化 |
| Explainer | すべての用語とすべてのワイヤフォーマットフィールドを、非技術的な読者向けに解説 |
| IPC | 特徴量ベクトルのワイヤフォーマット |
| Enforcement | 分類、4つの緩和層、NAT処理 |
| Training | ラベル付きデータのキャプチャとモデルのトレーニング |
| Testing | 両方のテストスイートの実行 |
| Security | ハードニングパスと脅威モデル |
| Roadmap | 完了済みおよび計画中のバージョン |
| Benchmark Results | FLOD対固定しきい値: ハードウェア、方法論、完全な出力 |
| Lessons Learned | 開発中に見つかった実際のバグ、一般化できる教訓として保持 |