Snort IDS/IPS 導入ラボ

Kali Linux 上の 3 台構成の仮想ネットワークにおいて、Snort 3 を侵入検知システム（受動的モニタリング）および侵入防御システム（iptables による能動的ブロック）としてフルサイクル導入し、4 つの攻撃ベクトルに対して検証したラボです。

本ラボは、同一の 4 ベクトル攻撃チェーンを 2 回実行することで、検知と防御の運用上の違いを実証します。最初はログを記録するだけでブロックできない IDS に対して、次に正当なトラフィックを維持しながら攻撃を選択的に破棄する IDS + iptables IPS レイヤーに対して実行します。

目次

• ラボ環境
• ネットワークトポロジー
• 方法
• Snort 設定
• カスタム検知ルール
• ステージ 1 — IDS モード
• ステージ 2 — IPS モード
• IDS vs IPS — 結果の比較
• 考察
• アーキテクチャに関する注記
• リポジトリ構成
• ラボの再現手順
• 倫理的免責事項
• ライセンス

ラボ環境

ネットワークトポロジー

攻撃者と Metasploitable の間のすべてのトラフィックはアナライザーを経由するため、モニタリングとポリシー適用の両方において自然なチョークポイントとなります。

                           ┌─────────────────────────┐
                           │   Analyzer / Router     │
                           │   Kali + Snort 3        │
                           │                         │
   Attacker Kali ──VMnet9──┤ eth1: 10.10.10.1        │
   10.10.10.10             │                         │
                           │ eth0: 192.168.10.143 ───┼──> WAN (NAT)
                           │                         │
   Metasploitable 2 ─VMnet10┤ eth2: 192.168.50.1     │
   192.168.50.10           │                         │
                           └─────────────────────────┘

図を用意できたら、この ASCII スケッチを screenshots/01-network-topology.png に置き換えてください: Topology

方法

本ラボは 2 つのステージで実行され、各ステージで同一の 4 ベクトル攻撃チェーンを使用します:

1. ICMP 偵察 — ホスト発見のための ping
2. Nmap SYN スキャン — ポート列挙のための nmap -sS（1000 ポート）
3. Hydra FTP ブルートフォース — vsftpd サービスに対する認証情報攻撃
4. vsftpd 2.3.4 バックドア — CVE-2011-2523 に対する Metasploit エクスプロイト

ステージ 1（IDS） は、アナライザー上で Snort を 5 つのカスタムルールとともに受動的に実行します — アラートをリアルタイムで観察し、それでもエクスプロイトが進行することを確認します。

ステージ 2（IPS） は、外科的ドロップルールを使用する iptables 適用レイヤーと Snort を組み合わせます — ICMP ping と正当な FTP ログインが機能し続ける一方で、攻撃がブロックされることを確認します。

デプロイ前のセットアップ

1. VMware でアナライザーに 3 つの NIC を構成します（ホストオンリー 2 つ、NAT/ブリッジ 1 つ）。
2. IP フォワーディングを有効にし、アナライザーがサブネット間および WAN へのルーティングを行うように MASQUERADE + FORWARD ルールを追加します — scripts/router_config.sh を参照。
3. Snort をインストールする前に、scripts/ping_check.sh を使用して各 VM からのエンドツーエンド接続を確認します。

Snort 設定

Snort は Kali のパッケージマネージャー（sudo apt install snort -y）でインストールされ、/etc/snort/snort.conf で設定されます:

HOME_NET = "10.10.10.0/24,192.168.50.0/24"
EXTERNAL_NET = "any"

ips = {
    enable_builtin_rules = true,
    include = "/etc/snort/rules/local.rules",
    variables = default_variables
}

alert_fast = { file = true, packet = false }

HOME_NET は両方の内部サブネットをカバーするため、Snort はアナライザー上のすべてのサブネット間トラフィックを検査に値するものとして扱います。alert_fast はコンパクトな 1 行アラートを生成します（パケット単位のログ記録は過剰な量を生成するため）。

設定の検証:

sudo snort -T -c /etc/snort/snort.conf
# Result: 652 rules loaded (5 custom text + 647 built-in), 0 warnings

カスタム検知ルール

/etc/snort/rules/local.rules 内の 5 つのルール（完全なファイルは scripts/local.rules）:

ステージ 1 — IDS モード

Snort は両方の内部インターフェースでパッシブモードで実行されます:

sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 \
    -A alert_fast -l /var/log/snort/

# Watch alerts in a second terminal:
sudo tail -f /var/log/snort/alert_fast.txt

起動出力で pcap DAQ configured to passive が確認できます — Snort はすべてのパケットを監視できますが、いずれもドロップまたは変更できません。

IDS の結果

攻撃者マシンから scripts/attack_simulator.sh を実行した後:

IDS はすべてを検知したが、何も止めなかった。 これがステージ 1 の中心的な教訓です: 適用機能のない IDS は警報システムであり、鍵ではありません。人間のアナリストがアラートを読む頃には、攻撃者はすでに root を取得しています。

副次的な観察: Snort の組み込みルール（116:408、116:414）は DHCP ブロードキャストトラフィックで発火します — 悪意はありませんが、本番環境ではアラートログを実用的に保つために抑制ルールが必要です。

ステージ 2 — IPS モード

IPS レイヤーは scripts/ips_setup.sh でデプロイされます。このスクリプトは次のことを行います:

1. 既存の iptables ルールをフラッシュする
2. IP フォワーディングを再び有効にし、ベースラインルーティングを再適用する
3. 特定の攻撃シグネチャを対象とする 4 つの外科的ドロップルールを適用する
4. 継続的なログ記録のために Snort をデーモンモード（-D）で起動する

iptables ルール

IPS の結果

同じ攻撃スクリプトが攻撃者マシンから再実行されました:

通常トラフィックの維持

2 つの手動チェックにより、選択的な適用が確認されました:

• ping -c 4 192.168.50.10 → 4 パケット送信、4 パケット受信、0% ロス
• msfadmin:msfadmin を使用した ftp 192.168.50.10 → 220 (vsFTPd 2.3.4) … 230 Login successful

実行中の iptables パケットカウンターによる定量的な証拠: 2051 パケット受理、12 パケットが FTP connlimit ルールでドロップ、808 個の ICMP パケットが受理 — 数値で見る選択的な適用です。

Snort の継続的なログ記録

IPS モードでも、Snort は、iptables が後続のパケットをドロップする前に受動的検査ポイントに到達したパケットに対して SID 1000002 / 1000003 のアラートを発火し続けました — つまり、iptables がポリシー適用を、Snort が監査ログ記録を提供し、連携して動作します。

IDS vs IPS — 結果の比較

考察

シミュレートされたすべての攻撃は IDS モードで検知されたか?

はい — SID 1000001 ～ 1000004 のすべてが攻撃シミュレーション中に正しく発火しました:

• ICMP ping (1000001) — すべてのエコー/応答に対する双方向アラート。
• Nmap SYN スキャン (1000003) — ミリ秒単位で発生するアラートの洪水、特徴的な送信元ポートのランダム化。
• FTP ブルートフォース (1000002) — Hydra の並列接続試行の正確なタイムスタンプ付きの明確な監査証跡。
• vsftpd バックドア (1000004) — :) コンテンツマッチが正確なエクスプロイトバイト列を捕捉。

しかし、検知 ≠ 防御です。 vsftpd エクスプロイトは、すべてのアラートが発火している間に root Meterpreter シェルを開きました。IDS をリアルタイムで監視している SOC アナリストは侵害を目撃していたでしょう — しかし、攻撃者は数秒で root を取得しており、アラートだけでは十分ではありません。これこそが IPS が存在する運用上の核心です。

IPS は通常トラフィックを妨げずに攻撃をブロックするうえでどの程度効果的だったか?

この実装は、正当なトラフィックに対する観測可能な影響ゼロで完全な攻撃緩和を達成しました。その効果は外科的なルール設計に由来します — 各 iptables ルールは広範なプロトコルではなく行動シグネチャを対象としています:

• SYN レート制限は、通常のハンドシェイクに影響を与えずにポートスキャンのフラッドパターンを破壊します。
• 送信元ごとの connlimit は、単一セッションの FTP を妨げずにブルートフォースツールの並列性をブロックします。
• STRING マッチは、正当な FTP ログイントラフィックをフィルタリングせずに正確なエクスプロイトペイロードをドロップします。

認識されている 1 つの制限: ICMP が完全に許可されているため、攻撃者は ping で Metasploitable が稼働していることを依然として確認できます。よりセキュリティレベルの高い環境では、これはレート制限されるか、信頼できる送信元に制限されるでしょう。このラボでは、ICMP が主要な接続確認メカニズムであるため、開放されたままです。

専用 Snort マシン vs. pfSense/OPNsense プラグイン

このラボでは専用の Snort マシンを使用しています。pfSense や OPNsense などのファイアウォールアプライアンス内で Snort をプラグインとして実行する場合と比較すると:

専用アプローチの利点:

• パフォーマンスの分離 — パケット検査専用に CPU と RAM のすべてを利用可能。ルーティング、DHCP、VPN、DNS との競合なし。
• 配置の柔軟性 — IDS/IPS はインライン、SPAN/ミラーポート、または内部セグメント境界に配置して、境界ファイアウォールに到達しない東西トラフィックを監視できます。
• 完全な設定制御 — すべてのプリプロセッサ、DAQ 設定、出力プラグイン、ルール更新スケジュールを CLI で設定可能。pfSense は GUI で一部のみを公開します。
• 回復力 — IDS/IPS マシンはルーターとは独立してフェイルオープンまたはフェイルクローズできます。pfSense では、Snort のクラッシュがルーティングと検知の両方を同時に停止させます。

トレードオフ:

• 学習曲線がより急 — CLI の習熟と直接的なルールセット管理が必要。
• メンテナンスのオーバーヘッド — ルール更新、バージョンアップグレード、ログローテーションがすべて手動。

専用 Snort は、パフォーマンス、配置、カスタマイズを必要とするエンタープライズ環境にとって正しい選択です。pfSense/OPNsense プラグイン方式は、使いやすさを優先する中小企業やホームラボ環境でより理にかなっています。

アーキテクチャに関する注記

ステージ 2 は技術的には 受動的 Snort + iptables による適用であり、Snort が真のインラインモードで実行されているわけではありません — Snort 自体はログを記録し（pcap DAQ configured to passive）、iptables がレート制限、文字列マッチ、接続数に基づいてドロップを実行します。

これは正当で一般的なデプロイパターンです（多くの実世界の Linux ベース IDS/IPS スタックがこのように動作します）。自然な次のステップは、ステージ 2 を snort --daq nfq（またはインラインモードの afpacket）と Snort の reject / drop ルールアクションを使用した真のインライン構成に移行し、iptables に委任するのではなく、Snort 自体が完全なシグネチャマッチングに基づいてドロップを実行することです。

リポジトリ構成

snort-ids-ips-lab/
├── README.md                       ← this file
├── report/
│   ├── Snort-IDS-IPS-Report.pdf    ← full lab report
│   └── Snort-IDS-IPS-Report.docx   ← editable source
├── scripts/
│   ├── router_config.sh            ← IP forwarding + iptables routing
│   ├── ping_check.sh               ← connectivity verification
│   ├── attack_simulator.sh         ← 4-vector attack chain
│   ├── ips_setup.sh                ← IPS iptables rules + Snort daemon
│   └── local.rules                 ← 5 custom Snort rules (SID 1000001-1000005)
├── screenshots/                    ← report figures
├── .gitignore
└── LICENSE

ラボの再現手順

⚠️ ラボ専用です。 これらのスクリプトは、意図的に脆弱なターゲットに対して実際のエクスプロイトとブルートフォースツールを実行します。所有しておらず、テストする明示的な書面による許可を得ていないシステムに対して実行しないでください。

1. 上記のトポロジーに従って VMware に 3 台の VM を構築します（VMnet9 と VMnet10 をホストオンリーとして）。
2. アナライザーで: scripts/router_config.sh を実行し、その後 scripts/ping_check.sh を実行して完全な接続を確認します。
3. アナライザーに Snort 3 をインストールします:
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. scripts/local.rules を /etc/snort/rules/local.rules に配置し、/etc/snort/snort.conf で HOME_NET = "10.10.10.0/24,192.168.50.0/24" を設定します。
5. 検証: sudo snort -T -c /etc/snort/snort.conf — 652 ルールが読み込まれ、警告 0 になることを期待。
6. ステージ 1 — IDS:
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # In another terminal:
   sudo tail -f /var/log/snort/alert_fast.txt
   

   攻撃者マシンで: sudo ./scripts/attack_simulator.sh — アラートの発火と Meterpreter シェルを観察します。

倫理的免責事項

このリポジトリに記録されているすべての活動は、監督付きの学術学習を目的として、自己完結型の VMware 仮想ラボ環境内でのみ実施されました。外部、本番、または実世界のシステムは、いかなる形でも標的にされたり、スキャンされたり、影響を受けたりしていません。Metasploitable 2 は、セキュリティトレーニング専用に設計された意図的に脆弱な仮想マシンです。

この資料は、システム所有者からの明示的な書面による許可なしに、実際のシステムに対してこれらの活動を再現するために使用してはなりません。 許可のないポートスキャン、認証情報攻撃、またはネットワークサービスの悪用は、ほとんどの法域で違法です。

ライセンス

MIT — LICENSE を参照。ラボレポート自体は教育用の参考資料として提供されています。