この記事は、Jack Koziolの新著『 Intrusion Detection with Snort 』 からの一部抜粋である。
リアルタイム警告は、侵入検知システム（IDS）を始めとする監視アプリケーションに実装される機能で、何らかのイベントが起きた際に、それをすばやくユーザに通知する。「すばやく」というのがどの程度の時間を指すのかは状況によって異なる。監視対象のシステムの重要性や、担当するユーザの職務などの要素が、何をもって「リアルタイム」とするかを決定するのだ。
Snortのリアルタイム警告はカスタマイズの自由度が非常に高い。個別のルールや、ルールのカテゴリに優先度を割り当てることで、どの警告をリアルタイムで通知するかを指定できる。1つ1つのルールに優先度を割り当てられるだけでなく、ルールをカテゴリに分けて、そのカテゴリに優先度を割り当てることもできる。
この優先度は、各ルールに関する通知を別々のユーザに送るように指定することもできる。つまり、サードパーティのSnortアプリケーションを使って、悪質なリモート・バッファ・オーバーフローに関する通知は自分宛に送られるように設定し、一方で、インターネットの適切でないアクティビティに関しては他のユーザに通知されるように設定することができる。通知の優先度をカスタマイズすれば、さまざまなルールをさまざまな方法で通知させることが可能だ。メールアドレスに通知を送らせてそれをポケットベルで受け取ったり、そのまま電子メールで受け取ったりすることができる。
Snort IDSにリアルタイム警告の機能を実装する最も一般的な方法は、swatch（Simple Watcher）やsyslog-ng（syslog-next generation）を利用することだ。swatchとsyslog-ngは、Snortからのsyslog出力の中に指定された文字列があるかどうかを監視し、その文字列が見つかると、コマンドを実行する。このコマンドは、多くの場合電子メールの送信だが、その他に、ポケットベル用アプリケーションや、警告音を鳴らすなどのオプションを指定することもできる。サーバとセンサのハイブリッド・インストールにおいては、swatchとsyslogを利用してリアルタイム警告を実装するのが最適だ。このハイブリッドにはすでにsyslogデーモンがインストールされている場合が多いので、swatchをセットアップして、syslogにログを出力するようSnortやBarnyardを構成し、通知を送るためのアプリケーションをインストールするだけで済む。
分散型の3層スキーマでは、syslog-ngの方が向いている。このスキーマにSnortをインストールする場合には、syslog警告を中央集中的に収集したいだろう。理論上、センサからの警告を受け取るのに最適な場所はSnortサーバだ。サーバは重要な警告を監視し、それを適切なユーザに電子メールで通知する。すべてのセンサに電子メール・アプリケーションとswatchをインストールするのは労力の無駄なので、syslog-ngに警告を収集させればよい。syslog-ngクライアントは、Snortからの警告データを受け取り、それを中央のsyslog-ngロギング・サーバに渡す。クライアントからサーバへのsyslog-ngセッションを暗号化するには、Stunnelを利用する。syslog-ngは、ロギング・サーバから単純なシェルスクリプトを呼び出し、電子メール・アプリケーションに警告を送る。
警告の優先度
リアルタイム警告をSnortに実装する前に、どの警告の通知を受けるべきかを判断する必要がある。Snortでは、警告の優先度をかなり柔軟に設定できる。通知の対象として、ルールのカテゴリを指定することも、個々のルールを指定することもできる。個々のルールに指定された優先度は、ルールのカテゴリに指定された優先度よりも優先する。
syslog-ngやswatchに監視させる文字列は、警告の優先度だ。この優先度にしたがって、実行するアクションを指定する。たとえば、優先度が1の警告ではポケットベル用のプログラムを実行し、優先度2の警告では電子メールアカウントに通知を送り、優先度3の警告ではネットワークの悪用を担当する管理者に通知を送る、といった具合だ。
どのルールを警告の対象にするかが決まったら、続いて、誰にどのような通知を送るかを決める必要がある。セキュリティに関するイベントを1人のユーザ、または1つのユーザのグループに通知する場合には、リアルタイム警告の対象とするすべてのルールとルールのカテゴリを同じ優先度にセットする。複数のユーザやグループに通知する場合には、それぞれに対して優先度を割り当てる。
Snort警告の通知先としてユーザのグループが指定されている場合は、それぞれの役割を前もって明確にしておくことが重要だ。グループに対して通知を行う場合には、通知の計画をしっかり立てておくことで、多くの問題を回避できる。グループが通知を受け取ると、そのうちの1人が、グループ内の他のユーザに断りなくその通知に対応してしまうというケースは非常に多い。最初に通知に対応したアナリストが行った修正作業が、他のアナリストを混乱させたり、邪魔したりする可能性もある。私は、遅番のアナリストが、他の人々が警告を把握する前にその警告を削除してしまい、IDSチームを混乱に陥れたのを目撃したことがある。このIDSチームはしばらくの間、Snortサーバが攻撃を受けたのではないかと考えたのだ。また、これよりも悪いシナリオは、リアルタイム警告を受け取ったグループのメンバ全員が、他の誰かが対応しただろうと考えて重要な警告をほったらかしにしてしまうことだ。このような問題を避けるには、それぞれの役割を事前に決めておくことが重要である。
classification.configを使った優先度の指定ルールのカテゴリに割り当てた優先度は、classification.configファイルで編集が可能だ。/etc/snort/conf/に置かれているこのファイルを開くと、ルールのカテゴリを確認できる。ここで紹介する例では、優先度が1のすべてのルールを通知するようリアルタイム警告が設定されている。よって、通知を受け取りたいルールのカテゴリの優先度を、このファイルで1に変更すればよい。例えば、DoS攻撃が成功した場合に通知を受け取るようにするには、
config classification: successful-dos, Denial of Service, 2
この行を次のように変更する。
config classification: successful-dos, Denial of Service, 1
ルールのカテゴリの粒度が目的にそぐわない場合は、自分で作成することができる。classification.configファイル内に、次の例のようにルールのカテゴリを作成する。
config classification: attack-response, Successful Attack Response, 1
カテゴリのキーワード内、およびデリミタのコンマの前には空白を含めることができない点に注意してほしい。
次に、新しいカテゴリのキーワードを、それに対応するルールに追加する。この例では、次の2つのルールのclasstypeオプションを変更した。
alert tcp $HTTP_SERVERS $HTTP_PORTS ->$EXTERNAL_NET any
(msg:"ATTACK RESPONSES http dir listing ";content:"Volume Serial Number "; flow:from_server,
established;classtype:attack-response;)
alert tcp $HTTP_SERVERS $HTTP_PORTS ->$EXTERNAL_NET any
(msg:"ATTACK RESPONSES command completed ";content:"Command completed ";
nocase;flow:from_server, established;classtype:attack-response;)
これで、これらの攻撃が成功した場合に、リアルタイムで通知を受け取ることができるようになった。
priorityオプション
個々のルールの優先度を変更することもできる。ルールにpriorityオプションを割り当てると、指定されたルールの優先度が変更される。あるpriorityを割り当てたルールにclasstypeオプションがあり、そのclasstypeオプションに異なる優先度が指定されている場合には、priorityオプションが優先される。先ほど紹介した、HTTPディレクトリのファイル表示に関するルールに異なる優先度を割り当てるには、次のように変更すればよい。
alert tcp $HTTP_SERVERS $HTTP_PORTS ->$EXTERNAL_NET any
(msg:"ATTACK RESPONSES command completed ";content:"Command completed ";
nocase;flow:from_server, established;classtype:attack-response;priority:2 )
これで、優先度が2に設定された。priorityオプションを使う方法は、環境内で特に重要なルールを識別するのに役立つ。
リアルタイム警告で2種類以上の通知方法を利用する場合には（電子メールとポケットベルなど）、通知方法ごとにさらにルールを分ける必要がある。これが済んだら、Snortにこの通知を実装しよう。実装については、次回説明する。
Jack Koziolは、シカゴ西部に本拠地を置く国民健康保険関連企業の情報セキュリティ部門のマネージャである。1998年以来、ネットワークセキュリティの分野で活躍している。Eコマース、ヘルスケア、金融などの業界で、上級管理職として、実働環境で大規模なSnortベースの侵入検知システムを構築してきた。Information Security Magazine誌では「Hack and Defend」やCISSPのレビュー・セッション・コースの講師を務め、情報セキュリティに関するさまざまな記事を執筆している。