Fedora 17でIPS（侵入防止システム）を設定する方法
概要
Vuurmuurは人間が読みやすいルール構文をiptablesコマンドに変換するLinux用ファイアウォール管理ツールです。ログ閲覧、トラフィックの流し込み（traffic shaping）、接続の切断などの機能があります。Suricataはマルチスレッド対応のネットワークIDS/IPSで、IDSモードとIPSモード両方をサポートし、HTTPストリームからファイル抽出などを行えます。
このハウツーでは、Fedora 17に標準パッケージのみを使って、動作するIPSを構築する方法を順を追って解説します。
前提と注意点
- 作業はrootまたはsudo権限で行ってください。短く定義: IDSは受動的に検知、IPSは能動的にブロックします。
- まずIDSモードで検証してください。IPSは誤設定時に正当な通信を遮断します。重要: 本番環境ではメンテナンス時間を確保してから適用してください。
インストール
VuurmuurとSuricataをyumでインストールします。
yum install suricata Vuurmuur-daemon Vuurmuur-tuiIDSモードでSuricataを実行する
最初はパッシブなIDSモードで動かして確認します。Emerging ThreatsのSuricata向けルールを取得して /etc/suricata/rules/ に展開します。
cd /etc/suricata/
curl -O https://rules.emergingthreatspro.com/open/suricata/emerging.rules.tar.gz
tar xzvf emerging.rules.tar.gz
ln -s /etc/suricata/rules/reference.config /etc/suricata/reference.config
ln -s /etc/suricata/rules/classification.config /etc/suricata/classification.config
cp /etc/suricata/rules/suricata-1.2-prior-open.yaml /etc/suricata/suricata.yamlSuricataをテスト実行します（例: インターフェース eth0）。
suricata -c /etc/suricata/suricata.yaml -i eth0数分間放置して、/var/log/suricata/stats.log と /var/log/suricata/http.log を確認します。ブラウザで適当なサイトにアクセスしてトラフィックを発生させてください。
IPSモードでSuricataを実行する
Suricataでトラフィックを解析して能動的に処理するには、iptablesからのパケットをSuricataに渡す必要があります。Vuurmuurでファイアウォールを管理し、まずはログ用の単純ルールを追加します。
vuurmuur_confを開き、”Rules”で次のルールを追加します。
accept service any from any to any logイメージ: Vuurmuurのルール画面（以下の例）のように追加します。
次にVuurmuurに使用するインターフェースを追加します。”Interfaces”で新規インターフェースを作り、deviceに “eth0” を指定します。
終了したらvuurmuur_confを閉じます。
rsyslog設定の調整
Vuurmuurのログ出力のためにrsyslog設定を編集します。
/etc/rsyslog.conf に次を追加します。
*.debug /var/log/debug保存後、rsyslogを再起動します。
service rsyslog restartVuurmuur起動と永続化
Vuurmuurを起動します。
service vuurmuur startブート時に起動するように設定します。
systemctl enable vuurmuur.servicevuurmuur_confでログビューアを開き、トラフィックが通っているか確認します。
すべて問題なければ、Vuurmuurルールを変更してパケットをSuricataに渡すようにします。
nfqueue service any from any to anyこのルールに変更すると、全トラフィックがNFQUEUE経由で渡されます。vuurmuur_confで “apply changes” を実行してファイアウォールを更新してください。ログビューにNFQUEUEのエントリが出ます。
次にSuricataを起動します。NFQUEUEを0番（-q0）で使用する例です。
suricata -c /etc/suricata/suricata.yaml -q0ブラウザでページを開き、/var/log/suricata/stats.log と /var/log/suricata/http.log を確認して、流れているトラフィックとHTTPログが記録されることを確かめます。例としてstats.logとhttp.logの出力例を示します。
stats.log（例）:
-------------------------------------------------------------------
Date: 10/8/2012 -- 17:20:08 (uptime: 0d, 01h 39m 02s)
-------------------------------------------------------------------
Counter | TM Name | Value
-------------------------------------------------------------------
decoder.pkts | Decode1 | 3147
...（中略）...
detect.alert | Detect | 0http.log（例）:
10/08/2012-17:24:02.447292 www.howtoforge.com [] / [] Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1 [] 192.168.122.48:48396 -> 188.40.16.205:80
10/08/2012-17:24:02.544458 static.howtoforge.com [] /misc/drupal.css [] Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1 [] 192.168.122.48:52942 -> 178.63.27.110:80SuricataをCtrl-Cで停止し、/etc/sysconfig/suricata を編集してOPTIONSをデーモン向けに変更します。
OPTIONS="-q 0 -D --pidfile /var/run/suricata.pid"その後、サービス経由で起動・有効化します。
service suricata start
systemctl enable suricata.serviceトラフィックをドロップする
デフォルトのルールは多くが”alert”なので、まだトラフィックはドロップされません。IPSとしてドロップを試すには、suricata.yamlのstream設定でinlineを有効にします。
stream:
memcap: 32mb
checksum_validation: yes # reject wrong csums
inline: yes次にSuricataが読み込むルールファイル群に local.rules を追加します。
default-rule-path: /etc/suricata/rules/
rule-files:
- local.rules
- emerging-ftp.rules
- emerging-policy.rules/etc/suricata/rules/local.rules を作成し、1行で次のようなドロップルールを追加します。
drop tcp any any -> any any (msg:"facebook is blocked"; content:"facebook.com"; http_header; nocase; classtype:policy-violation; sid:1;)Suricataを再起動します。
service suricata restartその後、ブラウザで http://www.facebook.com/ にアクセスすると接続がタイムアウトするはずです。/var/log/suricata/fast.log にドロップの記録が出ます（例）。
10/06/2012-11:40:49.018377 [Drop] [] [1:1:0] facebook is blocked [] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 192.168.122.48:57113 -> 173.252.100.16:80これで基本的なIPS動作を確認できました。
運用チェックリスト
管理者向けの簡易チェックリスト:
- IDSモードで十分にログを観測したか
- NFQUEUEルールを適用する前にバックアップを取ったか（iptables-save等）
- suricata.yaml の inline と memcap を環境に合わせて調整したか
- ロールバック手順を用意しているか
セキュリティ責任者向け:
- どのルールで何をドロップするかのポリシーを文書化したか
- プライバシー（HTTPSや個人情報検査）に関する合意を得たか
受け入れ基準
- ブラウザでブロック対象にアクセスすると接続が切断されログにDropが記録されること。
- suricata の stats.log にデコードしたパケット/セッションの統計が増加していること。
- 正常なサービスに対する誤検知（false positives）が許容範囲内にあること。
テストケース（例）
- 正常系: HTTPで一般的なページにアクセスし、http.logに記録されること。
- 検出系: local.rulesで指定した文字列を含むリクエストがfast.logに記録され、クライアント側で通信が遮断されること。
- 回帰系: Vuurmuurルールを “accept” に戻して通信が復旧すること。
ロールバック手順（手早い保守時）
- vuurmuur_confでルールを元に戻す:
accept service any from any to any logVuurmuurで “apply changes” を実行。
suricata を停止:
service suricata stop- 問題が解決したら設定を再検証してからIPSモードへ戻す。
トラブルシューティングと失敗事例
いつ失敗するか（主な原因）:
- NFQUEUE番号やインターフェースの指定ミスでパケットが渡らない。
- memcapや再構築の設定不足でストリーム再構築に失敗し、パフォーマンスが劣化する。
- ルールのマッチが過剰で正当な通信を大量にブロックする。
対処法:
- suricata の起動ログと /var/log/suricata/*.log を確認する。
- Vuurmuurで一時的に “accept” ルールに戻し、問題の切り分けを行う。
- memcap を調整し、必要ならサーバー側のメモリを増やす。
代替アプローチと拡張案
- NFQUEUEを直接iptablesで設定し、Vuurmuurを使わずにSuricataに渡す。小規模な環境では簡潔。
- 最新のFedoraや別ディストリでの導入。Fedora 17は古いので、最新版ではパッケージ名やsystemdユニットが異なる可能性があります。
- ルール管理にoinkmasterやPulledPorkを導入して、ルールの自動更新/分類を行う。
運用上のヒューリスティック（簡単な考え方）
- まず観測（IDS）→ 次に限定的に封鎖（IPS）→ 最後にポリシーの拡大、の順で進める。
- 重要サービスは常にホワイトリスト化してからテストする。
- ログの量は想定以上になるため、ログローテーションと保管方針を用意する。
セキュリティ強化のヒント
- SuricataとVuurmuurのバイナリを常に最新に保つ（脆弱性対策）。
- 管理インターフェースへのアクセスを限定する（管理用ネットワークやSSH鍵で）。
- 監査ログを中央ログサーバに送る。ログ改ざんに備えて読み取り専用の保管を検討する。
プライバシーと法的注意
トラフィックを深く検査すると通信内容の参照や保存が発生します。個人情報や暗号化通信（HTTPS）の扱いに関しては社内ポリシー・法律（例: 個人情報保護法）を確認してから運用してください。
簡潔な用語集
- IDS: 受動的に攻撃を検知するシステム。
- IPS: 検知に加えて不正通信を能動的に遮断するシステム。
- NFQUEUE: カーネルがユーザ空間にパケットを渡すための仕組み。
- memcap: Suricataが再構築に割り当てるメモリ上限。
追加の参考資料
- Suricata User Guide
- rule management with oinkmaster
- Vuurmuur user guide
まとめ
Fedora 17上でVuurmuurとSuricataを組み合わせれば、比較的短時間で動作するIPSを構築できます。まずはIDSモードで観測し、ログと統計を吟味してからNFQUEUE経由でIPSモードへと段階的に移行してください。運用ではルール管理、ログ保管、プライバシー配慮が重要です。
