HTTPベースでバックドア通信を遮断する

　前回の記事で説明したように「新しいタイプの攻撃」における共通脅威パターンは5つあります。この5つそれぞれに対して“出口対策”を施す必要があります。

　共通パターンを改めて見てみると、5つのパターンのうちパターン1～3の3つがバックドア通信に関するものです。つまり、バックドアに対する対策が「新しいタイプの攻撃」への対応策として有効ということがわかります。

　実際のシステム設計や構築では、まずHTTPプロトコルを使うパターン1と、独自の通信プロトコルを使うパターン2に対して何らかの制限を設け、バックドアの通信を遮断します。この遮断が通過された場合のパターン3に対しても対策を施すという考え方になります（図3-1）。

図3-1●パターン1とパターン2はファイアウォールによりほぼ同じ対策で対応できます

これをすり抜けた場合がパターン3で、そのための追加の対策が必要となります。

[画像のクリックで拡大表示]

80番ポートを使う通信に監視の目を光らせる

　まずパターン1とパターン2について見ていきましょう。パターン1と2はいずれもプロキシを経由せずに、外部と80番ポートを使って通信しようとします。つまり、社内からの通常のWeb閲覧通信に紛れて、外部サーバーの80番ポートへ接続しようとするのが特徴です。通信内容そのものは単純なウイルスの場合で独自プロトコルを、やや複雑なウイルスの場合でHTTPを使います。いずれも通信内容をログから確認することで特定が可能です。

　侵入した脅威はシステムの外に向けてバックドアを開いて通信を試みます。まずこの外向けの通信を明確に遮断するルールを適用します。その上で、ファイアウォールが遮断した通信記録がないかを確認すれば、システム内部にウイルスが混入しているかどうかをチェックできます。感染している端末の特定も可能でしょう。遮断に成功すれば、ウイルスへの外部からの命令も届かず、ウイルスが窃取した情報があったとしても外部に漏れることもありません。

　この2つの共通パターンに対しては「サービス通信経路設計」による対策が有効です。具体的には次の2点を実施します。

• ファイアウォールの外向け通信に遮断ルールを設定
• ファイアウォールの遮断ログを監視

　実際の設定は次のようになります。まず、ファイアウォールでは内部プロキシ（あるいはアプリケーション・ゲートウエイ）経由の外向け通信のみを許可するように設定し、プロキシを使わない端末から外部への通信についてはすべて遮断します。それでも外部のサーバーに向けて80番ポートを使って通信しようとするTCP通信があれば、C&Cサーバーとのバックドア通信の可能性があると判断できます。

　この運用に合わせて、外部に対してアクセスする必要がある各種サービスも、内部プロキシを中継するように設計します。これらの通信はOSやソフトウエアのアップデートに使用されるものであり、一律には遮断できません。具体的には、以下のようなものがあります。

　こうした例外の中には、プロキシ経由でのアップデートを設定できないものも、いくつか存在します。その場合でも、むやみに例外対象としてセキュリティ・ホールを作るのではなく、共有ファイルサーバーなどを用意した上で、このサーバーを経由してアップデートするといった工夫が必要です。システム管理者が安全なPCを使って、社内ネットワークとは別の契約回線経由でアップロードファイルを入手し、それを共有サーバーに配備するといった運用も検討してください。

　通信の遮断に成功したら、ファイアウォールのログを分析してウイルスによるバックドア通信を発見します。感染端末は特定しなくてはなりません。ファイアウォールのログ保存期間はバックドア通信活動のタイミング（スリープ、キープアライブ）実績から見積もりましょう。