ネットワークセキュリティHACKS Wiki 第十章 ネットワーク侵入検知 - careerbeat/dit-ehime GitHub Wiki
- Snort(ネットワーク侵入検知システム:NIDS)を用いてネットワークへの侵入を監視する
- ログを見るだけでは不正アクセスを検知できない
- ネットワークを流れるパケットに対してあるパターンに合致しているか否かを判定し、合致している場合はあらかじめ定められた処理を行う
- 「あらかじめ定められた処理」は管理者へアラートを出すなどである
- IDSとファイアウォールはお互いに補間し合う関係にある
※ファイアウォールはパケットが悪意のあるものかどうかを判断しないが、IDSはそれを行う
- ネットワーク型：ネットワークに流れるパケットすべてを監視する
- ホスト型：IDSが稼働しているコンピュータ自身を監視する
-
シグネチャ型：「○○○○の場合は不正アクセスである」といった情報(シグネチャ)と現在のパケットを照らし合わせ、合致した場合に不正アクセスと判断する
-
アノマリ型：「○○○○という状態が正常である」といった情報を何らかの手段により蓄積しておき、それと現在の状況を照らし合わせ、一定の閾値を超えた場合に「異常である」と判断する
- ログは攻撃者自身によって改ざんされる可能性があるため、不正アクセスを必ず見破れるとは限らない
- パケットのパターンによってより確実に不正アクセスを検知する
- シグネチャ型のNIDS(ネットワークに流れるパケットすべてを監視して、シグネチャとパケットを比較することにより不正アクセスを検知する)
- オープンソースのソフトウェア
- 新しい攻撃手法が発見された場合も、自らシグネチャを作成することができる
- 不正アクセスを検知した場合のアラートの手段には、Syslog、ファイル出力、データベースへ記録するなど様々な形式がある
下記でSnortを用いてネットワークへの侵入を検知する方法を解説する
- BASEによってSnortのアラートを管理する
- 大量の通信が発生するネットワークを監視すると、アラートも大量になるため
HACK#98でも述べた通り、Snortでネットワークを監視して発生したアラートは、Syslogやデータベースなどに記録される
その中から特定のアラートを探したり削除したりするのは手間のかかる作業である
そこで、「BASE」を用いることで、Snortのアラートデータベースを可視化し、アラートの管理を容易にする
- SnortのアラートデータベースをWebブラウザで閲覧できるようにGUIを提供するもの
- 様々な条件、ルール、発生時期、送信元／宛先、IPアドレス、ポート番号などによってアラートを検索して表示することが可能
- アラートのグループ化、削除、電子メールで送信、バックアップなども可能
下記にBASEによるSnortで発生したアラートの管理方法について解説する
- SnortALogを用いて、Snortやファイアウォールで記録されるログをレポート化する
- 不正アクセスを分析するためには、どのくらいの危険度のアクセスログが何件あったなどといった時系列データが必要となることがある
BASEによってSnortが検出したアラートを詳細な条件に従って細かく管理することができるが、レポート化する機能が備わっていない
レポート化されていないと、重大な不正アクセスを見逃してしまって、それに対する対策が怠慢になってしまう可能性がある
そこで、「SnortALog」を用いて、Snortが検出したアラートをレポート化して時系列的に可視化する
- Snortやファイアウォールで記録されるログを集計して出力するもの
- テキストやHTML、PDFといった形式でレポートを作成できる
- gtkを用いてX Windowに表示させることもできる
gtk(gimp tool kit)：GIMPを開発するためのツールキット
GIMP(GNU Image Manipulation Program)：ビットマップ画像編集・加工ソフトウェア
下記でSnortALogを用いたSnortのログを集計してレポートを作成する方法を解説する
- Squilを用いてIDSのイベントログの相関分析を行い、イベントログの詳細を解析する
- 膨大な量のログを得られてもそれらを分析しないとそれらの持つ意味が分からない
HACK#98で記述した通り、IDSではネットワークまたはホストにおいて通信された種々の情報やシステムの状態などの情報がログとして記録される
そのログには誰がログインしたか、どのようなデータが流れたか、どのようなエラーが発生したかなどのデータが時間と共に記録される
ログに記録されたそれらの情報を知るためには、ログを適切に分析しなければならない
ログを分析する方法として以下が上げられる
| 分析手法 | 特徴 |
|---|---|
| 統計分析 | 一定期間のアクセス数やアクセスの頻度などの情報を表やグラフに表して分析する 統計的情報から逸脱したデータを検知し不正アクセスを判定する 閾値をどこにするかにより検出率と誤検知率が変化する |
| イベント分析 | 1回の攻撃で複数のログが記録されることも多いことを踏まえて、IDSで検知した通信などを総合的に分析する |
| データマイニング(相関分析) | 大量のログデータからある傾向や相関関係などを見つけ出す 通常数回のステップを踏んで相関関係を絞り込んでゆくので手間がかかるが、有効な情報を得ることができる |
このHACKで紹介する「Sguil」は相関分析によってログを分析する
- Tcl／Tkによって記述されたグラフィカルな解析コンソール
※Tcl／Tk：スクリプト言語TclとそのGUIツールキットTk - クライアントサーバ型のアプリケーション(3つのパーツから構成)
- op_guil：Barnyardのプラグイン
※Barnyard：Snortでアラートをフォーマットして指定した形式で出力するもの - sguild：サーバ
- sguil.tk：クライアント
- op_guil：Barnyardのプラグイン
- Squilのエージェントで検知された情報がサーバにレポートされる
- サーバがエージェントからのデータを元に相関分析を行う
下記でSguilを用いたIDSのイベントログの相関分析方法について解析する
- SnortCenterを利用してNIDSセンサーを統一的に処理する
- 通常、NIDSセンサーの管理は各センサー単位で行うので、非常に手間がかかる
まず、センサーとは実際に不正アクセスの検知を行うものである
Snortでは、事前に設定されたルールに従ってセンサーで不正アクセスの検知を行う
センサーにはそれぞれ固有のルールが設定されていて、センサーの起動・停止であったりアラートを出すのは個別に行われる
そのため、センサーの管理は個別で行わなければならず、大変な作業となる
このHACKで紹介する「SnortCenter」は、上記のような個別に行われる操作を1つのアプリケーションで統一的に行うことができる
- 複数のNIDSのセンサーを統一的に管理する
- Webベースのコンソールと各NIDSセンサー上で動作するセンサーエージェントで構成される
- 独自のユーザー認証機構により、Webコンソールと各センサーエージェント間の通信を暗号化できる
→ 複数のセンサーに対するルールの作成や追加を安全に行うことができ、不正アクセス成功の可能性を低くできる - 複数のセンサーの起動・停止を行える
- NIDSのアラートを管理するBASEと組み合わせが可能
下記でSnortCenterによる複数センサーの管理方法を示す
- Snort独自のルール言語により、オリジナルのSnortルールを記述して、ネットワーク上で発生する様々な現象を検知する
- 不正アクセス手法は日々多種多様化していくので、オリジナルのSnortルールを追加していかないと検知できない
NIDSのSnortは、独自のルールエンジンとルール言語を持っている
ルールエンジンは、ネットワーク上で発生する様々な現象を検知するために様々な機能(検査されるパケットおよびパケット関連値をシステムがどのように評価するかを決定するなど)を備えている
ルール言語は、ルールエンジンの機能を操作するために記述する
ルールを適切に設定して、検知できるネットワーク上の減少を増やしていく
- ルールヘッダとルールボディから構成
- ルールヘッダ：ルールにマッチした際のアクション(ルールアクション)、ルールを適用するプロトコル、送信元・宛先のIPアドレス・ポートを記述
- ルールボディ：ルールに関連付けるメッセージやSnortの検査モジュールを呼び出すための細かいオプション(ルールオプション)を記述
ルールヘッダ(ルールボディ)
Snortルールは下記のようなフォーマットで記述される
action proto src_ip src_port direction dst_ip dst_port (options)
| ルールアクション | 概要 |
|---|---|
| log | ルールにマッチしたパケットログを記録 |
| alert | 設定ファイルやコマンドラインで指定した方法で管理者に通知したうえでパケットを記録 |
| pass | ルールにマッチしたパケットを無視 |
| active,dynamic | 2つを組み合わせることでSnortのルールを動的に変更 |
- 検査対象とするプロトコルを記述する
- Snortルールがサポートしているのは、ip、icmp、tcp、udp
- src_ip：パケットの送信元IPアドレス(範囲、リストでも指定可能)
- dst_ip：パケットの宛先IPアドレス(範囲、リストでも指定可能)
- src_port：パケットの送信元ポート番号(:区切りで範囲指定も可能)
- dst_port：パケットの宛先ポート番号(:区切りで範囲指定も可能)
- 特定のポート番号を指定しない場合は、「any」を記述する
- 初期のSnortでは「->」、「<-」が利用可能であったが、現在は「<-」が廃止されている
- 上記に合わせて、双方向の通信を意味する「<>」の2種類を指定できる
- Snortには下記の例のような多くのルールオプションが存在する
| ルールオプション | 概要 |
|---|---|
| msg | パケットがルールにマッチした場合にメッセージを出力する msg:"出力するメッセージ" |
| content | パケット内を16進の値や文字列で検索する (文字列の検索)content:"検索する文字列" (16進の値の検索)content:"|16進の値|" ※検索する文字列の前に「!」をつけると該当文字列を含まないものを検索可能 ※16進の値の1例として、0x90はバッファオーバーフローを引き起こす不正アクセスコードの検出によく用いられる |
| nocase | contentオプションによる文字列検索で、大文字・小文字を区別する場合にcontentオプションと共に指定する |
| offset,depth | contentオプションでマッチングを開始する値と終了する値を指定する |
| dsize | パケットのペイロードサイズを指定する dsize:ペイロードサイズ(の範囲) ※範囲指定には「<>」が使用可能 ※ペイロード：パケットのヘッダ部分を除いた送信したいデータそのもの |
| flags | TCPフラグを検査して、ポートスキャンなどを検出する flags: フラグ,予備フラグ フラグにはS(SYN)、F(FIN)、R(RST)、P(PSH)、A(ACK)、U(URG)を指定可能 予備フラグには1、2、0(フラグがセットされていないパケットにマッチさせる)が指定可能 |
| flag | flagsオプションより複雑なフラグの条件を記述可能 |
オリジナルルールにはノイズが存在し、それによって頻繁にアラートが上がってくる
それらをSnortルールエンジンの機能で抑制する
- アラート出力に必要な特定のIPアドレスに対するマッチの最低回数を指定する
- 指定した時間範囲内で出力するアラートを制限する
- 2種類の使用方法がある
- シグネチャIDによる制御：シグネチャIDでルールを分類してしきい値を与える
- ルールオプションによる制御：しきい値をルール内に直接記述する
- ルールをコメントアウトしなくとも特定のIPアドレス(アラート)に対する出力を抑制する
下記で実際にオリジナルのSnortルールを設定する方法を解説する
- IDSをステルス化して、IDS自身が不正アクセスを受けるのを防ぐ
- IDS自身が不正アクセスを受けると、不正アクセスを検知できなくなって危険性が増大する可能性がある
IDSは不正アクセスを検出すると、アラートを出して、攻撃者の振る舞いを記録してくれるので、攻撃者を追跡する貴重な証拠となる
上記のようにIDSの情報は慎重に取り扱わなければならないため、IDS自身が不正アクセスを受けることがあってはならない
しかし、IDSが通常のネットワーク上にあると、その可能性を低くできない
そこで、IDSを通常のネットワークから切り離し(ステルス化)てIDS自身への不正アクセスを防止する
- IDSの監視用ネットワークインタフェース(プロミスキャスモード)をIPアドレスを与えないで有効化する
- 上記によって、監視用ネットワークインタフェースを経由したIDSへのアクセスが不可能になる
下記でIDSの監視用ネットワークインタフェースをステルス化する具体的な方法を解説する