Linuxで使える侵入検知システム（IDS）：ゼロから始めるLinuxセキュリティ（7）
「侵入させないこと」と並んで重要なのが、「侵入された場合の対処」である。しかし、何も対策を施していないシステムでは、侵入されたという事実に気付くのが難しい。IDSを導入して、最悪の事態にも迅速に対応できる体制を整えておこう。
最近、IDS（Intrusion Detection System）という名前を聞いたことはないでしょうか？ または、IDSの導入を考えている管理者の方もいるのではないでしょうか？ あるいは、IDSという名前は知っていても、IDSとは一体どんなものなのか、何に役立つのか、よく分からないという方も多いのではないでしょうか。そこで、今回からIDSについて紹介していきたいと思います。
IDSとは何か
IDSには、ネットワーク型IDSとホスト型IDSの2種類あります。IDSを直訳すると「侵入検知システム」となりますが、侵入の試みも検知することができます。また、「不正アクセス」は侵入行為だけを指すものではありません。IDSでは、攻撃の事前調査と思われるアクティビティも検知できるため、「不正アクセス検知システム」と考えていただいても構いません。
IDSは、ネットワークを流れるパケットやホストのアクティビティを監視して、攻撃を受けていないか、または侵入されてファイルを改ざんされていないかなどをチェックします。
IDSソフトウェアの中には、不正アクセスの試みを検知するとRESETパケットを送信して（注）切断する機能を装備したものもあります。しかし、IDSはあくまでも「検知」を目的としたものであり、ファイアウォールのように防御できるわけではありません。そのため、目に見える成果というものは分かりにくいかもしれません。攻撃を検知しても、それへの対策が何も施されていなければ不正アクセスを許してしまうでしょう。このように書いてしまうと、IDSを導入しても意味がないと思われるかもしれませんが、もちろんそんなことはありません。
何度も説明してきたように、セキュリティ対策に絶対というものは存在しません。世の中では、ファイアウォールを導入していれば安全だと判断されることが多いようです。まず、この認識を正さなければなりません。ファイアウォール導入はあくまでもセキュリティ対策の1つにすぎず、導入したからといって絶対的な安全が手に入るわけではないのです。
公開Webサーバが存在するのであれば、当然HTTPに対するアクセスは許可しているでしょう。WebアプリケーションやCGIなどに不具合があれば、ファイアウォールで防御することができないため、不正アクセスを許してしまう恐れがあります。
例えば、HTTPに対して通常では考えられないようなアクセスがあるかもしれません。これを判断するために、HTTPに対するアクセスログをリアルタイムで監視することは非現実的です。そこで、IDSに監視の手伝いをしてもらうわけです。さらに、万が一不正アクセスを許してしまった場合、IDSのログを追跡調査に役立てることもできます。
ホスト型IDS
ホスト型IDSは公開サーバなど、監視対象となるホスト自身へ導入します。多くのホスト型IDSでは、ファイルの状態の監視が可能です。例えば、ファイルのサイズやパーミッションといったものが当てはまります。
Webサーバであれば、監視したい項目として考えられるのがコンテンツの書き換え、つまりファイルの改ざんです。利用するソフトウェアによって検知方法は異なりますが、多くのソフトウェアで採用されている検知方法が整合性のチェックによる監視です。ファイルサイズのHASH値をデータベースに保存して定期的に整合性をチェックすることで、内容の変化を検知します。変更したはずのないファイルが整合性チェックに引っ掛かったら、不正アクセスを許してしまったと考えられます。
また、攻撃者は侵入に成功すると、ログアウトする前にシステムログを削除して、侵入の痕跡を残さないようにするものです。こうなると、システムログから侵入の事実を把握することは難しくなりますし、その経路を特定することも非常に困難なものとなります。
コラム：踏み台にされることに注意
不正アクセスを許してしまうことがそもそもの問題ではありますが、早急に侵入の事実に気付くことも大切なことです。侵入に成功した攻撃者が行う行動は、ファイルの改ざんだけではありません。他サイトへの攻撃の踏み台にされてしまう可能性もあります。ホスト型IDSを利用することが、このような事態に早急に気付く手助けとなるのです。
もし、侵入の事実に気付かなければ、次のようなことが起こるかもしれません。
信頼関係
Network A<--------------->Network B
Network AとNetwork Bには信頼関係があり、Network B上にある重要なデータをNetwork Aに対しては公開しているとします。攻撃者がNetwork Aに侵入すると、そこからNetwork B上の重要な情報を盗み見られてしまうかもしれません。Network Bは、Network Aからの要求であったため、攻撃者に対して情報を公開してしまったこと自体に気付かないかもしれません。
このような事態に陥らないためにも、管理下にあるホストの状態を常に把握しておくことは、非常に重要なセキュリティ対策の1つと考えられます。
不正アクセスの事実に気付くことも大切ですが、その経路を特定することも重要です。ネットワークケーブルを外すなど、一時的な対策は施せるかもしれませんが、侵入経路を特定しなければ本質的な解決は望めません。このままでは、再度不正アクセスを許してしまうため公開できません。IDSは独自にログを持っているため、そのログを侵入経路の特定に役立てることができるのです。
また、ホスト型IDSの用途は不正アクセスの監視のみではありません。Webサイト改ざんの例を紹介しましたが、コンテンツの書き換えがすべて不正な改ざんというわけではありません。ただし、正当な書き換えであっても、ミスをする可能性があります。これは、アプリケーションなどの設定ファイルにも同じことがいえます。ホスト型IDSのファイル監査を利用すれば、どのファイルを変更したのかを確認することもできます。
Linuxで使えるホスト型IDS
以下に、Linuxで使える代表的なホスト型IDSを紹介します。
- Tripwire
http://www.tripwire.co.jp/（製品版）
http://www.tripwire.org/（無償版）
Tripwireは、ファイルの作成や削除、ファイルサイズやパーミッションなどの変更を監視することができます。指定されたファイルやディレクトリの情報のHASH値を取り、データベースに保存します。そして、定期的に現在の状態とデータベースの内容とを比較して、違反がないかどうか判断します。結果はレポートとして保存されるほか、指定したアドレスにメールを送信することもできます。
Tripwireで違反が検知されるということは、ファイルやディレクトリに対して何らかの変更が行われたと判断できます。
swatchは、厳密にはIDSといえないかもしれませんが、有用なルールなのでここで紹介しておきます。swatchはリアルタイムでシステムログを監視し、指定した文字列にマッチするログを検知すると、指定したアクションを実行します。例えば、ログインの失敗などはsyslog経由でログファイルに記録されます。このログの内容を「シグネチャ」としてマッチ条件にすることで、ログインの失敗を検知することができます。短時間に何度もログインの失敗が検知されるようであれば、何者かが不正にログインを試みようとしている可能性があると判断できます。
- Dragon Squire
http://www.enterasys.co.jp/
Dragon Squireは、Linux対応の商用IDSです。システムログ経由でホスト上の不審な行動を監視できるほか、リアルタイムでファイルの改ざんなどを検知することも可能です。不審と思われる行動などを検知すると、電子メールやSNMPを用いて管理者に通知します。
Dragon Squireは、「Dragon Server」という専用のコンソールで管理します。また、Webベースの管理インターフェイスがあるため、Webブラウザ経由で設定の変更が可能です。
ネットワーク型IDS
ネットワーク型IDSは、リアルタイムでネットワーク上のパケットを監視し、不審なパケットを検知します。
コラム：ネットワーク型IDSはもう要らないのか？≫
最近では、ホスト型・ネットワーク型一体のIDSが提供され始めています。具体的には、ホスト型にネットワーク型の機能を組み込んだものです。
これを使えば、ネットワーク型IDSは不要に思えるかもしれませんが、一概にそうとはいえません。ネットワーク型IDSの機能が含まれていると、それだけサーバへ負荷がかかります。また、ネットワーク型IDSは監視対象のネットワーク上に存在するすべてのホストに対するパケットを検知できます。よって、ホストが増えたからといって、ネットワーク型IDSも増やす必要はないのです。
やはり、ホスト型IDSとネットワーク型IDSは別々に用意した方がいいのではないでしょうか。
攻撃者の多くは、事前調査としてポートスキャンを実行するものです。ネットワーク型IDSはこれを検知できます。しかし、ポートスキャンを受けたからといって慌てる必要はありません。ファイアウォールやサーバ自体でフィルタリングが適切に設定されていれば、外部からのポートスキャンの結果は分かっているからです。
しかし、ポートスキャンが実行された場所によって事情が変わってきます。これが内部のクライアントからであればどうでしょうか？ 好奇心やいたずらにせよ、あまり好ましいものではありません。早急に実行者を見つけて警告を与えるべきでしょう。ネットワーク型IDSは、外部からの攻撃を監視するためだけにあるのではありません。内部からの不正なパケットも検知可能なのです。
2タイプのネットワーク型IDS
ネットワーク型IDSの中には、「シグネチャ」と呼ばれる情報を持つものがあります。シグネチャとは、攻撃と推測されるパケットの特徴をパターン化したもので、ネットワーク上を流れるパケットとシグネチャを比較します。シグネチャと一致するものを見つけると、攻撃を受けている可能性があると判断して管理者に何らかの方法で通知します。シグネチャマッチ型は、新たな攻撃手法に対応するため、攻撃手法が発見されるごとにシグネチャを更新する必要があります。
シグネチャを利用しないネットワーク型IDSも存在します。このようなタイプのIDSは、統計情報から分析を行い、異常状態を検知します。このタイプはシグネチャを利用しないため、更新作業は必要ありません。
ネットワーク型IDSの運用形態
ネットワーク型IDSは、パケットを監視したいセグメントに専用機を用意して設置します。設置場所としては、以下の3つが考えられます。
- ファイアウォールの外側
ファイアウォールの外側に設置すれば、多くの項目を検知するでしょう（注）。被害を受けることのない攻撃を検知する可能性もあります。
- DMZ上
公開サーバに対するアクセスを監視したいのであれば、DMZ上に設置するのが望ましいでしょう。また、DMZ上であればファイアウォールで許可されているパケット以外が検知されることは通常考えられません。よって、検知項目を絞ることができます。DMZ上に設置するメリットとして、ファイアウォールの監査が可能なことが挙げられます。ファイアウォールで拒否しているはずのパケットをIDSが検知するようであれば、ファイアウォールのルールを見直すべきでしょう。 - 内部ネットワーク
不正アクセスの多くが内部からであるということから、内部ネットワーク上に設置して不穏な動きを見せるクライアントがいないか監視するのも大きな意味があるでしょう。
以上のように、設置場所はIDS導入の目的によって変わってきます。
ネットワーク型IDSで必ずといっていいほど悩まされることがあります。それは、何を検知項目とするかの判断です。提供されているシグネチャすべてを検知項目としてしまうと、ログの嵐に見舞われるでしょう。このログを毎日毎日チェックするのは大変です。検知項目は絞り込んだ方が効果的です。
では、どのような項目を外すべきか考えてみましょう。例として、DMZ上に設置した場合を考えてみます。DMZ上にはWebサーバが存在し、ファイアウォールでは80/TCPのみ外部からのアクセスが許可されているとします。DNSに関するシグネチャは外しても問題ないでしょう。なぜなら、ファイアウォールを通過することは考えられないので、IDSで検知するはずがないからです。
しかしながら、ファイアウォールが必ずしも適切に設定されているとは限りません。また、WebサーバでHTTPだけでなく内部向けのDNSサービスを起動していれば危険な目に遭うかもしれません。そうなるとDNSも検知項目から外せなくなってしまいます。よって、そのような事態への対策も必要でしょう。この対策としては、80/TCP以外のアクセスがあれば検知するように設定すればいいのです。悪意があろうがなかろうが、80/TCP以外のアクセスがあれば、その時点で問題があるからです。DNSに限らず、ほかのサービスについても同様に考えることができます。
IDSを運用するのであれば、攻撃の手法についても知る必要があるでしょう。検知したものが、管理下のネットワークに被害をもたらすものなのかどうか判断しなければなりません。これができないと、IDSに振り回されてしまうでしょう。
Linuxで使えるネットワーク型IDS
以下に、Linuxで使えるネットワーク型IDSを紹介します。
snortは、Linux対応のネットワーク型IDSでは最も有名かつ利用されているソフトウェアでしょう（注）。snortはシグネチャマッチ型のIDSで、フリーソフトとして提供されています。基本的には、提供されているルールセット（シグネチャ）を利用します。ルールの記述方法もそれほど難しくないため、新たな攻撃手法が発見されても、その情報から早急に対応することができます。
また、アラートを検知したときの出力方法を選択することが可能です。その方法としては、システムログに送る、tcpdump形式保存、データベースへの格納などがあります。
- Dragon Sensor
http://www.enterasys.co.jp/
Dragon SensorもDragon Squireと同じくLinux対応の商用IDSです。シグネチャマッチ型IDSで、シグネチャの数は約1400も存在します。シグネチャ数は、ネットワーク型IDSの中ではNo.1ではないでしょうか。
シグネチャは自動的に更新できます。ただし、追加された項目を監視対象とするか否かは、当然のことながら運用担当者の判断となります。
Copyright © ITmedia, Inc. All Rights Reserved.