Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

フィードお問い合わせプライバシー© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
netward-standalone — 小規模なHTTPサービス向けのユーザー空間ボットおよびDDoS防御 | Kitploit
ツール/GitHubGitHub/dragon-lady/netward-standalone
防御ツールウェブプロキシと傍受情報収集ウェブセキュリティネットワークセキュリティ侵入検知アンチボット異常検知ログ分析
GitHubdragon-lady/netward-standalone

netward-standalone

小規模なHTTPサービス向けのユーザー空間ボットおよびDDoS防御

5911日前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有
リポジトリを見る
ウェブサイト

Net Ward

DDoSやボットによる悪用を無駄な労力に変える、ユーザー空間のデセプション層。

License: Apache 2.0 Python Status

Net WardはHTTPサービスの前面にリバースプロキシとして配置されます。正規のトラフィックはそのまま通過します。既知のプローブやフラッドには無害なミラー応答を返し、ボットの労力を消費させつつ、リクエストがアプリに到達することはありません — カーネルフックなし、ペイロードなし、報復なし、設計上フェイルオープンです。

Net Wardを選ぶ理由

  • 逸らす、反撃しない。 ボットは説得力のある無害なミラーに時間を浪費し、上流はリクエストを一切受け取りません。
  • ユーザー空間かつフェイルオープン。 カーネルモジュールもパケット改ざんもありません。分類、ストレージ読み取り、レンダリングのいずれかが失敗した場合、トラフィックはそのまま上流へ通過します(上流がダウンしている場合はデフォルトのミラーへ)。
  • どこにでも導入可能。 任意のHTTPサービスの前面にPythonプロセスを1つ置くだけ。ロードバランサーをここに向けるだけで完了です。
  • 設計からして誠実。 テレメトリなし、認証情報の収集なし、ローカルデータのすべてのバイトは運用者が所有します。Apache-2.0。

Dragon Ladyによる開発・保守 — github.com/Dragon-Lady · X: @answerislove2 実環境で発生するサプライチェーン攻撃やボット悪用キャンペーンを追跡する独立系セキュリティ研究者。

ウェブサイト: dragon-lady.github.io/netward-standalone


クイックスタート

python -m pip install --upgrade "netward>=0.4.12"
python -m netward --config example_config.json

バージョン0.4.12以降が、新規インストールおよびアップグレードにおける推奨ベースラインです。古いリリースも再現性のために引き続き利用可能ですが、新規デプロイでは現行リリースを使用してください。

またはソースから:

git clone https://github.com/Dragon-Lady/netward-standalone
cd netward-standalone
pip install -e .

Net Ward は listen_address で待ち受け、クリーンなトラフィックを upstream_target に転送します。


設定

サンプル設定をコピーし、上流ターゲットを編集します:

cp example_config.json config.json

Net Ward を起動する前に、upstream_target を実際の HTTP サービスに向けてください。アップストリームに到達できない場合、一致しないリクエストは生のプロキシエラーを公開する代わりに、デフォルトのミラー応答を返します。

必須フィールド:

フィールド意味
node_idこの Net Ward インスタンスの安定した名前
upstream_target保護対象の HTTP サービス
listen_addressNet Ward がバインドするホストとポート

オプションのフィールドは、ミラーの強度、ローカルストレージ、メッシュのプレースホルダー、アラートチャネル、アップストリームのタイムアウト、プローブログの保持を制御します。パターン一致またはリクエストフラッドの開始時に、アラートが SQLite に記録されます。アラートは種類、送信元、パターンごとに 5 分間重複排除されます。alert_channels リストが空の場合は stdout に送信されます。明示的な配信には stdout、email、slack、ntfy の任意の組み合わせを選択してください。送信配信はバックグラウンドで実行され、失敗したチャネルを再試行します。未配信の最近のアラートは起動時に再試行されます。

メールには alert_email、alert_smtp_host、alert_smtp_from が必要です。alert_smtp_port と alert_smtp_security(starttls、ssl、または none)を設定してください。none はループバック SMTP サーバーに対してのみ許可されます。認証が必要な場合は、alert_smtp_username と、パスワードを含む環境変数の名前を指定する alert_smtp_password_env を設定してください。Slack には alert_slack_webhook が必要です。ntfy には alert_ntfy_topic(ntfy.sh 上のトピック、またはセルフホストの完全なトピック URL)が必要です。保護されたトピックの場合は、そのベアラートークンを含む環境変数の名前を alert_ntfy_token_env に設定してください。HTTP の宛先は、ループバック以外では HTTPS を使用する必要があります。alert_timeout_secs のデフォルトは 5 秒です。Net Ward は起動時に要求された宛先を確認し、成功した配信の受領記録をアラートテーブルに保存します。アラートメッセージには送信元 IP、パターン ID、分類が含まれます。生のリクエストボディやヘッダーは含まれません。

オプションフィールドデフォルト意味
upstream_timeout_total10アップストリーム呼び出しのリクエスト全体の予算(秒)
upstream_timeout_connect3接続(DNS + TCP + TLS)タイムアウト(秒)
upstream_timeout_sock_read5アップストリームのソケット読み取り間のアイドル時間(秒)
upstream_max_concurrency64処理中のアップストリームリクエスト数
upstream_max_body_bytes8388608バッファリングされるアップストリーム応答ボディの最大サイズ(8 MiB)。これより大きいボディはデフォルトのミラーへフェイルオープンします
probe_retention_secs604800プローブログの TTL(7 日間)
probe_max_rows10000書き込み時パージ後のプローブログの最大行数
alert_timeout_secs5送信アラート配信のチャネルごとのタイムアウト(秒)

実行

python -m netward --config config.json

トポロジーの例:

コンポーネントアドレス
Net Ward127.0.0.1:8080
アップストリームアプリhttp://127.0.0.1:9000
ストレージnetward.db

ロードバランサーまたはWebサーバーをNet Wardに向けてください。可能な限り、アップストリームアプリはホストまたは信頼されたネットワークからのみ到達可能にしてください。 Net Wardをlocalhost以外から到達可能にしたい場合にのみ、listen_addressを0.0.0.0:<port>に設定してください。 Linux/macOSでは、storage_pathを誰でも書き込み可能な状態にしないでください。例: chmod 600 netward.db、または監視のために意図的に読み取りアクセスが必要な場合にのみchmod 644 netward.db。

リソース監視

Net Wardは文書化されたボックスあたりの容量を継続的に維持しますが、Pythonランタイムのメモリプールは、持続的な高負荷の後にワーキングセットの状態を保持する場合があります。継続的な高トラフィック下でNet Wardを運用するオペレーターは、プロセスのリソース使用状況を監視し、定期的にデーモンを再起動してください。例えば週次、またはRSSがベースラインの2倍を超えたときなどです。v0.5では、自動テレメトリではなく、オペレーターのフィードバックとローカルテストの観測に基づいてこのガイダンスを改善する予定です。


検証

クリーンなリクエストはアップストリームに到達するはずです:

curl -i http://127.0.0.1:8080/

既知のプローブはミラーリングする必要があります:

curl -i http://127.0.0.1:8080/wp-admin/

WordPress プローブは偽のログインページを返します。上流サービスはそのリクエストを受信しません。

ハッピーパスの例

上記の例のトポロジーでは、正常な初回実行は次のようになります:

  1. 127.0.0.1:9000 で小さな上流サービスを起動します。
  2. 127.0.0.1:8080 で Net Ward を起動します。
  3. Net Ward 経由で / をリクエストし、上流のレスポンスが返ってくることを確認します。
  4. Net Ward 経由で /wp-admin/ をリクエストし、代わりにミラーレスポンスが返ってくることを確認します。

期待される結果:通常のトラフィックは上流アプリに到達し、既知のプローブは Net Ward のミラーレイヤーによって処理されます。これは、プロキシパス、パターンマッチ、およびミラーレスポンスがすべて機能していることを示す最もシンプルなシグナルです。


オペレーターコマンド

バンドルされたベンダーパターンセットをインストールまたは更新します:

python -m netward.cli --db netward.db install-patterns
python -m netward.cli --db netward.db install-patterns --force

アクティブなパターンを一覧表示します:

python -m netward.cli --db netward.db list-patterns

データベースに書き込まずにプローブレポートを読み取ります。レポートは集計カウントです。どのプローブファミリーが発火したか、それらのファミリーがヒットしたリクエストパスの合計、および関与したソースの数が含まれます。生のIPアドレスや地理情報は出力されません。--send は同じダイジェストを配信します — パスカウントを含み、生のIPは決して含みません。出力ファイルは所有者のみアクセス可能(0600)です。

python -m netward.cli --db netward.db report
python -m netward.cli --db netward.db report --since 7d --format md --output report.md
python -m netward.cli --db netward.db report --format html --output report.html
python -m netward.cli --db netward.db report --family wordpress --top 10
python -m netward.cli --db netward.db report --send --config config.json

保存されるプローブログは7日間または10,000行に制限されます。レポートはその期間を記述し、その旨を明示します。より厳格なパターンの候補はレビュー用に表示され、インストールはされません。

パターンを無効化または再有効化する:

python -m netward.cli --db netward.db disable-pattern wordpress_admin_probe
python -m netward.cli --db netward.db enable-pattern wordpress_admin_probe

上流のサービスが /admin で実際の管理パネルを公開している場合は、Net Ward をそのサービスの前に配置する前に、generic_admin_login_probe を無効化するか、より厳密なオペレーターパターンに置き換えてください:

python -m netward.cli --db netward.db disable-pattern generic_admin_login_probe

オプションのパターン

一部のベンダーパターンは同梱されていますが、デフォルトでは無効になっています。これは、上流がパターンの対象とするプロトコル機能を同じように使用している場合、正当なトラフィックを壊す可能性があるためです。

basic_auth_probe

Authorization: Basic <base64> を介したブルートフォースによるクレデンシャルスタッフィングを捕捉します。

有効化しても安全なのは次の場合のみです: 上流が HTTP Basic 認証をまったく使用していない場合。上流が実際のユーザーからの Basic 認証クレデンシャルを受け付ける場合、このパターンを有効にするとそれらのユーザーが無限の 401 ループに陥ります — Net Ward は偽のチャレンジを返し、ブラウザは再プロンプトを出し、このサイクルが繰り返されます。

有効化:

netward-cli --db netward.db enable-pattern basic_auth_probe

再度無効化します:

netward-cli --db netward.db disable-pattern basic_auth_probe

有効化後に動作していることを確認するには:

curl -i -H "Authorization: Basic dXNlcjpwYXNz" http://127.0.0.1:8080/api/admin

401 と WWW-Authenticate: Basic realm="Restricted" を返す必要があります。アップストリームはリクエストを受信してはなりません。


セーフティモデル

Net Ward はフェイルオープンかつユーザー空間のみで動作します:

  • カーネルフックなし
  • 通常の HTTP レスポンス以外でのパケット改ざんなし
  • 敵対的ペイロードなし
  • 報復なし
  • フォンホームなし、メンテナからのテレメトリなし
  • 分類、ストレージの読み取り、またはミラーレンダリングが失敗した場合、トラフィックはアップストリームへ転送されます。アップストリームも到達不能な場合は、デフォルトのミラーが返されます。ストレージの失敗によってリクエストパスが 500 になってはなりません。
  • フェイルクローズ(Net Ward が分類または保存できない場合にトラフィックをドロップする)は実装されていません。

ミラー層は自動化された悪用をそらすためのものであり、攻撃し返すためのものではありません。

ログイン値は収集対象の製品ではありません。機密ヘッダー(Authorization、Cookie、Set-Cookie、Proxy-Authorization など)およびパスワードらしきボディやクエリのキーは、プローブがローカルデータベースに書き込まれる前に秘匿化されます。残余リスクは残ります:その他のヘッダー、非構造化ボディ、およびそれらのキー名を使用しない値は、オペレーターの管理下でローカルに保存される可能性があります。プローブログを認証情報の保管庫として扱わないでください。また、公開レポートに実際のシークレットを含めないでください。


プライバシーとローカルデータの利用

Net Ward はプロジェクトのメンテナにテレメトリを送信せず、オペレーターのトラフィックをいかなる外部目的にも使用しません。

ツールをダウンロード