5分でSuricataをインストール — さっそく始めよう
10台以上のサーバーにセキュリティ監査を実施した経験から気づいたことがある：ほとんどのサーバーに共通の問題があった。ネットワークトラフィックを誰も監視していないのだ。サーバーは正常に動いているのに、毎晩ポートスキャンやブルートフォース攻撃が行われていても誰も気づかない。Suricataはまさにその問題を解決してくれる。
まずはさっとインストールして動かしてみよう：
sudo apt update
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt install suricata -y
sudo suricata --build-info | head -5
Suricata version X.X.Xという行が表示されれば、インストール完了だ。次に、使用中のネットワークインターフェースを確認しよう：
ip a | grep -E "^[0-9]+:|inet "
# インターフェース名を控えておこう — 通常はeth0またはens3
IDSモードでSuricataを起動しよう — トラフィックを監視するだけで、何もブロックしない：
sudo suricata -c /etc/suricata/suricata.yaml -i eth0 --runmode autofp -D
sudo tail -f /var/log/suricata/fast.log
簡易テストはこれで完了だ。Suricataが実際の攻撃を検知できるようにするには、ルールとネットワークの設定が必要だ — 続きを読もう。
Suricataはどのように動作するのか？
設定を始める前に、Suricataの動作モードを理解しておくと、準備が整っていない段階でIPSを誤って有効にするミスを防げる。主要なモードは3つある：
- IDS（Intrusion Detection System）：トラフィックを監視してアラートをログに記録するが、通信には介入しない
- IPS（Intrusion Prevention System）：危険なトラフィックをリアルタイムで能動的にブロックする
- NSM（Network Security Monitoring）：すべての接続のメタデータを完全に記録する
多くの人が使い慣れている従来のIDS、Snortと比べると、Suricataはデフォルトでマルチスレッドをサポートしており、マルチコアCPUをより効率的に活用できる。TLSインスペクション、HTTPロギング、ファイル抽出が標準搭載されており、追加プラグインは不要だ。ルール形式はSnortと互換性があるので、Snortからの移行もスムーズに行える。
Suricataの詳細設定
ステップ1：Emerging Threatsルールをダウンロード
ルールはSuricataが攻撃パターンを識別するための「辞書」だ。Emerging Threats Openは約45,000のシグネチャを持つ無料のルールセットで、毎日更新されている：
sudo apt install suricata-update -y
sudo suricata-update update-sources
sudo suricata-update enable-source et/open
sudo suricata-update
# 結果：約45,000件のルールが/var/lib/suricata/rules/suricata.rulesにダウンロードされる
ステップ2：メイン設定ファイルを編集する
/etc/suricata/suricata.yamlを開いて、最も重要な2つのセクションを探そう：
sudo nano /etc/suricata/suricata.yaml
HOME_NETセクション — 内部IPアドレス範囲を設定する：
vars:
address-groups:
HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
EXTERNAL_NET: "!$HOME_NET"
af-packetセクション — Suricataがリッスンするインターフェースの設定：
af-packet:
- interface: eth0 # 実際のインターフェース名に変更する
cluster-id: 99
cluster-type: cluster_flow
defrag: yes
ステップ3：設定を確認してサービスを起動する
# 起動前に構文を確認する — このステップに何度も救われる
sudo suricata -T -c /etc/suricata/suricata.yaml -v
# エラーがなければ：
sudo systemctl enable suricata
sudo systemctl start suricata
sudo systemctl status suricata
IDSからIPSへの切り替え — 実際にトラフィックをブロックする
多くのガイドが省略するステップだ。IDSはアラートを出すだけだが、IPSは実際にブロックできる。LinuxでのSuricata IPSはnfqueue（Netfilter Queue）を通じて動作する。
sudo apt install libnetfilter-queue1 -y
トラフィックをSuricataに通してから送り出すように設定する：
# トラフィックをSuricataのキューに転送する
sudo iptables -I FORWARD -j NFQUEUE --queue-num 0
sudo iptables -I INPUT -j NFQUEUE --queue-num 0
sudo iptables -I OUTPUT -j NFQUEUE --queue-num 0
# 再起動後もルールを保持するために保存する
sudo apt install iptables-persistent -y
sudo netfilter-persistent save
IPSモード（インラインモード）でSuricataを実行する：
sudo suricata -c /etc/suricata/suricata.yaml -q 0
高い授業料で学んだ教訓：本番環境に直接IPSを有効にしてはいけない。以前あるサーバーでIPSを有効化したところ、内部ロードバランサーのトラフィックまで誤ってブロックしてしまい、原因を突き止めるまで2時間のデバッグが必要だった。IPSに切り替える前に、少なくとも1週間IDSモードで運用してフォルスポジティブを観察しよう。
Suricataのログを読む・分析する
知っておくべきログファイル
Suricataはいくつかのログファイルを生成し、それぞれ異なる目的を持っている：
ls /var/log/suricata/
# fast.log → 簡潔で読みやすいアラート、リアルタイム
# eve.json → 完全なJSONログ、SIEM/ELK Stackで使用
# stats.log → Suricataのパフォーマンス統計
リアルタイムでアラートを監視する：
sudo tail -f /var/log/suricata/fast.log
# 出力例：
# 03/03/2026-10:15:32 [**] [1:2100366:7] GPL ICMP_INFO PING *NIX [**] {ICMP} 203.0.113.5 -> 10.0.0.1
アラートを種類別にフィルタリングしたい？このPythonスクリプトはeve.jsonを読み込んで、より見やすい形式で出力する：
sudo python3 -c "
import sys, json
with open('/var/log/suricata/eve.json') as f:
for line in f:
try:
e = json.loads(line)
if e.get('event_type') == 'alert':
print(f\"{e['timestamp']} | {e['alert']['signature']} | {e['src_ip']} -> {e['dest_ip']}\")
except:
pass
" | tail -20
応用：カスタムルールの作成とfail2banの統合
SSHブルートフォースを検知するカスタムルールの作成
sudo nano /etc/suricata/rules/local.rules
# SSHブルートフォースを検知：60秒以内に10回の接続
alert tcp any any -> $HOME_NET 22 (msg:"SSH Brute Force Attempt"; flow:to_server; flags:S; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-admin; sid:9000001; rev:1;)
# ポートスキャンを検知：10秒以内に50個のSYNパケット
alert tcp any any -> $HOME_NET any (msg:"Possible Port Scan Detected"; flags:S; threshold:type both, track by_src, count 50, seconds 10; classtype:network-scan; sid:9000002; rev:1;)
suricata.yamlにルールファイルのパスを追加する：
rule-files:
- suricata.rules
- local.rules # この行を追加する
fail2banと組み合わせて自動ブロックを実現する
fail2banはSuricataのfast.logを読み込み、繰り返し攻撃を行うIPを検知すると自動的にiptablesルールを追加する：
sudo apt install fail2ban -y
sudo nano /etc/fail2ban/filter.d/suricata.conf
[Definition]
failregex = ^\d{2}/\d{2}/\d{4}-\d{2}:\d{2}:\d{2}\.\d+ \[\*\*\] .* \[\*\*\].* \{TCP\} <HOST>:\d+ ->
ignoreregex =
sudo nano /etc/fail2ban/jail.d/suricata.conf
[suricata]
enabled = true
filter = suricata
logpath = /var/log/suricata/fast.log
maxretry = 3
bantime = 3600
findtime = 300
action = iptables-allports[name=suricata]
sudo systemctl restart fail2ban
sudo fail2ban-client status suricata
実運用から得た教訓
- eve.jsonは思ったより早く巨大になる：トラフィック約500Mbpsのサーバーで、2週間後にファイルが50GBに達したことがある。suricata.yamlの
eve-logセクションでrotate-interval: dayを有効にしてlogrotateと組み合わせよう — ストレージが満杯になってから夜中の3時に対処するはめにならないように - 重要な内部IPをホワイトリストに追加する：ロードバランサー、監視サーバー、バックアップエージェント — ノイズアラートを防ぐためにsuppressリストに追加しよう
- ルールを毎日自動更新する：
# 毎朝2時にルールを更新するcronジョブ
echo "0 2 * * * root /usr/bin/suricata-update && /bin/systemctl reload suricata" | sudo tee /etc/cron.d/suricata-update
- リロード前は必ずルールをテストする、例外なし：構文エラーが1つあるだけでSuricataが完全に起動を拒否する
sudo suricata -T -c /etc/suricata/suricata.yaml -v
# 出力がクリーンな場合のみリロードする
sudo systemctl reload suricata
- パフォーマンスの監視：大量トラフィック（1Gbps以上）では、4vCPUサーバーでSuricataがCPUの30〜40%を消費することがある。
stats.logを確認し、必要に応じてワーカースレッド数を増やすかルールセットを絞り込もう - SuricataをUFWと組み合わせて使う：UFWがファイアウォールを担当し、Suricataが攻撃パターンの検知を担当する — 互いに代替できない2つの独立した防御レイヤーだ
