検知とは？/ キャッシュワン
[ 517] ＠IT：Snortでつくる不正侵入検知システム 第1回
[引用サイト] http://www.atmarkit.co.jp/fsecurity/rensai/snort01/snort01.html
|
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 「IDSとは一体何なのか」。そう疑問に思った方は少なくないであろう。簡単にいえば、「ネットワークを流れるパケットに対してあるパターンに合致しているか否かを判定し、合致している場合はあらかじめ定められた処理を行う」ものである。 「あらかじめ定められた処理」とは具体的にどのような処理なのかというと、大抵は「警告を発する」という処理が行われる。あくまで「警告を発する」だけであることに注意してほしい。その警告を受けてどう動くかは、ほかならぬIDS管理者次第なのである。 「IDSを導入するメリットは何なのであろうか」という疑問を持たれるかもしれない。最も大きなメリットは「異常に気付かせてくれる」という点である。IDSがなければ、何か異常が発生したとしてもそれに気付くことは容易ではない。IDSを導入した後にそれが発する警告を眺めてほしい。恐らくその量の多さに驚くことだろう（後ほど述べるが、これらすべてが不正アクセスであるとは限らない）。 次に浮かんでくる疑問は、「IDSがあればファイアウォールは不要なのではないか」、あるいは「ファイアウォールがあるからIDSは不要なのではないか」といったものだろう。答えは「否」である。そもそもIDSとファイアウォールはお互いを補完する関係にある。もちろん、それぞれを単体で運用しても有益であるが、両者を組み合わせればさらに有益なものとなる。理想的にはファイアウォールとIDSの両方を設置することが望ましいといえる。 一方IDSはというと、「有人改札」であるといえる。チケットを持っているか否かに加え、そのチケットの持ち主が例えば指名手配犯でないかどうかといったことをチェックする。もし指名手配犯であれば、警察に通報することだろう。このようにIDSは、あるパケットがバッファオーバーフローを引き起こす脆弱性を狙ったものであるかどうかを判断し、そうであればIDS管理者に警告する。 「誤検知があっても問題はないのではないか」と考える方がいらっしゃるかもしれないが、それは最初だけである。IDSが警告をログに記録する場合で考えてみよう。最初のうちは誤検知があってもそれを無視してログをチェックするであろう。しかし、次第に誤検知の相対量が増えてくると、正規の警告が誤検知に埋もれてしまう。そうすると正規の警告を見逃しやすくなってしまう。探すのも面倒になる。その結果どうなるか。IDSの警告を無視するようになる。正しく侵入を検知しているものもそうでないものも、すべて無視するようになる。 極端な例だと思われるかもしれないが、多かれ少なかれそのようになっていくものである。また、ログを保存するストレージの容量を無駄に消費することにつながったり、余計なリソースを消費したりする結果にもなる。 このことから導き出される結論はただ1つ。「誤検知は極力減らすべし」。では、どうやって誤検知を減らしていけばよいのか。答えは単純である。ネットワークに最適化すればよい。しかしながら、単純であることと簡単であることは等価ではない。より具体的な方法については、今後紹介していきたいと思う。 4月にセキュリティインシデントが急増するワケ （2008/5/20）新人を歓迎するのは優しい先輩だけではありません。新人とセキュリティの関係を、彼らを育成する立場から考えてみます |
[ 518] Linuxで使える侵入検知システム（IDS）
[引用サイト] http://www.atmarkit.co.jp/flinux/rensai/security07/security07.html
|
「侵入させないこと」と並んで重要なのが、「侵入された場合の対処」である。しかし、何も対策を施していないシステムでは、侵入されたという事実に気付くのが難しい。IDSを導入して、最悪の事態にも迅速に対応できる体制を整えておこう。 IDSには、ネットワーク型IDSとホスト型IDSの2種類あります。IDSを直訳すると「侵入検知システム」となりますが、侵入の試みも検知することができます。また、「不正アクセス」は侵入行為だけを指すものではありません。IDSでは、攻撃の事前調査と思われるアクティビティも検知できるため、「不正アクセス検知システム」と考えていただいても構いません。 IDSは、ネットワークを流れるパケットやホストのアクティビティを監視して、攻撃を受けていないか、または侵入されてファイルを改ざんされていないかなどをチェックします。 IDSソフトウェアの中には、不正アクセスの試みを検知するとRESETパケットを送信して（注）切断する機能を装備したものもあります。しかし、IDSはあくまでも「検知」を目的としたものであり、ファイアウォールのように防御できるわけではありません。そのため、目に見える成果というものは分かりにくいかもしれません。攻撃を検知しても、それへの対策が何も施されていなければ不正アクセスを許してしまうでしょう。このように書いてしまうと、IDSを導入しても意味がないと思われるかもしれませんが、もちろんそんなことはありません。 何度も説明してきたように、セキュリティ対策に絶対というものは存在しません。世の中では、ファイアウォールを導入していれば安全だと判断されることが多いようです。まず、この認識を正さなければなりません。ファイアウォール導入はあくまでもセキュリティ対策の1つにすぎず、導入したからといって絶対的な安全が手に入るわけではないのです。 公開Webサーバが存在するのであれば、当然HTTPに対するアクセスは許可しているでしょう。WebアプリケーションやCGIなどに不具合があれば、ファイアウォールで防御することができないため、不正アクセスを許してしまう恐れがあります。 例えば、HTTPに対して通常では考えられないようなアクセスがあるかもしれません。これを判断するために、HTTPに対するアクセスログをリアルタイムで監視することは非現実的です。そこで、IDSに監視の手伝いをしてもらうわけです。さらに、万が一不正アクセスを許してしまった場合、IDSのログを追跡調査に役立てることもできます。 ホスト型IDSは公開サーバなど、監視対象となるホスト自身へ導入します。多くのホスト型IDSでは、ファイルの状態の監視が可能です。例えば、ファイルのサイズやパーミッションといったものが当てはまります。 Webサーバであれば、監視したい項目として考えられるのがコンテンツの書き換え、つまりファイルの改ざんです。利用するソフトウェアによって検知方法は異なりますが、多くのソフトウェアで採用されている検知方法が整合性のチェックによる監視です。ファイルサイズのHASH値をデータベースに保存して定期的に整合性をチェックすることで、内容の変化を検知します。変更したはずのないファイルが整合性チェックに引っ掛かったら、不正アクセスを許してしまったと考えられます。 また、攻撃者は侵入に成功すると、ログアウトする前にシステムログを削除して、侵入の痕跡を残さないようにするものです。こうなると、システムログから侵入の事実を把握することは難しくなりますし、その経路を特定することも非常に困難なものとなります。 不正アクセスを許してしまうことがそもそもの問題ではありますが、早急に侵入の事実に気付くことも大切なことです。侵入に成功した攻撃者が行う行動は、ファイルの改ざんだけではありません。他サイトへの攻撃の踏み台にされてしまう可能性もあります。ホスト型IDSを利用することが、このような事態に早急に気付く手助けとなるのです。 不正アクセスの事実に気付くことも大切ですが、その経路を特定することも重要です。ネットワークケーブルを外すなど、一時的な対策は施せるかもしれませんが、侵入経路を特定しなければ本質的な解決は望めません。このままでは、再度不正アクセスを許してしまうため公開できません。IDSは独自にログを持っているため、そのログを侵入経路の特定に役立てることができるのです。 また、ホスト型IDSの用途は不正アクセスの監視のみではありません。Webサイト改ざんの例を紹介しましたが、コンテンツの書き換えがすべて不正な改ざんというわけではありません。ただし、正当な書き換えであっても、ミスをする可能性があります。これは、アプリケーションなどの設定ファイルにも同じことがいえます。ホスト型IDSのファイル監査を利用すれば、どのファイルを変更したのかを確認することもできます。 Tripwireは、ファイルの作成や削除、ファイルサイズやパーミッションなどの変更を監視することができます。指定されたファイルやディレクトリの情報のHASH値を取り、データベースに保存します。そして、定期的に現在の状態とデータベースの内容とを比較して、違反がないかどうか判断します。結果はレポートとして保存されるほか、指定したアドレスにメールを送信することもできます。 swatchは、厳密にはIDSといえないかもしれませんが、有用なルールなのでここで紹介しておきます。swatchはリアルタイムでシステムログを監視し、指定した文字列にマッチするログを検知すると、指定したアクションを実行します。例えば、ログインの失敗などはsyslog経由でログファイルに記録されます。このログの内容を「シグネチャ」としてマッチ条件にすることで、ログインの失敗を検知することができます。短時間に何度もログインの失敗が検知されるようであれば、何者かが不正にログインを試みようとしている可能性があると判断できます。 ネットワーク型IDSは、リアルタイムでネットワーク上のパケットを監視し、不審なパケットを検知します。 最近では、ホスト型・ネットワーク型一体のIDSが提供され始めています。具体的には、ホスト型にネットワーク型の機能を組み込んだものです。 これを使えば、ネットワーク型IDSは不要に思えるかもしれませんが、一概にそうとはいえません。ネットワーク型IDSの機能が含まれていると、それだけサーバへ負荷がかかります。また、ネットワーク型IDSは監視対象のネットワーク上に存在するすべてのホストに対するパケットを検知できます。よって、ホストが増えたからといって、ネットワーク型IDSも増やす必要はないのです。 攻撃者の多くは、事前調査としてポートスキャンを実行するものです。ネットワーク型IDSはこれを検知できます。しかし、ポートスキャンを受けたからといって慌てる必要はありません。ファイアウォールやサーバ自体でフィルタリングが適切に設定されていれば、外部からのポートスキャンの結果は分かっているからです。 しかし、ポートスキャンが実行された場所によって事情が変わってきます。これが内部のクライアントからであればどうでしょうか？ 好奇心やいたずらにせよ、あまり好ましいものではありません。早急に実行者を見つけて警告を与えるべきでしょう。ネットワーク型IDSは、外部からの攻撃を監視するためだけにあるのではありません。内部からの不正なパケットも検知可能なのです。 ネットワーク型IDSの中には、「シグネチャ」と呼ばれる情報を持つものがあります。シグネチャとは、攻撃と推測されるパケットの特徴をパターン化したもので、ネットワーク上を流れるパケットとシグネチャを比較します。シグネチャと一致するものを見つけると、攻撃を受けている可能性があると判断して管理者に何らかの方法で通知します。シグネチャマッチ型は、新たな攻撃手法に対応するため、攻撃手法が発見されるごとにシグネチャを更新する必要があります。 シグネチャを利用しないネットワーク型IDSも存在します。このようなタイプのIDSは、統計情報から分析を行い、異常状態を検知します。このタイプはシグネチャを利用しないため、更新作業は必要ありません。 ネットワーク型IDSは、パケットを監視したいセグメントに専用機を用意して設置します。設置場所としては、以下の3つが考えられます。 公開サーバに対するアクセスを監視したいのであれば、DMZ上に設置するのが望ましいでしょう。また、DMZ上であればファイアウォールで許可されているパケット以外が検知されることは通常考えられません。よって、検知項目を絞ることができます。DMZ上に設置するメリットとして、ファイアウォールの監査が可能なことが挙げられます。ファイアウォールで拒否しているはずのパケットをIDSが検知するようであれば、ファイアウォールのルールを見直すべきでしょう。 不正アクセスの多くが内部からであるということから、内部ネットワーク上に設置して不穏な動きを見せるクライアントがいないか監視するのも大きな意味があるでしょう。 ネットワーク型IDSで必ずといっていいほど悩まされることがあります。それは、何を検知項目とするかの判断です。提供されているシグネチャすべてを検知項目としてしまうと、ログの嵐に見舞われるでしょう。このログを毎日毎日チェックするのは大変です。検知項目は絞り込んだ方が効果的です。 では、どのような項目を外すべきか考えてみましょう。例として、DMZ上に設置した場合を考えてみます。DMZ上にはWebサーバが存在し、ファイアウォールでは80/TCPのみ外部からのアクセスが許可されているとします。DNSに関するシグネチャは外しても問題ないでしょう。なぜなら、ファイアウォールを通過することは考えられないので、IDSで検知するはずがないからです。 しかしながら、ファイアウォールが必ずしも適切に設定されているとは限りません。また、WebサーバでHTTPだけでなく内部向けのDNSサービスを起動していれば危険な目に遭うかもしれません。そうなるとDNSも検知項目から外せなくなってしまいます。よって、そのような事態への対策も必要でしょう。この対策としては、80/TCP以外のアクセスがあれば検知するように設定すればいいのです。悪意があろうがなかろうが、80/TCP以外のアクセスがあれば、その時点で問題があるからです。DNSに限らず、ほかのサービスについても同様に考えることができます。 IDSを運用するのであれば、攻撃の手法についても知る必要があるでしょう。検知したものが、管理下のネットワークに被害をもたらすものなのかどうか判断しなければなりません。これができないと、IDSに振り回されてしまうでしょう。 snortは、Linux対応のネットワーク型IDSでは最も有名かつ利用されているソフトウェアでしょう（注）。snortはシグネチャマッチ型のIDSで、フリーソフトとして提供されています。基本的には、提供されているルールセット（シグネチャ）を利用します。ルールの記述方法もそれほど難しくないため、新たな攻撃手法が発見されても、その情報から早急に対応することができます。 注：もともとはシンプルなネットワークモニタリングツールであったため、単純なスニファとして利用することもできます。 また、アラートを検知したときの出力方法を選択することが可能です。その方法としては、システムログに送る、tcpdump形式保存、データベースへの格納などがあります。 シグネチャは自動的に更新できます。ただし、追加された項目を監視対象とするか否かは、当然のことながら運用担当者の判断となります。 奥が深いセキュリティ対策の世界をゼロから解説。ホストレベルのセキュリティからファイアウォール、IDSの構築、ログ管理方法まで、システム管理者必見 WebDAVのメソッドは便利な反面、セキュリティホールとなり得る。しかし、適切な対策を講じることでメソッドの危険性は取り除くことができる サーバにリモートログインする場合は、暗号化して転送するsshを使おう。sshをサーバとクライアントにインストールすれば、インターネット上でも安全な通信が可能になる |
キャッシュワンのサイトです。
