Linux環境におけるSuricata IDS/IPSの導入・設定ガイド：ネットワークトラフィック監視とリアルタイム攻撃遮断の実践 - ITFROMZERO - Share tobe shared! LinuxにおけるパッシブIDSとインラインIPSのアーキテクチャ比較とSuricataの導入解説。NFQUEUEを用いた設定手順、ルールセットの最適化、リアルタイム攻撃遮断テストまで実践的に紹介します。

Table of Contents

LinuxにおけるSuricataの導入モデル比較

侵入検知・防止システム（IDS/IPS）を構築する際、最も重要な判断となるのがネットワークトポロジの選定です。Suricataを外部からのオブザーバーとしてパッシブに配置するのか、それとも各パケットに対して直接介入させるのか。現在、主に3つのアーキテクチャが存在します：

パッシブIDSモデル（AF_PACKET / SPANポート経由のスニッフィング）：ネットワークインターフェースカード（NIC）がスイッチのSPANポートまたはTAPからミラーリングされたトラフィックを受信します。Suricataはバックグラウンドでパケットを読み取り、解析します。マルウェアやポートスキャンを検知した場合、システムはアラート（alert）ログを記録するのみとなります。
従来のインラインIPSモデル（NFQUEUE / iptables）：Netfilterファイアウォールを通過するパケットがユーザー空間のキュー（NFQUEUE）に転送されます。Suricataはルールセットに基づいてパケットを検証し、その後エンジンが判定コマンドを発行します：ACCEPT（通過許可）または DROP（即時切断）。
eBPF/XDPを活用したモダンIPSモデル：カーネルスタック経由でパケットをユーザー空間へ転送する代わりに、SuricataはeBPFバイトコードをNICのドライバ層（XDP）へ直接ロードします。悪意のあるパケットは、CPUの処理サイクルを消費する前にハードウェアに近い層で即座に破棄されます。

各アーキテクチャのメリット・デメリット分析

いずれの方式も、システムの安全性とサーバーリソースとの間でトレードオフが存在します：

1. パッシブIDS（AF_PACKET）

メリット：システムの稼働率（アップタイム）を最大限に維持できます。Suricataが高負荷状態に陥ったりクラッシュしたりしても、Webサーバーやデータベースは通常通り稼働を継続します。ネットワークのレイテンシ増加もゼロです。
デメリット：進行中の攻撃を自動的に遮断することはできません。ダッシュボードにSQLインジェクションのアラートが表示された時点で、既にデータが漏洩している可能性があります。管理者は後からIPをブロックするために、自作スクリプトの実行やfail2banの設定を行う必要があります。

2. NFQUEUE経由のインラインIPS

メリット：エクスプロイトを即座に阻止できます。悪意のあるパケットはゲートウェイで直ちに破棄され、Nginxなどのリバースプロキシやバックエンドサービスに到達することはありません。
デメリット：カーネル空間とユーザー空間を行き来するため、リクエストごとに約0.2ms〜1.5msのネットワーク遅延が発生します。Suricataがハングアップした際にバイパス用のフェイルセーフフラグを有効にし忘れていると、サーバーのネットワークが完全に遮断される恐れがあります。

3. eBPF/XDPによるインラインIPS

メリット：圧倒的な処理速度を誇ります。10GbEポート環境下で毎秒500万〜1000万パケット（pps）のフィルタリングが可能で、レイヤー4のDoS攻撃を瞬時に無力化します。
デメリット：Linuxカーネル5.4以降が必須となります。また、NICドライバがネイティブXDP（Intel ixgbe/i40eやMellanoxなど）に対応している必要があります。シグネチャのデバッグ手順もNFQUEUEに比べて複雑になります。

本番環境にはどの構成を採用すべきか？

本番サーバークラスタにおける安全な導入ロードマップとして、以下の2フェーズアプローチを推奨します：

第1週目：パッシブIDSモードで運用します。実際のトラフィック環境下でSuricataを3〜7日間稼働させてください。ログファイルを詳細に精査し、連携先パートナーのWebhookや社内バックアップトラフィックによる誤検知（False Positive）をフィルタリングして除外します。
防御アクティベーションフェーズ：--queue-bypassフラグを併用したNFQUEUEによるインラインIPSへ移行します。これは中規模のVPSや物理サーバー（4〜16 vCPU）における現実的かつ堅牢な選択肢です。プロセストラブル時の通信断を防ぎつつ、Webエクスプロイトを確実に遮断できます。

Ubuntu/Debian環境でのSuricata IPS導入手順

ステップ1：サーバーの準備とアカウントセキュリティの確保

ファイアウォールを変更してポートを開放する前に、アカウントのセキュリティ対策を徹底しておく必要があります。toolcraft.app/ja/tools/security/password-generator のパスワード生成ツールを使用すれば、sudo権限を持つユーザー用の強力なランダムパスワードを生成できます。このツールはブラウザ上で直接処理され、ネットワーク経由でデータが送信されないため、よりセキュアにSSH設定を行えます。

# リポジトリの更新と必要な依存ライブラリのインストール
sudo apt update && sudo apt upgrade -y
sudo apt install -y software-properties-common curl libpcap-dev libnetfilter-queue-dev jq

ステップ2：公式PPAからのSuricataインストール

Ubuntuの標準リポジトリで提供されているSuricataパッケージは古い場合が多いため、最新のエンジン更新やバグ修正を取り込むにはOISFの公式PPAを使用することをおすすめします：

sudo add-apt-repository ppa:oisf/suricata-stable -y
sudo apt update
sudo apt install -y suricata

SuricataがNFQUEUEモジュールを組み込んでビルドされているか確認するために、以下のコマンドを実行します：

suricata --build-info | grep -E "NFQueue|AF_PACKET"

ターミナルに NFQueue support: yes と表示されれば、システムはIPSモードで動作させる準備が整っています。

ステップ3：設定ファイル（suricata.yaml）のチューニング

メイン設定ファイルを開きます：

sudo nano /etc/suricata/suricata.yaml

以下の3つの重要項目を確認・設定してください：

保護対象ネットワーク範囲（HOME_NET）の定義：誤検知を防ぐため、内部サブネットまたはサーバーのパブリックIPを正確に入力します：
```
vars:
  address-groups:
    HOME_NET: "[192.168.1.0/24, 10.0.0.0/8, 203.0.113.15/32]"
    EXTERNAL_NET: "!$HOME_NET"
```
nfqキューの設定：nfq:ブロックを探し、キュー番号（queue number 0）が正しく割り当てられていることを確認します：
```
nfq:
  mode: accept
  repeat-mark: 1
  repeat-mask: 1
  route-queue: 2
```
EVE JSONログ形式の有効化：eve-logを有効化して、Suricataがすべてのアラート、DNSクエリ、HTTPメタデータを /var/log/suricata/eve.json に出力するようにします。このログファイルはELK、Grafana Loki、Vectorへの直接取り込みに対応しています。

ステップ4：Emerging Threats（ET Open）ルールセットの更新

Suricataには、最新のシグネチャをダウンロードするためのツール suricata-update が統合されています：

# OISFリポジトリから最新ルールを取得
sudo suricata-update

# 利用可能な追加ルールソースを一覧表示
sudo suricata-update list-sources

デフォルトでは、ET Openのルールセットは alert アクションを使用しています。重大なアラートを自動的に drop アクションへと変換するために、/etc/suricata/modify.conf を作成します：

echo 're:drop "^alert (tcp|udp|icmp) \$EXTERNAL_NET any -> \$HOME_NET"' | sudo tee /etc/suricata/modify.conf
sudo suricata-update --modify-conf /etc/suricata/modify.conf

ステップ5：遮断テスト用ルール（Drop Rule）の作成

drop機能の動作を検証するため、外部からのPing（ICMP Echo Request）パケットを遮断するルールを作成します。/var/lib/suricata/rules/local.rules を開きます：

sudo nano /var/lib/suricata/rules/local.rules

ファイルに以下の1行を追加します：

drop icmp any any -> $HOME_NET any (msg:"LOCAL TEST - Blocked Ping Echo Request"; itype:8; sid:1000001; rev:1;)

/etc/suricata/suricata.yaml の rule-files: セクションに - local.rules が宣言されていることを確認してください。次に、設定ファイルの構文チェックを実行します：

sudo suricata -T -c /etc/suricata/suricata.yaml -v

システムに Configuration provided was successfully verified と表示されれば、設定ファイルにエラーはありません。

ステップ6：iptablesによるトラフィックのNFQUEUEへのルーティング

ここから、Suricataをメイントラフィックフローに組み込みます。Suricataが予期せず停止した場合でもサーバーの通信が途絶しないよう、--queue-bypass フラグを付与します：

# INPUTおよびFORWARDトラフィックをNFQUEUEキュー0へ転送
sudo iptables -I INPUT -j NFQUEUE --queue-num 0 --queue-bypass
sudo iptables -I FORWARD -j NFQUEUE --queue-num 0 --queue-bypass

キュー番号0にバインドした状態でSuricataをデーモンモード（バックグラウンド）で起動します：

sudo suricata -c /etc/suricata/suricata.yaml -q 0 -D

systemdで管理する場合は、/etc/default/suricata ファイルを編集して LISTENMODE=nfqueue に変更し、サービスを再起動します：

sudo systemctl restart suricata
sudo systemctl status suricata

ステップ7：遮断結果の検証とログ分析

ネットワーク内の別端末から、サーバーに対してpingを送信します：

ping 203.0.113.15

パケットは即座にブロックされ、送信元端末には Request timed out または100%のパケットロスが表示されます。サーバー側の eve.json を確認してイベントの詳細を調査します：

sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert") | {timestamp: .timestamp, src_ip: .src_ip, alert: .alert.signature, action: .alert.action}'

ターミナルに以下のような結果が出力されます：

{
  "timestamp": "2026-10-19T10:47:30.123456+0000",
  "src_ip": "192.168.1.50",
  "alert": "LOCAL TEST - Blocked Ping Echo Request",
  "action": "blocked"
}

"action": "blocked" のフィールドは、パケットがLinuxのネットワークスタックに到達する前に破棄されたことを示しています。この設計により、サーバーの可用性を維持したまま、Nmapによるポートスキャン、SSHブルートフォース攻撃、Webエクスプロイトを能動的に防御することが可能になります。