内部でひそかに拡大する最新サイバー攻撃と対策：セキュリティ強化塾（2/3 ページ）

[キーマンズネット]

サイバー攻撃の7つの段階

　まずはサイバー攻撃の全体像を捉えておこう。その典型例は図1のように7段階で進行するシナリオだ。

図1 サイバー攻撃の7つの段階（出典：IPA）

　図1における（1）攻撃立案段階と（2）攻撃準備段階についての対策は非常に困難だ。攻撃準備は基本的には組織の公開情報や従業員のブログやSNSなどに含まれる関係者および連絡先に関する情報収集だ。中にはメールの中間者攻撃による盗聴の手口も利用されるが、総じて情報システム側で発生に気付くことが難しい。

　既存の対策は、メールのウイルスチェックやフィルタリングだ。これらの「入口対策」はスパムメール防止に有効で、ブラックリストに掲載された送信元や既知のウイルスを含んだメールをブロックできる。

　しかし、送信元が詐称され、添付ファイルが正当なPDFなど文書ファイルの体裁を保ち、しかも仕組まれる不正コードが攻撃のたびに新しいものに差し替えられてしまうような攻撃が行われると有効に働かない。しかも、こうした特徴を持つ攻撃メール作成はエクスプロイトキットと呼ばれる攻撃ツールで簡単に作成できる。

　そこで、入口対策をくぐり抜けたウイルスが、組織内のネットワークを通じて情報を収集したり、外部の攻撃指令用サーバと交信したりすることを防ぐことに重心を置くことになる。それが図1の黄色で示した（4）から（6）の段階だ。この部分について以下に対策を紹介する。

基盤構築段階のシステム設計策

　まずは内部から外部の指令サーバとの通信（コネクトバック通信）を発見し、遮断することが第一のポイントだ。その方法として有効なのは、外部ネットワークとのゲートウェイにプロキシサーバを設置し、以下のような設定を行うことだ。

（1）プロキシサーバを経由しない外部への通信を遮断

【実装】

　外部への通信は全て社内プロキシサーバを経由するようにWebブラウザ設定を強制（図2の「実装事項1）した上で、ファイアウォールでプロキシサーバ経由以外のHTTPおよびHTTPS（SSL）通信ポートを使う外向け通信（ポート80と443）を遮断する設定にする（図2の「実装事項2」）。

図2 ファイアウォールでのコネクトバック通信の遮断（出典：IPA）

　これで標的型攻撃に使われるウイルスのうち、半数以上のコネクトバック通信を遮断できる。プロキシサーバを迂回（うかい）して直接外部の指令サーバと接続できる通信経路を作る仕組みになっているからだ。

【実装上の注意】

　ただし、Windows Update Serverとの通信やウイルス対策ソフト、セキュリティパッチ管理ソフトなど業務で使うサービスでプロキシサーバを経由しない設定になっているものについては、設定をし直してプロキシサーバ経由でサービスに接続できるように設計する。

　また、プロキシサーバ経由のオンラインアップデートができないソフトがある場合は、共有ファイルサーバにアップデートプログラムを用意してオフラインアップデートが行える仕組みを作るとよい。

【運用管理】

　ファイアウォールのログを分析すると、プロキシサーバで遮断されたコネクトバック通信を発見できる。感染PCを突き止めて排除することも可能だ。なお、ファイアウォールの通信ルールは定期的に棚卸しして、不要な通信ルールを残さないようにすることをおススメする。

（2）プロキシサーバをトンネリングしようとするCONNECTメソッドでのリクエストを拒否

　上記の対策で防げない残り約半分のウイルスは、プロキシサーバをいわば「だまして」抜け道を作ろうとする。多用されるのはHTTPリクエストをCONNECTメソッドで行い、プロキシをトンネリングする方法だ。

　ウイルスには、CONNECTメソッドでの通信をランダムな通信ポートを使って行う特徴を持つものが多い。業務で使うポートを80番と443番だけに限るルールにしておけば、それら以外のポートでのCONNECTメソッドによる通信はウイルスからのものと推定できる。

【実装】

　プロキシサーバの設定に「ACL（Access Control List）」を追加し、業務で利用するSSL通信用のポート以外でのCONNECTメソッドでの通信を遮断する。代表的なプロキシサーバである「Squid」の場合を例にとると、図3のような設定にする。

図3 SquidにおけるACL設定例（出典：IPA）

【実装上の注意】

　業務システムでSSL通信以外にCONNECTメソッドを使用する場合は、その使用ポート番号もACLに追加する。

【運用管理】

　プロキシサーバのログを分析して正規ポート以外でCONNECTメソッドでの接続を行う端末を特定すれば、原因が突き止められる可能性がある。全ての不正通信を検知できるわけではないが、不正通信の8割でも網にかけられれば、残りの2割も発生源を突き止めやすくなる。

　なお、ACLが適切でないと業務用の通信まで遮断してしまう可能性がある。定期的に通信ログを確認してACLの見直しを行うとよい。

（3）プロキシサーバの認証機能を有効にする

【実装】

　ユーザー管理機能（ユーザー単位での認証）があるプロキシサーバを設置し、Digest認証などの安全性が高い認証方法（ID／パスワードが平文でネットワーク上に流れないもの）を用いるのも有効だ。

　同時にWebブラウザのオートコンプリート機能を禁止し、ID／パスワードがユーザー端末上に保存されないように（攻撃者に窃取されてしまう可能性があるので）する対策も必要になる。Webブラウザ起動時に毎回IDとパスワードの入力が必要になるが安全が確保できる。

　認証サーバとの連携により、不要なアカウントの削除などのユーザー管理を適切に行いつつ、この方法で対策すると効果的だ。

【運用管理】

　プロキシサーバの認証ログを分析すれば、短時間で大量の認証失敗（ブルートフォース攻撃である可能性）、同一端末からの複数ユーザーIDによる認証失敗（パスワード固定でIDを変化させる攻撃の可能性）、異なる端末から同一ユーザーIDによる認証成功（窃取したユーザーIDの使い回しの可能性）などの異常行動が発見できる。異常な認証失敗や成功を記した端末を特定したり、窃取された可能性のあるユーザーIDを持つ人物の端末調査などに役立つ。

コラム：時間外にプロキシを止めて不正通信を発見する

　ウイルスは常時外部と接続するものが多いので、接続が切れると定期的に再接続しようとする。この特徴を逆手にとって攻撃を検知することが可能だ。

　全ての外部通信がプロキシを経由する設定のまま、業務時間外にファイアウォールの設定を変えてプロキシとの接続を遮断すればよい。その日は従業員にPCを起動したまま帰ってもらい、プロキシとの再接続を試みる通信を記録する。2回以上これを仕掛けると、定期的に再接続を試みる端末、つまりウイルス感染している端末が特定できる可能性が高い。