IDSを使ったLinuxセキュリティアップ入門（９）

　前回は、SnortをIDSモードで起動しネットワーク型IDSとして動作させた結果と、記録されたアラートログalertの内容について説明した。Snortのアラートメッセージがどのように記録されているのか、その基本的な形態と、メッセージの各部分が意味しているところについては

特集特集

2004年5月6日（木） 12時00分

　前回は、SnortをIDSモードで起動しネットワーク型IDSとして動作させた結果と、記録されたアラートログalertの内容について説明した。Snortのアラートメッセージがどのように記録されているのか、その基本的な形態と、メッセージの各部分が意味しているところについてはお分かりいただけたと思う。今回は、Snortの設定のチューニングとIDSの誤検知についてお話しよう。

　その前に、遅ればせながら改めて今回利用したネットワーク環境について触れておこう。

●ネットワーク環境について

　今回、執筆のために利用したネットワーク環境は筆者宅の小規模LANである。このLANには、無線LANのアクセスポイントを含み全体で10台近いマシンが接続されている。ちょっとしたSOHO並みの規模はあるはずだ。
　インターネットへの接続はフレッツADSLである。ADSLモデムとブロードバンドルーターを繋ぎ、そのルーターから小型のスイッチングハブを介して各マシンを接続している。その中から監視対象マシンとして、テスト用に使っている1台のLinuxマシンにSnortをインストールした。
　ADSLモデムを介して直接インターネットに繋がっている場合と違い、ルーターを置くだけで、IPマスカレードなどの機能によって内部LANに関するセキュリティは一定線が確保される。もちろん、それでは面白くないので、ルーターのDMZ機能を利用した。

「DMZ」とはDeMilitarized Zoneの略で、いわゆる非武装地帯を指す言葉だ。IT業界で用いられた場合は、インターネットに接続されたネットワークで、ファイアウォールによって外部ネットワークからも内部ネットワークからも隔離された第3の区域のことを指す。外部に公開するサーバをDMZに置くことで、外部からの不正なアクセスをファイアウォールによって排除し、万が一公開サーバが不正アクセスされても内部ネットワークにまで被害が及ぶことがない構造になっている。
　ただし、今回使用したルータのDMZ機能は、ルータの内側に設置されているマシンのひとつを、直接ADSLモデムに繋げているように見せかける機能のことである。ネットワーク対戦ゲームや一部のストリーミングメディアを楽しみたい場合などに利用する機能だ。この機能を利用すると、IPマスカレードなどの機能が効かなくなるためアドレス変換が行われず、マシンに直接グローバルIPアドレスが振られインターネットに接続しているような状況になる。まさに、外の世界に晒された形になるのだ。

　今回は、監視対象マシンを1台に絞り、ネットワーク全体を監視対象とすることは行わなかったが、ネットワーク内の別のマシンにSnortをインストールし、特定ネットワークを監視対象として設定すれば、LAN内を流れる全パケットをチェックすることが可能になる。もっとも、ネットワーク全体を監視するには、Snortがネットワークを流れている全パケットを読み取れる必要がある。スイッチングハブが導入された環境ではこれが難しい。家庭内LANでも100MBが当たり前となり、ギガイーサネットも急速に低価格化が進んでいる現在、古いリピータハブを使うこともできない。企業などのそれなりに規模が大きいネットワークでIDSによるネットワーク監視を行うには、パケットキャプチャを行えるポートを通常のポートとは別に備えたような高機能ハブを用意する必要があるだろう。

●設定の見直し−ルールの絞込み

　さて、Snortを動かしてみると、外部からのアクセスが意外と多いことに気づかされる。監視対象のマシンは、1週間弱、動作させておいたわけだが、alertログファイルの大きさは最終的に30KBを超えるサイズになった。これを多いと見るか少ないと見るかは、意見が分かれるところだろう。ただ、ドメインも持たず、外部に対して明示的にサーバを公開しているわけでもない1端末に対するアクセスとしては、多いと感じるのは筆者だけではあるまい。これが企業などの公開サーバとなると、日々どの程度のアクセスに晒されているのか想像を絶するところがある。

　しかし、alertログの中身がすべて危険な不正アクセスを意味しているわけではない。筆者の監視対象マシンに記録されたアラートメッセージの大半（実に90%以上）が、「MS-SQL Worm propagation attempt」というアラートであったことは前回説明した。これは、「Slammer」というワームによる無差別な攻撃パケットを検知したものである。ワームによる不正アクセスは確かにあったわけだが、監視対象マシンはLinuxマシンでありSQL Serverはインストールされていない。ネットワークへの脅威という点から見れば、意味がないものだ。
　なお、筆者が所持するLAN内のWindowsマシンはすべて最新のセキュリティパッチの対応済みで、たとえSQL Serverが人知れず動作していたとしても何ら問題はない状態になっている。

　このように、現実的にSnortを運用していくと、例のような攻撃と検知されても環境によっては直接影響を受けないものや、実際には無害と思われるようなアクセスの記録も増えていくことになる。そして、このような状態でログが増えると、本当に危険な不正アクセスの情報が膨大なログの中に埋没してしまい、下手をするとうっかり見落としてしまう可能性がでてくる。こういった余計なアラートメッセージはノイズや誤検知ともいい、これらを如何に減らすかがSnort運用の成否を分ける部分となる。

【執筆：磯野康孝】

（詳しくはScan本誌をご覧ください）
http://www.ns-research.jp/cgi-bin/ct/p.cgi?m-sc_netsec

《ScanNetSecurity》