• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

技術の広場

新米の管理者に贈るちょっと楽しいログの運用・管理法(下)

濱本常義 2003/07/04 ITpro

図14 iplogの稼働に必要なlibpcapライブラリをインストールする手順
図15 iplogをインストールする手順
図16 iplogを起動するコマンド
図17 iplogが出力したログの例
図18 iplogの設定ファイルであるiplog.confの例
表7 iplogが出力したログの解析に使った六つのツール
図19 iplogが出力したログの書式
表8 筆者が実際に設置したサーバで2002年8月11日~9月18日までの間に記録されたiplogログを集計した結果
図20 表8の集計のために使ったコマンド
図21 httpでアクセスしてきた送信元を詳細に調べるコマンド例
表9 iplogが出力したログを図22のコマンドで分析した結果
図22 図21のコマンドを修正してポート情報を抽出しないようにしたコマンド
表10 iplogが出力したログを図23のコマンドで分析し,接続元の国情報を付加した結果
図23 特定の接続元アドレスの情報だけを抽出した例
図24 筆者の設置したサーバにアクセスしてきた数を日付ごとに集計した結果

iplogによるトラフィック監視

 ここまでで,syslogについての基本的な事項について理解してもらえたと思う。次は,ログをさまざまな切り口で調べるノウハウについて話を移す。以下では,TCP/IPトラフィック・ロギング・ツール「iplog」を取り上げ,このツールが出力するログの活用方法について説明する。

 iplogとは,フリーのTCP/IPトラフィック・ロギング・ツールである。どのポートにどこからアクセスがあったのかをすべて保存する。例えば,iplogはsnortと組み合わせて使うと威力を発揮する。フリーのIDSとして有名なsnortの場合,特定のシグネチャに合致したものだけを不正なアクセスとして検知する。裏を返せば,シグネチャが完成していない攻撃を検知することはできない。この弱点をiplogのトラフィック収集機能で補完するのだ。

 iplogの最新版は2.2.3だ(http://prdownloads.sourceforge.net/ojnk/iplog-2.2.3.tar.gz)。http://ojnk.sourceforge.net/のサイトから入手できる。稼働するには,libpcapというライブラリが必要になる。インストールする前に,libpcapがインストール済みかを確認しよう。libpcapのない環境でiplogをインストールしようとするとエラーを起こす。libpcapの現時点での最新版は0.7.1である。libpcapのインストールは,図14[拡大表示]のような順番でコマンドを打てばあっという間に終わる。iplogのインストールは図15[拡大表示]の手順でよい。

iplogの適切な運用法

 iplogは/usr/local/sbin/iplogにインストールされる。起動するには,図16[拡大表示]のように指定すればよい。デフォルト設定では,/etc/iplog.confをオプションなしで設定ファイルとして読み出し,ログは/var/log/messagesに保存する。インストール直後の状態では,/etc/iplog.confファイルはなく,自分で作る必要がある。また,保存ログが/var/log/messagesだと色々な情報にまぎれてしまう可能性が高いため,-lオプションを付けて保存するログ・ファイルの別にした方がよい。図16の例では,/var/log/iplog.logに保存するようにしている。

 これでiplogの起動は完了である。swatchと同じように,このまま運用に入ってもよいし,システム起動時に自動的に立ち上がるように/etc/rc.d/rc.local ファイルに記述してもよい。

 前述のように,「tail -f /var/log/iplog.log」などのコマンドで,iplogが出力するログをずっと見ていると,図17[拡大表示]のようなものが出力される。iplogはデフォルト設定のままだと,すべてのパケットを保存する。このため,iplogをインストールしたサーバがWebサーバやメール・サーバだった場合,ログが膨大な量になってしまう。大容量のハード・ディスクにすべてのログを保存するも一つの手だが,icmpやdnsのパケットを保存したくない場合は設定ファイルであるiplog.confを書き換える。

 例えば,図18[拡大表示]のように設定すれば不必要なパケットを保存しないで済む。iplogの場合,ネットワーク単位で保存しないトラフィックを指定するなど細かな設定が可能だ。詳しくは

# man iplog.conf

コマンドで表示される内容を参照してほしい。iplogの日本語情報が必要なら,みっきーのネットワーク研究所(http://www.hawkeye.ac/micky/index.html)にドキュメントの和訳がある。参考にするとよいだろう。このサイトにはログの見方のノウハウが掲載されており,非常に参考になる。

コマンドを駆使したログ分析法

 では,ワンライナー(1行プログラミング)と呼ばれるプログラミング技法を使って,iplogのログを簡単に分析する手法を紹介しよう。なぜ,ここでiplogを選択したかというと,出力されるログの書式が比較的単純で分析しやすいからだ。しかも,分析して判明する内容が大きな意味を持つ。ログの理解を深めるための良いテキストとなる。ここで選択したコマンド・ライン・ツールは表7[拡大表示]の六つである。

 実際にiplogが出力したログを見てみよう。図19[拡大表示]がその例である。iplogを動かしているサーバに対して,TCPで接続してきたアプリケーションの種類と接続元が記録されている。iplogには他の出力形式もあるが,この形式が一番わかりやすいので選択した。

 表8[拡大表示]は/etc/iplog.confに何も設定しないで収集したデータ/var/log/iplog.logに対して,どのようなアプリケーションのアクセスが多かったのかを集計した表である。筆者が実際に設置したサーバで,2002年8月11日~9月18日までの間に記録されたログを調べた。これは図20[拡大表示]のようなコマンドを使って取得した。sshとWebサーバだけを稼働したサーバに対して,1カ月でさまざまなポート・プローブを受けていることがわかる。また,Webサーバには空白ページかないのに,これだけのアクセスがあったことがわかる。

 2位のms-sql-sは,明らかに「MS SQL Serverを標的としたSQLSPIDAワーム」(http://www.jpcert.or.jp/at/2002/at020002.txt)によるものと思われる。標的になるポート開いていないのに,ご苦労なことである。また,この集計では443番ポートが出てきていない。この原稿執筆時点で猛威を振るいつつあるLinux.Slapper.Wormのアクセスはまだないこともわかる。このように集計すれば,サーバがどのようなアクセスを受けたかの傾向がわかる。

不正アクセスの傾向を知る

 ここで,大量にカウントされたログをさらに詳細に調べれば,不正アクセスの傾向が得られるかもしれない。例として,httpでどういうアクセスがあったのかを調べてみよう。

 まず,図21[拡大表示]のようなコマンドを打ってみた。すると,表9[拡大表示]のように接続元の後ろにポート情報が付加された情報が集計された。ただ,これだと多くのカウント数が「1」になり,集計データを読みにくい。

 そこで修正したのが,図22[拡大表示]のコマンドである。図21と異なるのは,接続元情報のうち「:」で区切られた前の文字列だけを抽出したことだ。これで,ポート情報を消してカウントすることができる。結果は表10[拡大表示]に示す。

 さらに,whoisゲートウェイ(例えばhttp://whois.ansi.co.jp/?key=202.100.249.231)を使ってトップ6の所属する国を調べたところ,インド,中国という順になった。

 ここで,202.68.142.123がどういう動作を行ったかを

# cat iplog.log | grep 202.68.142.123

というコマンドで単純に抽出してみた。図23[拡大表示]がその結果である。8月22日の10時27分~11時までの間に,Webのぜい弱性スキャナを使って広域をスキャンした気配である。これ以上の情報を得ようとした場合は,snortなどに頼らないとならないが,単純にアクセスを受けた頻度は判明する。アクセスの傾向を単純に調べたいときなど,やはりiplogは重宝する。

 このほか,時間ごとの総アクセス頻度を集計したければ,

# cat iplog.log|awk -F: '{print $1}'| uniq -c

というコマンドを実行すればよい。日付ごとにアクセス集計する場合は,

# cat iplog.log|awk -F: '{print $1}'|awk
'{print $1,$2}'| uniq -c

である。これをグラフ化したのが図24[拡大表示]だ。明らかに日曜日の夜から月曜日の朝にかけてアクセス数が多いのが見て取れる。土日の空いた時間によからぬことをやっているのだろう。

 このようにワンライナーのプログラミングともいえないレベルの分析手法でも,色々な切り口で情報が分析できる。さらに詳しく分析するなら,Perlやawkなどで本格的にプログラミングすればよい。考え方はワンライナーの延長のようなもので,非常に簡単だ。

 一見地味に思えるログの運用・管理作業だが,今回はワンライナー分析法など,非常に簡単でしかも効果的な手法を伝えることができたのではないかと思っている。これらの手法は単純な分,非常に応用範囲が広い。今回紹介したアクセス傾向を示すグラフなどは,自社のサーバが実際にどのようなアクセスを受けているか,経営層に理解してもらう資料としても使えるだろう。

 生の情報であるログは,味付け次第でさまざまな活用法が生まれる。ログに親しむには,実践してみるのが近道だ。ぜひ,身近なサーバのログを取得してみるなど,今回紹介したようなツールやテクニックに挑戦してもらいたい。健闘を祈る。

濱本 常義
筆者は中国情報システムサービスに勤務。ソリューション事業本部システム営業部で,セキュリティ対策関連事業に従事している。現在は,主にセキュリティ・ポリシ策定事業に携わっている。セキュリティ関連のメーリング・リスト「connect24h」を運営している。本稿に関する質問や要望はhamamoto@hicat.ne.jpまで。

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

ネットワーク/通信サービス

セキュリティ

もっと見る