Suricataとは？導入からルール作成・IPSモード運用まで【8.0対応】

Suricataは、侵入検知（IDS）・侵入防御（IPS）・ネットワークセキュリティモニタリング（NSM）を1つのプロセスで担うオープンソースのネットワーク検査エンジンです。非営利団体OISF（Open Information Security Foundation）が開発し、ライセンスはGPL、実装はCとRust、最初の正式リリースは2010年7月でした。2026年8月22日時点の安定版は2026年7月7日公開の8.0.6で、同じ日に出た7.0.17を最後に7.0系はEOL（End-of-Life）へ移りました。この記事では、Debian/UbuntuへのインストールからEVE JSONログの読み方、ルールの書き方、IPSモードでの遮断構成までを、実際に打つコマンドと設定断片で追います。

まとめ：Suricataの導入判断で先に押さえる6点

• 1つのバイナリでIDS（検知のみ）・IPS（遮断）・NSM（通信記録）を担い、どれになるかは配置と設定で決まります。
• 7.0系は2026年7月7日付でEOL。7.0.17が最終リリースで、新規構築も既存機も8.0系へ寄せる前提になりました。
• 同梱版は上流より古く、Ubuntu 24.04 LTSは7.0.3、26.04 LTSは8.0.3です。上流最新はppa:oisf/suricata-stableから入れます。
• ルールはaction・header・optionsの3要素で構成し、自作ルールのsidは1000000〜1999999から採ります。
• IPS化はNFQUEUEとAF_PACKET inlineの2方式で、後者はiptables設定なしに2本のNIC間をブリッジします。
• SuricataはTLSを復号しません。検知対象はSNIや証明書などハンドシェイクのメタデータに限られます。

以下、動作モードの整理から順に、設定ファイルとコマンドの単位で具体化していきます。

SuricataがIDS・IPS・NSMで担う役割と切り替えの判断

IDS・IPS・NSMの3モードと配置で決まる切り替えの判断

IDSモードはミラーポートやTAPから受け取ったパケットのコピーを検査し、一致したルールをアラートとして記録します。経路の外側にいるため、Suricataが落ちても業務通信に影響しません。IPSモードは経路上にSuricataを置き、dropアクションのルールに一致したパケットを破棄します。NSMは検知とは独立した機能で、フロー・DNS問い合わせ・TLSハンドシェイク・HTTPリクエスト・転送ファイルをイベントとして書き出し、事後の追跡に使います。

IDSとIPSの一般的な違いや、ファイアウォール・WAFとの守備範囲の重なりについてはIDS・IPSとは？違い・仕組み・種類とファイアウォール/WAFとの使い分けを解説で整理しています。境界の内側を信頼しない設計へ寄せている組織なら、ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説が扱う原則のうち「通信を継続的に観測する」層をSuricataが引き受ける、という位置づけになります。ここで扱う範囲はSuricata固有の設定だけです。

「スリカタ」か「スリカータ」か：名称の由来と表記を統一する基準

Suricataはミーアキャットの学名Suricata suricattaに由来するラテン語の属名です。日本語では「スリカタ」「スリカータ」の両方が使われ、定着した正式なカタカナ表記はありません。社内ドキュメントでは英字の「Suricata」に統一しておくと、コマンド名やルールファイル名との対応が崩れません。

SuricataがTLSに対してできること・できないことの線引き

SuricataのTLS向け検知キーワードは、tls.sni・tls.cert_subject・tls.cert_fingerprint・tls.alpn・tls.versionといった、ハンドシェイクと証明書のメタデータを対象にしたものです。暗号化されたペイロードを復号する機能は持ちません。「HTTPS通信の中身に含まれる攻撃文字列を検知したい」という要件は、Suricata単体では満たせないということです。

この制約は設計に直結します。外向き通信がほぼHTTPSの環境では、発火するのはTLSメタデータとDNS、平文プロトコル向けのルールが中心になります。中身まで見たいなら、前段にTLS終端するリバースプロキシやロードバランサを置き、復号後の平文区間をSuricataに通す構成が必要です。逆に言えば、経路上にTLS終端が無い環境こそ、Suricataを入れても期待した効果が出ない唯一のパターンです。

暗号化通信のバイパスが8.0でstream.bypassから分離

暗号化された通信は中身を検査できないため、Suricataは途中で追跡を打ち切って処理量を減らせます。7.0系ではこの挙動がstream.bypassと結びついており、暗号化通信だけを切り離す設定ができませんでした。8.0では両者が分離され、プロトコル単位で挙動を指定します。

app-layer:
  protocols:
    tls:
      encryption-handling: bypass   # bypass, track-only, full
    ssh:
      encryption-handling: bypass

bypassは暗号化区間に入った時点で追跡をやめ、track-onlyはフローの記録だけ続け、fullは検査を継続します。7.0系と同じ挙動に揃えるには、TLSとSSHの両方をbypassにしたうえでstream.bypassをtrueにする設定が必要です。開発版の9.0系ではQUICにも同じ形のquic.encryption-handlingが入る見込みで、暗号化プロトコルごとに処理量を調整する方向が続いています。

Suricata 8.0系のインストールとバージョン選択の考え方

ディストリビューション同梱版と上流最新版の差を選定前に確認する

aptで素直に入るSuricataは、ディストリビューションのリリース時点で固定されます。上流の最新版との開きは次のとおりです（2026年8月22日時点）。

ここで効いてくるのが、同梱版の系列が上流でまだ保守されているかどうかです。Ubuntu 24.04 LTS自体はまだサポート期間中でも、同梱の7.0.3が属する7.0系は上流の修正対象から外れました。しかもUbuntuのsuricataパッケージはuniverseに置かれており、セキュリティ更新が約束されるmainではありません。24.04 LTSで運用を続けるなら、PPAから8.0系を入れて上流の修正に追随する構成が現実的な選択になります。

7.0系のEOLと8.0系のサポート期間をEOL方針から読む

OISFは公開のEOL方針を持っています。メジャーバージョンは2年に1回、各ブランチは初回安定版から3年間サポートされ、パッチリリースは平均して2か月に1回ほど出る、という設計です。ブランチが重なる1年間が移行の窓になります。2026年8月22日時点で公開されているEOL状況は次のとおりです。

8.0.0の初回安定版は2025年7月8日でした。前述の方針をそのまま当てはめるなら、次のメジャーである9.0系は2027年半ばごろ、8.0系のEOLは2028年半ばごろという見通しになります。日付が確定した告知ではないので、計画には幅を持たせてください。ドキュメントサイトの最新版はすでに9.0.0-devを指しており、開発は進行中です。移行の窓を1年と見込むなら、8.0系への移行を先延ばしにする理由は残っていません。

PPAからの導入手順とサービス起動前に通す実務的な設定検証の方法

公式が案内している手順は次の4コマンドです。

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install suricata

suricata-stableは常に最新の安定版を、suricata-betaはリリース候補（RC）を提供します。両方を有効にすると常に最新のリリース（stableまたはbeta）が入るので、本番機ではstableだけを有効にしてください。導入後はバージョンとビルドオプションを確認します。

suricata --build-info | grep -iE "Suricata version|Hyperscan|Rust|AF_PACKET|NFQueue"
sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml -v

suricata -Tは設定とルールを読み込んで検証するだけで、パケット処理は始めません。ルールの構文エラーやYAMLのインデント崩れはここで落ちるため、サービスを再起動する前に必ず通しておきます。

8.0で変わった点と7.0系からの移行時に確認する非互換の一覧

8.0.0は2025年7月8日に公開されました。検知範囲に直接効くのは対応プロトコルの追加で、ARP・DNS over HTTPS・LDAP・Multicast DNS・POP3・TCP上のSIP・WebSocketが解析対象に加わっています。SIPはTCPでも解析されるようになり、SIP_PORTS変数が追加され、統計のsipカウンタはsip_tcpとsip_udpに分かれました。SDPパーサはSIPなど上位のパーサから呼ばれる形で動きます。ARPロガーはイベント量が多いため既定では無効です。内部ではHTTPパーサのLibHTPに加えFTP・ENIP・MIMEの解析がRustへ移され、suricatascとsuricatactlもRust実装に置き換わりました。Lua 5.4が同梱されサンドボックス内で実行されるようになり、以前は明示的な有効化が必要だったLuaスクリプトが既定で使えます。

7.0系からのアップグレードでは非互換の変更を先に確認します。ssh.protoversionとssh.softwareversionは削除されたため、これらを使う自作ルールは書き換えが必要です。threadingのCPUアフィニティ設定はリスト形式から辞書形式へ変わりました。stream.checksum-validationをnoにしていてもチェックサム系キーワードの判定は独立して働くようになり、tcpv4-csum: invalidのようなルールが7.0系と違う挙動を見せます。requiresキーワードに未知の要件を書いたルールは読み込まれません。EVE JSONではstats.whitelistがstats.scoreへ改名されています。NapatechとPF_RINGはプラグインに切り出されました。7.0系のyamlをそのまま流用すると起動しないか、意図した並列度が出ません。

AF_PACKETの既定値も動いています。inline構成でcluster_flowを使う場合はdefragが既定でオフ、非inlineではtpacket-v3が既定になり、ブロックサイズは32kから128kへ引き上げられました。メモリ使用量はその分増えるので、センサを多数のインターフェースに張っている環境では実測してから本番へ入れます。TPACKET_V2側にはv2-block-sizeが新設され、旧来の値へ戻せます。

その先の9.0系で来る変更も、いま設計に織り込んでおけば手戻りを減らせるでしょう。開発版のドキュメントでは、非推奨だったhttp-log出力の削除、stream.reassembly.depthを明示しなかった場合の既定が無制限から1MiBへ変わる点、ether.ether_typeをネットワークバイト順で記録する点、アラートのreject-targetキーがreject_targetへ変わる点、統計のプロトコル名でハイフンがアンダースコアへ揃う点が挙がっています。ログを機械処理しているなら、後ろの2つはパーサの修正が要ります。

採用前に確認する公式サポート階層とTierごとの保証範囲の読み方

Suricataは対応環境をTierで公開しており、同じ機能でもCIとQAの手厚さが違います。ここを見ずに構成を決めると、動くには動くが問題が起きたときに一次サポートの外側だった、という事態になります。8.0.6のドキュメントに載る階層は次のとおりです。

本記事で扱うNFQUEUEとAF_PACKET inlineは、どちらもTier 1に入ります。一方でDPDKやPF_RING、eBPF/XDPと組み合わせたAF_PACKETはTier 2で、CIはあってもQAは通っていません。AF_XDPとNFLOGはコミュニティ支援、Napatechはベンダ支援、IPFWは保守されていない扱いです。10Gbps超の環境でDPDKを検討するときは、この階層差を織り込んだうえで自前の検証工数を積んでおきます。

ディストリビューションの一覧では、Tier 1にRHEL/CentOS 7、RHEL/Alma/Rocky 8と9、Ubuntu 20.04と22.04、Debian 10・11・12、FreeBSD 12と13が並びます。Ubuntu 24.04以降はこの表にまだ反映されていません。表に載っていないことは動かないことを意味しませんが、CIで毎回検証される組み合わせではない、という読み方が妥当です。アーキテクチャはx86_64とARM8-64bitがTier 1で、後述するパターンマッチングエンジンの選択にも関わってきます。

suricata.yamlで最初に触る設定とEVE JSONログの読み方

HOME_NETと監視インターフェースの指定で決まる方向判定

インストール直後に手を入れるのは、監視対象ネットワークの定義とキャプチャ対象インターフェースの2箇所です。ルールの多くは$HOME_NETと$EXTERNAL_NETで方向を判定するため、既定のままだと内外の判定がずれ、アラートが出ないか出すぎる状態になります。

# /etc/suricata/suricata.yaml
vars:
  address-groups:
    HOME_NET: "[192.168.0.0/16,10.0.0.0/8]"
    EXTERNAL_NET: "!$HOME_NET"

af-packet:
  - interface: eth0
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

cluster-type: cluster_flowは、同一フローのパケットが必ず同じスレッドへ届くようカーネル側で振り分ける設定です。SuricataはTCPストリームを再構築してから検査するため、フロー単位で束ねないと再構築が壊れ、検知漏れが起きます。

EVE JSONのイベント種別と初動調査で最初に実行するjqの操作

Suricataの主力の出力形式はEVE JSONで、1行1イベントとして書き出されます。typesで有効にした種別だけが記録されます。

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert
        - http
        - dns
        - tls
        - flow
        - files

alertはルール一致、flowは通信の開始と終了・転送量、dnsとtlsとhttpはそれぞれのプロトコルのメタデータです。調査でまず使うのは、アラートだけを抜き出して署名名と送信元を並べる操作になります。

sudo jq -c 'select(.event_type=="alert") | {ts:.timestamp, sig:.alert.signature, sid:.alert.signature_id, src:.src_ip, dst:.dest_ip}' /var/log/suricata/eve.json | tail -n 20

ここで得たsignature_idが、後述する誤検知の抑制やルール無効化に指定する値です。長期保管して横断検索したい場合はSIEMへ転送する構成です。製品の選定基準はSIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説【2026年時点】にまとめています。SIEM製品を入れる前に自前のログ基盤へ寄せる段階なら、Fluentdを用いた監査ログシステムの基本アーキテクチャ設計と運用フローの全体像を徹底解説する完全ガイドで扱う収集・保管の設計がそのまま当てはまります。

pcapを入力にした検知の再現テストで繰り返す3行の実行手順

ルールを追加したとき、本番トラフィックが流れてくるのを待つ必要はありません。Suricataはpcapファイルを入力にできるため、保存済みのキャプチャに対してルールを当て直せます。

mkdir -p ./out
sudo suricata -c /etc/suricata/suricata.yaml -r /var/tmp/sample.pcap -l ./out
grep -c '"event_type":"alert"' ./out/eve.json

-rでpcapを読み、-lでログの出力先を分離します。-lに渡すディレクトリは存在しないとSuricataが起動時に落ちるため、1行目のmkdirが要ります。本番のログディレクトリを汚さずに検証できるので、ルール修正のたびにこの3行を回すのが最短です。オフラインpcapでの実行は公式のTier 1に入る動作モードなので、検証手順としての安定性も担保されています。キャプチャの中身を目で追う工程では、AIにpcapを読ませるWireshark MCPとは｜AIにパケット解析をさせるMCPサーバーの仕組みと導入手順の方法も併用できます。

ルールの構文とsuricata-updateによる更新運用の設計

ルールを構成するアクション・ヘッダ・オプション3要素の読み方

Suricataのルールは、アクション・ヘッダ・オプションの3要素でできています。公式ドキュメントが例示しているルールは次のとおりです。

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP GET Request Containing Rule in URI"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"rule"; fast_pattern; classtype:bad-unknown; sid:123; rev:1;)

先頭のalertがアクション。一致したときの動作を示す指定です。続くhttp $HOME_NET any -> $EXTERNAL_NET anyがヘッダで、プロトコル・送信元・宛先・方向を指定します。括弧内がオプションで、http.methodやhttp.uriのような検査対象バッファの切り替え、contentによる文字列一致、sidやrevといったメタ情報が並ぶ構造です。fast_patternはそのcontentを事前フィルタとして優先的に使う指示で、ルール数が増えたときの性能に効いてきます。

自作ルールのsid採番範囲と競合を避ける配置先ファイルの決め方

sidは登録レジストリで範囲が管理されており、1000000〜1999999がローカル用途に予約されています。自作ルールはこの範囲から採番しないと、将来取り込んだ配布ルールセットと衝突します。2200000〜2299999はSuricata自身が出すエンジンイベント用なので使えません。

# /var/lib/suricata/rules/local.rules
alert dns $HOME_NET any -> any any (msg:"LOCAL Suspicious DNS query for example.test"; dns.query; content:"example.test"; nocase; sid:1000101; rev:1;)

ルールを直すたびにrevを1つ上げておけば、どの版のルールが発火したのかをEVE JSONのalert.revから追跡可能です。8.0ではrequiresキーワードの扱いが厳しくなり、Suricataが解釈できない要件を書いたルールは読み込まれずに捨てられます。バージョン依存の記述を入れるときはsuricata -Tで読み込み件数まで見ておきます。

suricata-updateでのソース管理と無停止リロードの手順

suricata-updateは、複数のルールソースを取得してマージし、/var/lib/suricata/rules/suricata.rulesに1本化するツールです。ソースを何も設定していない状態では、Emerging Threats Openルールセットが既定で取得されます。

sudo suricata-update update-sources
sudo suricata-update list-sources
sudo suricata-update enable-source oisf/trafficid
sudo suricata-update
sudo suricatasc -c "ruleset-reload-rules"

最後のsuricatascがルールの無停止リロードです。ruleset-reload-rulesは読み込み完了まで待ち、ruleset-reload-nonblockingは待たずに戻る仕様です。最後にリロードした時刻はruleset-reload-timeで確認できます。IPSモードではサービス再起動の瞬間に通信が途切れるので、リロードで済むものを再起動に落とすと、その都度ダウンタイムを自分で作ることになります。なお8.0ではsuricatascがRust実装へ置き換わりました。Pythonモジュールとして呼んでいた自動化があるなら、そこだけ書き換えが要ります。

個別のルールを止めるには/etc/suricata/disable.confにsidやルールファイル名を書いてsuricata-updateを再実行します。既定で無効なルールを有効化するのが/etc/suricata/enable.confです。生成されたsuricata.rulesを直接編集すると次回の更新で消えるため、必ずこの2ファイル経由で管理します。

IPSモードを構成する2方式と経路へ安全に組み込むための設定手順

NFQUEUE方式：既存のiptables構成へ追加する手順

NFQUEUE方式は、Linuxのnetfilterがパケットをユーザ空間のキューへ渡し、Suricataが判定結果を返す仕組みです。すでにiptablesやnftablesでフィルタリングしているホストに追加しやすい方式です。

sudo iptables -I FORWARD -j NFQUEUE
sudo suricata -c /etc/suricata/suricata.yaml -q 0

転送トラフィックを見るならFORWARD、ホスト自身の通信を守るならINPUTとOUTPUTにルールを入れます。nftablesならqueue num 3-5 options fanout,bypassのように複数キューへの分散とbypassの指定が可能。bypassを付けると、キューを読むプロセスが居ないときパケットは次のテーブルへ進みます。Suricataが停止しても通信は流れ続ける代わりに、その間の遮断機能は働きません。なお、NFQ対応が有効かどうかはsuricata --build-infoのNFQueue supportで確認できます。

AF_PACKET inline方式：2本のNICでブリッジする設定

AF_PACKET方式では、Suricataが2本のインターフェース間でパケットをコピーします。iptablesやnftablesの設定は不要で、インターフェースが上がっていれば動作します。

af-packet:
  - interface: eth0
    threads: 1
    cluster-id: 98
    cluster-type: cluster_flow
    defrag: no
    copy-mode: ips
    copy-iface: eth1
    buffer-size: 64535
  - interface: eth1
    threads: 1
    cluster-id: 97
    cluster-type: cluster_flow
    defrag: no
    copy-mode: ips
    copy-iface: eth0
    buffer-size: 64535

copy-modeはipsとtapの2つ。ipsではdropキーワードが有効になり、一致したパケットは破棄されます。tapは遮断せず、Suricataは単なるブリッジとして振る舞います。defragをnoにしているのは、8.0からinline構成のcluster_flowでdefragが既定オフになったためです。断片化再構成で大きなフレームが生成されると、カーネル側のロードバランスが正しく効かなくなります。

公式のIPS手順はstream.inlineをautoまたはyesに設定するよう案内しています。既定がautoのため多くの場合は明示不要ですが、設定を引き継いだ環境では値の確認が必要です。遮断ルールは次のようにdropで始めます。

drop tcp any any -> $HOME_NET 22 (msg:"LOCAL SSH from outside blocked"; sid:1000201; rev:1;)

遮断による通信断リスクを抑える実務的で具体的な段階導入の3ステップ

IPSモードの本質的なリスクは、検知精度ではなく可用性です。AF_PACKET inlineでSuricataのプロセスが停止すると、2本のNIC間でパケットをコピーする主体が居なくなり、その経路の通信は完全に止まります。NFQUEUEのbypassのような逃げ道が構造的に無いためです。単一経路にAF_PACKET inlineを入れるのは、経路が冗長化されているか計画停止の窓が取れる環境に限るべきです。

順序としては、IDSモードでミラーポートに1〜2週間置いて誤検知を潰し、次にcopy-mode: tapで経路に入れて安定性を見て、最後にipsへ切り替えてdropルールを少数から足します。最初からETルールセット全体をdropで当てると、業務通信を巻き込んだ時点で切り戻しになり、結局IDSへ戻ることになります。

どのルールをdropへ昇格させるかは、自環境で実際に踏まれうる弱点の把握が前提になります。外部公開資産の状況が手元で整理できていないなら、脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説で整理した工程を先に通してください。そのうえで脆弱性診断・セキュリティ診断で洗い出した弱点に対応するルールから遮断へ回すと、遮断対象の優先順位が根拠を持ちます。

8.0で追加された実験的firewallモードとIPSの機能差と採用条件

テーブルと既定ポリシー：packet:filterはdropが既定

8.0では、許可リストで通しそれ以外を落とす「firewallモード」が追加されました。IPSモードが「一致したものを落とす」のに対し、firewallモードは「明示的に通したものだけ通す」設計です。有効化はsuricata.yamlの専用ブロックで行います。

firewall:
  enabled: yes
  rule-path: /etc/suricata/firewall/
  rule-files:
    - firewall.rules

ルールはテーブルに分類され、テーブルごとに既定ポリシーが決まっています。パケット層のpacket:pre_flowとpacket:pre_streamは既定がaccept:hook、packet:filterは既定がdrop:packetです。アプリケーション層のapp:filterはプロトコルと状態ごとに分かれ、既定はdrop:flowになります。つまりpacket:filterやapp:filterにルールを1本も置かないまま有効化した通信は、既定ポリシーによる遮断対象です。既定ポリシー自体はfirewall.policiesで上書きでき、dropの代わりにrejectを返す指定もできます。

accept・drop・passのアクションスコープと多段の指定

firewallルールではアクションのスコープを明示します。acceptはpacket（このパケットのみ）・flow（以降のフロー全体）・hook（現在のフックのルール評価を打ち切り次のテーブルへ）・tx（現在のトランザクション）から選び、dropはpacketかflowです。acceptはfirewallルールでしか使えません。

注意したいのは、firewallルールのdropがアラートを含意しない点です。検知側のルールではdropがアラート生成を伴いますが、firewallモードではalertを二次アクションとして明示しないとイベントが残りません。passも二次アクション扱いで、効果が及ぶのは検知側のルールだけです。統計はfirewall.acceptedとfirewall.blockedで数え、firewallを通ったうえで検知側も通過したパケットはips.acceptedの加算対象です。遮断がどちらの層で起きたのかは、この2系統のカウンタで切り分けます。

実験的な位置づけを踏まえて本番採用の可否を決める具体的な判断ライン

suricata.yamlのコメントにも「experimental」と明記されており、本番の遮断をfirewallモードだけに委ねる段階ではありません。既定が拒否である以上、ルールの書き漏れがそのまま業務通信の停止につながります。検証環境で通信要件を洗い出す用途、あるいは限定されたセグメントで許可リストを固める用途に絞り、通常の遮断は従来のIPSモードで組むのが2026年8月時点の現実的な線です。ファイアウォールとは？仕組み・種類とWAF・UTMとの違い、企業の選び方を解説で整理しているアドレスとポートによる制御を置き換えるものではなく、アプリケーション層の状態まで見て通す判断を足す層だと捉えると設計がぶれません。

Snort 3との比較で見るSuricataの選びどころと移植性

この比較では「Snortはシングルスレッド、Suricataはマルチスレッド」という説明が今も広く流通していますが、これはSnort 2.x時代の話です。Snort 3は--max-packet-threads（短縮形-z）で複数のパケットスレッドを起動でき、もはや決定的な差ではありません。2026年時点で効く違いは、設定の記述形式・解析エンジンの実装・IPS化の手段にあります。

ログをそのままJSONで扱いたいならSuricataが素直です。EVE JSONは種別ごとにスキーマが決まっており、jqやログ基盤へ直接投入できます。逆に、Snort向けの設定資産やサポート契約を前提にした構成が既にあるなら、Snort 3を続ける方が総コストは低くなります。ルール言語は共通の祖先を持ち基本構文こそ近いものの、Suricata固有のキーワード（8.0で追加されたabsentやtxbitsなど）を使ったルールは移植できません。「ルールは互換だから乗り換えは容易」という前提で移行計画を立てるのは避けてください。

なお、どちらも通信そのものを見るエンジンです。アプリケーション層の攻撃をHTTPリクエスト単位で止める用途には専用製品が適します。守備範囲の切り分けはWAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説を参照してください。組織全体の管理枠組みのどこに当たるのかを言葉にしておきたい場合は、NIST CSF 2.0とは？重要インフラ以外も対象となるサイバーセキュリティ管理フレームワークの要点とメリットの「検知」機能に対応づけると、経営層への説明が通りやすくなります。

誤検知と取りこぼしを減らす運用チューニングの具体的な実務手順

誤検知の抑制：threshold.configとdisable.confの使い分け

ETルールセットをそのまま有効にすると、業務システムの正常な通信が大量のアラートを出すことがあります。ルールごと止めるのは最後の手段で、まず発生源を限定して抑制します。

suppress gen_id 1, sig_id 2002087, track by_src, ip 209.132.180.67

trackにはby_src・by_dst・by_eitherの指定が可能です。この書き方なら特定の監視サーバやバックアップ機からの通信だけを対象外にでき、他の送信元からの同じ攻撃は検知され続けます。ルール自体が自社環境で無意味だと判断できた場合にだけ、disable.confにsidを書きます。

パケットロスはstats.logのkernel_dropsで比率を見る

「アラートが出ない」原因は、ルール不足ではなくパケットの取りこぼしであることがあります。検査前に落ちたパケットは、どんなルールを足しても検知されません。

grep -E "capture.kernel_packets|capture.kernel_drops" /var/log/suricata/stats.log | tail -n 6

kernel_dropsがkernel_packetsに対して無視できない比率なら、処理が追いついていません。対処はスレッド数とcluster-typeの見直しが先で、次がパターンマッチングエンジンの切り替えです。

sudo suricata -c /etc/suricata/suricata.yaml -i eth0 --set mpm-algo=hs --set spm-algo=hs

既定値はautoで、利用可能ならHyperscanが選ばれます。ただしHyperscanが対象とするのはx86系アーキテクチャ（公式表記は “Intel x86 based processor architectures”）です。ARMではvectorscanがドロップイン代替になります。vectorscanはHyperscanと同じlibhsを提供するため、suricata --build-infoの表示はどちらもHyperscan support: yesです。実体の判別はパッケージの依存関係（Debian系ならlibvectorscan5かlibhyperscan5か）で行います。

アラートを見る担当者が不在の環境で導入が失敗に終わる主な理由

導入を見送るべき条件を1つ挙げるなら、アラートを受け取って調査する担当が決まっていない環境です。ETルールセットは初期状態で数万件規模のルールを読み込み、アラート件数はトラフィック量に比例して増えます。トリアージの手順を決めないまま入れた3か月後には、ログローテーションだけが回っている状態です。監視体制の設計はSOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】で扱っています。

逆に、採用してよい条件も条件付きで言い切れます。ミラーポートかTAPが取れる経路があり、EVE JSONを保管する先が決まっており、週に1回でもアラートを見る当番が置けるなら、IDSモードでの導入は費用対効果が合います。ここに遮断まで足すのは、対象セグメントの通信要件が文書化され、切り戻し手順が用意できてからで十分でしょう。3つのうち1つでも欠けるなら、まずNSMとして通信記録だけを取り、検知は後から重ねる順序を選んでください。

よくある質問

WindowsでもSuricataを動かせますか？

動きます。公式がエンドユーザ向けにWindowsインストーラ（MSI）を用意しており、suricata.io のダウンロードページから入手します。2026年8月22日時点で配布されているのは64bit版のSuricata-8.0.6-1です。ライブキャプチャにはNpcapが、IPSモードにはWinDivertが別途必要です。MSYS2環境でソースからビルドする場合はmake install-confとmake install-fullが正しく動作しないと公式ドキュメントに明記されているため、設定ファイルを手動で配置することになります。なおWindows/MinGW64はサポート階層でTier 2に置かれています。

Dockerで試すことはできますか？

できます。Docker Hubで配布されているjasonish/suricataイメージが広く使われています。インターフェースの監視に必要なのは、ホストのネットワーク名前空間と特権。--net=hostに加えてnet_admin・net_raw・sys_niceのケーパビリティを付与します。/etc/suricataを空のボリュームとしてマウントすると、既定の設定一式が生成されます。

Suricataの利用に費用はかかりますか？

Suricata本体はGPLで公開されており、ライセンス費用はかかりません。suricata-updateが既定で取得するEmerging Threats Openルールセットも無償です。実際のコストは、パケットを取りこぼさないCPUとNICを備えたサーバ、ログの保管先、アラートを見る人の工数に発生します。

既存のファイアウォールやWAFがあってもSuricataは必要ですか？

役割が異なります。ファイアウォールは通信の可否をアドレスとポートで判断し、WAFはHTTPリクエストの内容を検査してWebアプリケーションへの攻撃を止めます。Suricataが埋めるのは、通過を許可した通信の中で何が起きているかを記録し、既知の攻撃パターンやマルウェアの通信を検知する層です。NSMのイベント記録は、インシデント後に「いつ・どこと・どれだけ通信したか」を遡る手がかりになります。

SuricataのアラートをSIEMに集約するにはどうしますか？

EVE JSONは1行1JSONなので、ファイルを追尾して転送するエージェントを置けば済みます。Suricata側の変換は不要で、eve-logのtypesで転送したい種別だけを有効にして流量を抑えます。全種別を有効にするとflowイベントが大半を占めて取り込みライセンスを圧迫しがちなので、まずはalert・dns・tlsに絞るのが現実的です。Elasticsearch/Kibana（ELK）で可視化する場合も同じで、eve.jsonを追尾するシッパーを1つ置けば足ります。

7.0系のまま運用を続けても問題はありませんか？

7.0系は2026年7月7日にEOLへ移り、7.0.17が最終リリースになりました。以降は脆弱性が見つかっても上流の修正が出ません。ディストリビューションのバックポートに頼る形になりますが、Ubuntuのsuricataパッケージはuniverse収録で、セキュリティ更新が約束される区分ではありません。検知エンジン自体が攻撃対象になりうる位置に置かれる以上、8.0系への移行を優先する判断が妥当です。移行時の非互換は本記事の移行章にまとめています。

10Gbps級の回線でも取りこぼさず処理できますか？

回線速度ではなく、実効のパケット毎秒とルール数、そしてCPUコア数で決まります。判断材料はstats.logのcapture.kernel_dropsで、ここが増えないコア数までthreadsを上げるのが基本です。AF_PACKETで足りない場合の選択肢がDPDKやPF_RINGですが、どちらもサポート階層ではTier 2で、CIはあってもQAは通っていません。導入するなら自前の負荷試験を工程に組み込んでください。8.0でAF_PACKETのブロックサイズが128kへ増えた分、メモリ消費も実測しておきます。

関連記事

• IDS・IPSとは？違い・仕組み・種類とファイアウォール/WAFとの使い分けを解説
• WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説
• SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説【2026年時点】
• SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】
• ファイアウォールとは？仕組み・種類とWAF・UTMとの違い、企業の選び方を解説
• ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説
• Wireshark MCPとは｜AIにパケット解析をさせるMCPサーバーの仕組みと導入手順