導入背景：従来のファイアウォールだけでは不十分な理由
firewalldを起動し、不要なポートをすべて閉じてSSHポートを2222に変更しただけで、サーバーのセキュリティは万全と言えるでしょうか。答えは否です。SQLインジェクションやLog4j、リモートコード実行（RCE）の脆弱性を狙った攻撃リクエストは、通常の80番や443番ポートを難なくすり抜けます。iptablesやfirewalldのようなL3/L4ファイアウォールは、送信元IP、宛先IP、ポート番号しか検証しません。パケット内部のペイロード情報に対しては完全に盲目なのです。
そこで不可欠となるのが、ディープパケットインスペクション（DPI: Deep Packet Inspection）機能を備えたNIDS/NIPS（ネットワーク侵入検知／防御システム）です。
自社で300〜500Mbps規模のトラフィックを処理するCentOS Stream 9ゲートウェイクラスタを構築した際、私はメインの防御層としてSuricataを選定しました。シングルスレッド動作でCPUボトルネックに陥りやすいSnort 2.xとは異なり、Suricataは16〜32コアのマルチコアサーバーでも極めてスムーズにスケールします。AF-PACKET機構によって負荷が均等に分散されるため、急激なトラフィック急増時でもパケットドロップの心配がありません。
CentOS Stream 9へのSuricataのインストール
SuricataはCentOS Stream 9のEPELリポジトリで提供されています。ただし、依存ライブラリを漏れなく取得するため、事前にCRB（CodeReady Builder）リポジトリを有効化しておく必要があります。
システムを更新し、必要なリポジトリを有効化します：
dnf update -y
dnf config-manager --set-enabled crb
dnf install -y epel-release epel-next-releaseSuricataパッケージ本体と、ログ解析・チューニングに役立つ2つの補助ツール（JSONログ処理用のjq、NICパラメータ調整用のethtool）をインストールします：
dnf install -y suricata jq ethtoolインストール完了後、組み込まれているビルド情報を確認します：
suricata --build-info特にAF_PACKET、PCRE、Libnetfilter_queueの3項目に注目してください。すべてYESと表示されていれば、IDSモード（パッシブ監視）とIPSモード（NFQUEUEによるインライン遮断）の双方に対応できる準備が整っています。
Suricataの詳細設定：IDSモードとルールの取得
1. ネットワークインターフェースと内部サブネットの確認
利用可能なネットワークインターフェース一覧を確認します：
ip -br addrここでは、外部トラフィックを受信するNICがeth0、保護対象となる内部サーバーのIPレンジが192.168.1.0/24であると仮定します。
2. 設定ファイル suricata.yaml の編集
メイン設定ファイル/etc/suricata/suricata.yamlを開きます：
nano /etc/suricata/suricata.yaml主に変更すべき重要なポイントは以下の2箇所です：
内部サブネット（HOME_NET）の定義： デフォルトのanyのまま運用するのは避けてください。保護対象のIPレンジを正確に指定することで、トラフィックの方向性をSuricataが正しく認識し、誤検知（False Positive）を大幅に低減できます：
vars:
address-groups:
HOME_NET: "[192.168.1.0/24, 10.0.0.0/8]"
EXTERNAL_NET: "!$HOME_NET"AF-PACKETキャプチャの設定： af-packetセクションまでスクロールし、interface: eth0を実際のネットワークインターフェース名に合わせて変更します：
af-packet:
- interface: eth0
cluster-id: 99
cluster-type: cluster_flow
defrag: yes
use-mmap: yes
tpacket-v3: yes3. NICのパケットオフロード機能の無効化（必須）
近年のNICは、OSへの負荷を軽減するために複数のパケットを最大64KBの大きなチャンクにまとめるLRO/GRO機能がデフォルトで有効になっています。この仕組みはCPU負荷を下げる一方で、DPIエンジンにとっては大きな障害となります。規格から外れて結合されたパケットに対してはシグネチャ照合が正常に機能せず、攻撃を見逃す原因になります。
監視対象NICのオフロード機能を直ちに無効化します：
ethtool -K eth0 rx off tx off gso off gro offCentOS Stream 9の再起動後もこの設定を永続化させるため、NetworkManagerを使用して設定を反映します：
nmcli connection modify eth0 ethtool.feature-rx off ethtool.feature-tx off ethtool.feature-gro off ethtool.feature-gso off
nmcli connection up eth04. suricata-update によるシグネチャルールの取得
Suricataにはsuricata-updateツールが標準で付属しています。このコマンドを実行すると、日々更新される4万件以上のシグネチャを含む無償のEmerging Threats Open（ET Open）ルールセットが自動取得されます：
suricata-update統合されたルールファイルは/var/lib/suricata/rules/suricata.rulesに保存されます。サービスを起動する前に、YAMLファイルのインデント崩れや構文エラーがないかテスト検証を実施します：
suricata -T -c /etc/suricata/suricata.yaml -vConfiguration provided was successfully verifiedというメッセージが表示されれば構文チェックはパスです。サービスを起動・自動起動設定します：
systemctl enable --now suricata
systemctl status suricata検証とモニタリング：ログ確認と擬似攻撃テスト
Suricataのログは/var/log/suricata/ディレクトリに出力され、主に以下の2つのファイルが重要となります：
fast.log: アラートごとに1行で簡潔に出力されるログ。tail -fによるリアルタイムの状況把握に最適です。eve.json: メタデータ、DNSクエリ、HTTPヘッダー、TLSハンドシェイク、フロー情報などが網羅された詳細なJSON形式のログ。
1. テストペイロード送信によるアラート発報テスト
複雑な攻撃ツールを用意する必要はありません。IDSコミュニティで標準的に使われているテスト用ドメインへcurlでリクエストを送信します：
curl http://testmyids.comこのWebサイトは、root権限が奪取されたサーバーのレスポンスを模したuid=0(root) gid=0(root)という文字列を返します。直ちにfast.logを確認してみましょう：
tail -n 5 /var/log/suricata/fast.logSuricataが即座に攻撃の痕跡を検知したことが確認できます：
[1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 217.160.0.187:80 -> 192.168.1.50:492842. jqを用いたリアルタイムログフィルタリング
eve.jsonには1時間あたり数万件のイベントが記録されるため、nanoやcatで閲覧するのは非現実的です。jqを活用して重要なアラートのみを抽出し表示します：
tail -f /var/log/suricata/eve.json | jq -c 'select(.event_type=="alert") | {time: .timestamp, alert: .alert.signature, src: .src_ip, dst: .dest_ip}'このように簡潔に出力されるため、GraylogやELK Stackへの転送・統合も容易に行えます：
{"time":"2026-11-05T12:00:15.123456+0700","alert":"GPL ATTACK_RESPONSE id check returned root","src":"217.160.0.187","dst":"192.168.1.50"}実践的なワンポイントアドバイス：最初からパケットをドロップするIPSモードに切り替えるのは避けてください。まずは最低でも1〜2週間ほどIDS（検知）モードで運用することをお勧めします。この期間にシステムの平常時のトラフィック挙動を把握し、ルールの微調整や、社内スキャンツール・定期バックアップ処理に対するホワイトリスト登録を行いましょう。IPSを有効化した瞬間に正規のユーザーアクセスを誤遮断してしまうトラブルを確実に防止できます。
