侵入検知システム Snort の心臓部、ルールセットを理解し使いこなす
はじめに:Snortとルールセットの重要性
Snortは、ネットワークトラフィックをリアルタイムで分析し、悪意のあるアクティビティや攻撃の試みを検知・防御するためのオープンソースの侵入検知・防御システム(IDS/IPS)です。ネットワークセキュリティの分野で広く利用されており、その柔軟性と強力な検知能力が高く評価されています。しかし、Snortがその真価を発揮するためには、「ルールセット」と呼ばれる定義集が不可欠です。
ルールセットは、Snortがどのような通信パターンを「異常」または「攻撃」とみなすかを定義したルールの集まりです。いわば、Snortの「知識」や「判断基準」であり、このルールセットの質と鮮度が、そのまま検知能力に直結します。ルールが古かったり、不適切だったりすると、新たな脅威を見逃したり、逆に正常な通信を誤ってブロックしてしまう(誤検知)可能性があります。
このブログ記事では、このデフォルトルールセット(コミュニティルールセットを主軸に解説します)の入手方法、構造、設定、カスタマイズ、そして効果的な運用方法について、網羅的に解説していきます。Snortをこれから導入する方、すでに運用しているけれどルールセットについて深く理解したい方にとって、必読の内容となるでしょう。
デフォルトルールの入手と配置 📥
Snortでデフォルトルールを利用するには、まずルールセットを入手し、Snortが読み込める適切な場所に配置する必要があります。入手方法はいくつか考えられます。
1. Snort.orgからのダウンロード
最も一般的で推奨される方法は、Snortの公式サイト (https://www.snort.org/) から最新のルールセットをダウンロードすることです。Snort.orgでは、主に2種類のルールセットが提供されています。
- コミュニティルールセット (Community Ruleset):
- 無料で利用可能。
- SnortコミュニティとTalosによって作成されたルールが含まれる。
- 基本的な脅威に対応するためのルールが中心。
- 利用にはSnort.orgでのユーザー登録(無料)が必要な場合があります。
- サブスクライバルールセット (Subscriber Ruleset):
- 有料のサブスクリプションが必要(個人利用は無料の場合あり)。
- Talosによって維持され、最新の脅威に迅速に対応するためのルールが含まれる。コミュニティルールセットよりも包括的で、より早く新しいルールが提供される。
- 商用環境や、より高度な保護が必要な場合に推奨される。
通常、「デフォルトルール」という文脈では、コミュニティルールセットを指すことが多いです。Snort.orgにログインし、ダウンロードページから使用しているSnortのバージョンに合ったルールセット(通常はtar.gz形式のアーカイブ)をダウンロードします。ダウンロードには Oinkcode と呼ばれる、ユーザー固有のコードが必要になります。これはユーザー登録後に取得できます。
2. Snortインストール時のデフォルトルール
OSのパッケージマネージャー(例: apt, yum)やソースコードからSnortをインストールした場合、基本的なルールや設定ファイルのテンプレートが含まれていることがあります。ただし、これらは最新ではない可能性が高いため、本格的な運用を開始する前には、Snort.orgから最新のルールセットをダウンロードして置き換えることが強く推奨されます。
ルールファイルの配置
ダウンロードしたルールセット(tar.gzファイル)を展開すると、多数の `.rules` ファイルと、関連する設定ファイル(`*.conf`, `*.map` など)が含まれています。これらのファイルをSnortの設定ファイル (`snort.conf`) で指定されたルールパスに配置する必要があります。
一般的なルールパスは以下の通りですが、環境によって異なる場合があります。
/etc/snort/rules/
/usr/local/etc/snort/rules/
/opt/snort/rules/
ルールパスは `snort.conf` ファイル内で `var RULE_PATH` という変数で定義されています。この設定を確認し、正しい場所に展開したルールファイルを配置してください。
# snort.conf 内の例
# Setup the path to the rules files
# var RULE_PATH ../rules
var RULE_PATH /etc/snort/rules
また、ルールセットにはルールファイル以外にも `preproc_rules` や設定ファイルのスニペットなどが含まれることがあります。これらも `snort.conf` の指示に従って適切な場所に配置、または設定を反映させる必要があります。
デフォルトルールの構造 🧱
Snortのデフォルトルールセット(コミュニティルールセットなど)は、単一の巨大なファイルではなく、脅威の種類やプロトコルごとに分類された多数の `.rules` ファイルから構成されています。これにより、管理やチューニングが容易になっています。
ルールファイルの分類
ルールファイルは、その内容を示す分かりやすい名前が付けられています。以下は、コミュニティルールセットに含まれるカテゴリの例です(実際のファイル名やカテゴリはバージョンによって変わることがあります)。
カテゴリ例 | 内容 |
---|---|
app-detect.rules |
特定のアプリケーションの通信を検出するルール |
attack-response.rules |
攻撃成功後の兆候(例: 不正な応答コード)を検出するルール |
browser-*.rules |
Webブラウザに関連する脆弱性や攻撃を検出するルール (例: browser-chrome, browser-firefox) |
dos.rules |
DoS(サービス拒否)攻撃に関連するルール |
exploit-kit.rules |
既知のエクスプロイトキットに関連する通信を検出するルール |
file-*.rules |
特定のファイルタイプ(実行ファイル、画像、PDFなど)に関連する脅威を検出するルール (例: file-executable, file-office) |
malware-*.rules |
マルウェアの活動(C&C通信、ダウンロードなど)を検出するルール (例: malware-cnc, malware-other) |
netbios.rules |
NetBIOSプロトコルに関連するルール |
policy-*.rules |
組織のセキュリティポリシー違反となりうる通信(P2P、特定サービスの利用など)を検出するルール (例: policy-social, policy-other) |
protocol-*.rules |
特定のプロトコル(DNS, FTP, ICMP, SMTPなど)に関連するルール |
scan.rules |
ポートスキャンなどの偵察行為を検出するルール |
server-*.rules |
サーバーソフトウェア(Apache, IIS, MySQL, Oracleなど)の脆弱性を狙った攻撃を検出するルール |
sql.rules |
SQLインジェクション攻撃に関連するルール |
このように分類されていることで、管理者は自身のネットワーク環境や監視対象に合わせて、必要なカテゴリのルールを選択的に有効化できます。
ルールの基本構文
個々のSnortルールは、特定のフォーマットに従って記述されています。ルールは大きく分けて「ルールヘッダ」と「ルールオプション」の2つの部分から構成されます。
アクション プロトコル 送信元IP 送信元ポート 方向 送信先IP 送信先ポート (オプション)
ルールヘッダ (Rule Header):
- アクション (Action): ルールにマッチした場合にSnortが実行する動作。例:
alert
(警告ログ生成),log
(ログ記録),pass
(通信許可),drop
(通信遮断, IPSモード時),reject
(TCP RST/ICMP Port Unreachable送信, IPSモード時)。 - プロトコル (Protocol): 対象とする通信プロトコル。例:
tcp
,udp
,icmp
,ip
。 - 送信元IP (Source IP): 送信元IPアドレスまたはネットワーク。
any
(任意), 特定IP, CIDR表記,$HOME_NET
(設定ファイルで定義された内部ネットワーク) など。 - 送信元ポート (Source Port): 送信元ポート番号。
any
(任意), 特定ポート, ポート範囲 (例:1:1024
),$HTTP_PORTS
(設定ファイルで定義されたHTTPポート) など。 - 方向 (Direction): 通信の向き。
->
(送信元から送信先へ),<>
(双方向)。 - 送信先IP (Destination IP): 送信先IPアドレスまたはネットワーク。送信元IPと同様の形式。
- 送信先ポート (Destination Port): 送信先ポート番号。送信元ポートと同様の形式。
ルールオプション (Rule Options):
- 括弧
()
内に記述され、セミコロン;
で区切られる。 - ルールがマッチするためのより詳細な条件を指定する。
msg
: アラート発生時に表示されるメッセージ。必須オプション。例:msg:"MALWARE-CNC Suspicious User-Agent";
content
: パケットペイロード内で検索する文字列やバイナリパターン。例:content:"|eicar test file|";
pcre
: Perl互換正規表現 (PCRE) によるパターンマッチング。例:pcre:"/login\.php\?user=\w+/";
flow
: TCPセッションの状態(確立済みか、クライアントからか等)を指定。例:flow:established,to_server;
sid
: ルール固有の識別子 (Snort ID)。1,000,000以上はローカルルール用。例:sid:2013410;
rev
: ルールのリビジョン番号。例:rev:5;
classtype
: 攻撃の分類。例:classtype:trojan-activity;
- その他、多数のオプションが存在 (
http_uri
,http_header
,byte_test
,threshold
,detection_filter
など)。
ルール例:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"BROWSER-PLUGINS Adobe Acrobat Reader LibTIFF tiff_parse page Integer Overflow"; flow:to_client,established; file_data; content:"/Filter[/FlateDecode/DCTDecode]"; fast_pattern:only; content:"/Type/XObject/Subtype/Image"; content:"/ColorSpace"; distance:0; content:"/BitsPerComponent 8"; distance:0; content:"/Width "; distance:0; content:"/Height "; distance:0; content:"/Length "; distance:0; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, service http; reference:cve,2010-0188; classtype:attempted-user; sid:16301; rev:12;)
この例では、外部ネットワークから内部ネットワークのHTTPポートへのTCP通信で、特定のAdobe Acrobat Readerの脆弱性 (CVE-2010-0188) を狙う可能性のあるパターン(特定の文字列シーケンス)がペイロードに含まれている場合にアラートを生成します。
デフォルトルールの有効化と設定 ⚙️
ルールセットを入手し配置したら、次に `snort.conf` ファイルを編集して、どのルールを有効にするかをSnortに指示する必要があります。すべてのルールを無条件に有効にすると、パフォーマンスの低下や誤検知の増加を招く可能性があるため、慎重な選択が求められます。
snort.conf でのルール有効化
`snort.conf` ファイルには、ルールファイルを読み込むための `include` ディレクティブが記述されるセクションがあります(通常、ファイルの後半部分)。ここで、有効にしたいルールファイルへのパスを指定します。
# Step #6: Configure rule sets.
# site specific rules
# include $RULE_PATH/local.rules
# Example Community Rules (enable desired categories)
# Be selective to optimize performance and reduce noise
# include $RULE_PATH/app-detect.rules
include $RULE_PATH/attack-response.rules
# include $RULE_PATH/backdoor.rules
# include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/browser-chrome.rules
include $RULE_PATH/browser-firefox.rules
include $RULE_PATH/browser-ie.rules
# ... (other rule files) ...
include $RULE_PATH/malware-cnc.rules
include $RULE_PATH/malware-other.rules
# include $RULE_PATH/policy-other.rules
# include $RULE_PATH/protocol-dns.rules
include $RULE_PATH/protocol-icmp.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/server-apache.rules
# include $RULE_PATH/sql.rules
# include $RULE_PATH/x11.rules
上記の例では、行頭に #
が付いている行はコメントアウトされており、そのルールファイルは読み込まれません。#
を削除することで、そのルールファイルが有効になります。
ルール管理ツール (PulledPork, Oinkmaster)
ルールセットは頻繁に更新されるため、手動でのダウンロード、展開、`snort.conf` の編集は手間がかかります。そこで、PulledPork や Oinkmaster といったルール管理ツールを利用することが一般的です。
これらのツールは、以下のような機能を提供します。
- Snort.orgから最新のルールセットを自動的にダウンロード(Oinkcodeを使用)。
- ダウンロードしたルールセットの展開と配置。
- ルールセットに含まれる変更点(追加/削除/変更されたルール)の管理。
- 設定ファイルに基づいて、有効にするルールファイルや個別のルール (sid) を制御。
enablesid.conf
: 特定のsidを強制的に有効化。disablesid.conf
: 特定のsidを無効化。modifysid.conf
: 特定のsidのルール内容を変更(アクション変更など)。
- Snortの設定ファイルやプロセス再起動の自動化(設定による)。
PulledPork (https://github.com/shirkdog/pulledpork) は現在も活発に開発されており、広く使われています。これらのツールを活用することで、ルール管理の負担を大幅に軽減し、常に最新の状態でSnortを運用することが可能になります。cron などで定期的に実行するように設定するのが一般的です。
# PulledPorkの実行例 (設定ファイル pulledpork.conf が必要)
/usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -l
デフォルトルールのカスタマイズとチューニング 🔧
デフォルトルールセットは多くの一般的な脅威に対応できるように作られていますが、そのまま利用すると個々のネットワーク環境に合わず、問題が発生することがあります。最も一般的な問題は「誤検知 (False Positive)」と「パフォーマンス低下」です。これらに対応するため、ルールのカスタマイズとチューニングが必要になります。
誤検知 (False Positives) への対応
誤検知とは、実際には悪意のない正常な通信を、Snortがルールに基づいて攻撃や異常として検知してしまうことです。誤検知が多いと、本当に重要なアラートが埋もれてしまったり、IPSモードで運用している場合には正常な通信が遮断されて業務に支障をきたす可能性があります。
誤検知への対策としては、いくつかの方法があります。
- ルールの無効化:
- 特定のルール (sid) が頻繁に誤検知を引き起こす場合、そのルール自体を無効化します。
- PulledPork を使用している場合は
disablesid.conf
に該当する sid を記述します。 - 手動管理の場合は、該当ルールをコメントアウトするか、
snort.conf
にinclude
されているルールファイルから削除します(非推奨、アップデートで元に戻るため)。
suppress
キーワード:- 特定の送信元/宛先IPアドレスやネットワークに対して、特定のルール (sid) またはジェネレータID (gid) のアラートを抑制します。
threshold.conf
ファイル(または `snort.conf` 内)に記述します。- 例: sid 16301 のアラートを、IPアドレス 192.168.1.10 から発生した場合のみ抑制する。
suppress gen_id 1, sig_id 16301, track by_src, ip 192.168.1.10
thresholding
とdetection_filter
:- 特定の時間内に特定の回数以上イベントが発生した場合にのみアラートを上げるように設定します(Thresholding)。
threshold.conf
やルールオプション内で設定します。DoS攻撃やスキャン検知ルールの誤検知抑制に有効です。- 例: sid 21004 (ポートスキャン) のアラートを、60秒間に5回以上検知した場合にのみ、送信元IPごとに1回だけ上げる。
event_filter gen_id 1, sig_id 21004, type limit, track by_src, count 5, seconds 60
- ルールの修正 (Modify):
- PulledPork の
modifysid.conf
を使って、ルールのアクションをalert
からlog
に変更したり、内容を微調整したりします。(高度な知識が必要)
- PulledPork の
パフォーマンスチューニング
多数のルールを有効にすると、Snortが処理すべき計算量が増加し、CPU使用率の上昇やパケットロスの原因となる可能性があります。特に高速なネットワーク環境では、パフォーマンスチューニングが重要になります。
- 不要なルールの無効化: 最も効果的な方法です。組織の環境に関係のないプロトコルやアプリケーションのルールは無効化します。
- ホームネットワーク変数 (
$HOME_NET
,$EXTERNAL_NET
) の適切な設定:snort.conf
で内部ネットワークと外部ネットワークを正確に定義することで、ルールの適用範囲が最適化され、不要な評価を避けることができます。$HOME_NET
にany
を設定するのは避けるべきです。 - ポート変数 (
$HTTP_PORTS
,$SSH_PORTS
など) の適切な設定: 監視対象のサービスが実際に使用しているポートに合わせて変数を設定します。 - Snortの実行オプション: 実行時のオプションや設定(例: DAQモジュール、スレッド数、アフィニティ設定など)を最適化します。(環境依存性が高い)
- ハードウェアリソース: CPUパワー、メモリ容量、高速なNICなど、十分なハードウェアリソースを確保することも重要です。
- ルール記述の最適化 (上級): ルール内の
content
マッチングやpcre
の効率を考慮した記述。(ルール開発者向け)
ローカルルールの作成 (local.rules)
デフォルトルールセットを補完するために、組織固有の要件に合わせたカスタムルールを作成することが推奨されます。これらのルールは、通常 $RULE_PATH/local.rules
というファイルに記述し、snort.conf
で include $RULE_PATH/local.rules
のように読み込みます。
ローカルルールでは、以下のような目的のルールを作成できます。
- 組織内の特定のサーバーへの不正アクセス試行の検知。
- 内部ポリシー違反(特定のWebサイトへのアクセス、禁止されたアプリケーションの使用など)の検知。
- デフォルトルールセットではカバーされていない、特定の脅威や脆弱性に対応するルール。
- 誤検知を抑制するための、より限定的な条件を持つルール。
ローカルルールを作成する際は、SID(ルールID)として 1000000
以上の番号を使用します。
# 例: 内部の機密サーバー (192.168.1.100) への外部からのSSH接続試行を検知
alert tcp $EXTERNAL_NET any -> 192.168.1.100 22 (msg:"LOCAL - External SSH attempt to Confidential Server"; flow:to_server,established; classtype:attempted-admin; sid:1000001; rev:1;)
local.rules
を活用することで、デフォルトルールセットの汎用性を維持しつつ、組織固有のセキュリティ要件に対応することが可能になります。
実践的な使い方と注意点 🚀
デフォルトルールセットを効果的に活用し、Snortを安定運用するためには、いくつかの実践的なポイントと注意点があります。
定期的なルール更新の重要性
新しい脅威や脆弱性は日々登場しています。Snortの検知能力を維持するためには、ルールセットを常に最新の状態に保つことが極めて重要です。前述の PulledPork などのルール管理ツールを使用し、少なくとも1日に1回はルールを更新するプロセスを自動化することを強く推奨します。
ルール更新時には、新しいルールが追加されたり、既存のルールが変更・削除されたりします。更新後に意図しないアラートが増加したり、パフォーマンスに影響が出たりしないか、ログを注意深く監視する必要があります。
ログの監視と分析
Snortが出力するアラートログ(通常は /var/log/snort/alert
やsyslog経由で出力)を定期的に監視し、分析することが不可欠です。
- アラートの傾向把握: どのようなアラートが頻繁に発生しているか、特定の送信元/宛先からのアラートが多いかなどを把握します。
- 誤検知の特定と対応: 正常な通信が誤って検知されていないかを確認し、必要に応じて前述のチューニング(suppress, disableなど)を行います。
- インシデントの早期発見: 重要なアラートを見逃さず、セキュリティインシデントの兆候を早期に捉えます。
- ルールの有効性評価: どのアラートが実際に役立っているか、不要なアラートはどれかを評価し、ルールセットの最適化に繋げます。
大量のアラートログを手動で分析するのは困難なため、SIEM (Security Information and Event Management) システムやログ管理ツール(例: ELK Stack/OpenSearch Dashboards, Graylog, Splunk)と連携させ、アラートの集約、可視化、相関分析を行うのが一般的です。これにより、効率的な監視と迅速なインシデント対応が可能になります。
他のセキュリティツールとの連携
Snortは単体でも強力ですが、他のセキュリティツールと連携させることで、より多層的な防御を実現できます。
- ファイアウォール連携: Snort (特にIPSモード) が検知した悪意のあるIPアドレスを、ファイアウォールのブロックリストに動的に追加する連携(例: Snort + pfSense/OPNsense, Snort + iptables/nftables)。
- SIEM連携: 前述の通り、アラートログをSIEMに集約し、他のデバイス(ファイアウォール、プロキシ、エンドポイントセキュリティなど)のログと相関分析を行うことで、インシデントの全体像を把握しやすくなります。
- 脅威インテリジェンス連携: 外部の脅威インテリジェンスフィード(悪性IPアドレスリスト、マルウェアハッシュなど)を取り込み、Snortのルールや検知ロジックに活用する。
ライセンスに関する注意
前述の通り、Snort.orgが提供するルールセットには無料のコミュニティルールセットと有料のサブスクライバルールセットがあります。
- コミュニティルールセット: 基本的な保護を提供しますが、最新の脅威への対応はサブスクライバルールセットより遅れる傾向があります。ライセンスを確認し、利用条件(特に商用利用)を遵守する必要があります。
- サブスクライバルールセット: より迅速かつ包括的な保護を提供します。商用環境や高いセキュリティレベルが求められる環境では、導入を検討する価値があります。ライセンス費用が発生します(個人利用は無料の場合あり)。
利用しているルールセットの種類とライセンスを正確に把握し、規約を遵守することが重要です。
まとめ 🎉
Snortのデフォルトルールセット(主にコミュニティルールセット)は、Snortを効果的に運用するための基礎となる重要な要素です。この記事では、その入手方法、構造、有効化、カスタマイズ、そして実践的な運用上の注意点について解説しました。
デフォルトルールを使いこなすためのキーポイントは以下の通りです。
- ✅ 最新ルールの入手: Snort.orgから定期的に最新ルールを入手し、PulledPork等で更新を自動化する。
- ⚙️ 適切な有効化: 環境に合わせて必要なルールカテゴリを選択的に有効化し、不要なルールは無効にする。
- 🔧 継続的なチューニング: 誤検知 (False Positive) を抑制 (suppress, disable) し、パフォーマンスを最適化する。
- 📝 ローカルルールの活用:
local.rules
を用いて組織固有のルールを作成し、防御を強化する。 - 📊 ログ監視と分析: アラートログを継続的に監視・分析し、SIEM等と連携してインシデント対応やルール改善に繋げる。
- 📜 ライセンスの遵守: 利用するルールセットのライセンスを確認し、規約を遵守する。
Snortとデフォルトルールセットは、導入して終わりではありません。ネットワーク環境の変化や新たな脅威の出現に対応するため、継続的な学習、監視、そして改善が不可欠です。この記事が、皆さんのSnort運用の一助となれば幸いです。 Happy Snorting! 💪
参考情報 (一部)
- Snort公式サイト: https://www.snort.org/
- Snort 3 ドキュメント (ルールについて): https://docs.snort.org/rules/ (英語)
- PulledPork (GitHub): https://github.com/shirkdog/pulledpork
コメント