平成30年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問2|持ち帰ったノートPCが工場を蝕む—情報処理安全確保支援士で学ぶネットワークワーム感染の実例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 平成30年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問2

• 主なテーマ: ネットワークワーム、445/TCP（ファイル共有）の悪用、ポートスキャン、ネットワークフロー情報による検知、DHCPログ突き合わせ、VLANによる感染遮断、STIX

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「社外に持ち出したノートPCを、いつものように社内のネットワークにつないだ」——たったそれだけのことが、工場全体を巻き込むインシデントの引き金になりました。情報処理安全確保支援士の午後Ⅰで出題されたこの事例は、ネットワークワーム（自分自身の複製を次々と他の機器に送り込み、人の操作なしに感染を広げるマルウェア）が社内ネットワークで暴れる様子を、克明に描いています。

2017年に世界を襲ったWannaCryは、Windowsのファイル共有機能（445番ポート）の脆弱性を突いて、人の手を介さずに猛烈な速さで広がりました。この事例のワームVは、そのWannaCryをほぼなぞった存在です。怖いのは、誰かが不注意にファイルを開いたわけでもなく、ただネットワークにつながっているというだけで感染が連鎖していく点にあります。

この記事を読むと、ワームがどうやって増殖するのか、IDS（不正侵入検知システム）のアラートが鳴らなくても異常を見つける方法、そしてログを突き合わせて感染源をどう特定するのかが見えてきます。受験者にはログ解析とインシデント対応の論点が、ネットワークを運用する管理者には「外に出たPCをどう迎え入れるか」という実務の急所が見えてくるはずです。

インシデントの概要

舞台は、従業員数1,200名の製造業者、G社です。本社のほかに四つの工場を持ち、工場には無線LANのアクセスポイント（AP）が導入されていました。

G社は、ネットワークの監視にそれなりに投資していました。本社と各工場には、レイヤ3スイッチ（L3SW。IPアドレスをもとに通信を振り分ける装置）と、NSM（ネットワークセキュリティモニタリング）のセンサが置かれています。NSMセンサは、攻撃のパターンを登録しておいて一致を検知するシグネチャ型のIDS機能に加えて、ネットワークフロー情報（NF情報）を記録する機能を備えていました。NF情報とは、流れる全パケットのヘッダを見て、「いつ・どこから・どこへ・どのポートへ・どのプロトコルで・何バイト」といった通信の概要を、コネクション単位で記録したものです。中身までは見ませんが、「誰が誰とどれだけ通信したか」という流れが分かる。これらは管理ネットワークを通じてNSM管理サーバに集約され、統合管理されていました。

つまりG社は、攻撃のシグネチャに引っかかる「既知の攻撃」だけでなく、通信の量やパターンの異常からも、おかしな兆候を捉えられる態勢を持っていたのです。この「中身は見えなくても流れは見える」仕組みが、のちに事態を救うことになります。物語は、ある日のアラートメールから始まります。

何が起きたのか

ある日、セキュリティ管理部のJ主任のもとに、NSM管理サーバから一通のアラートメールが届きました。J主任は、部下のM君とともに調査を始めます。

NSM管理サーバのダッシュボードを確認すると、奇妙なことに気づきます。シグネチャ型のIDS機能のアラートは、一つも発生していなかったのです。既知の攻撃パターンには、何も引っかかっていない。にもかかわらずアラートメールが届いたのは、通信量が普段の2倍以上に膨れ上がっていたからでした。攻撃の「型」ではなく、通信の「量」の異常が、最初の手がかりだったのです。

直近1時間のコネクション件数を表示させると、異常は一目瞭然でした。送信元IPアドレス別では、`10.100.130.1`という一つのアドレスが、4,000万件以上という桁外れの件数で突出しています。宛先ポート別では、`445/TCP`——ファイル共有に使われるポート——へのコネクションが4,600万件以上と、これも異常な多さでした。さらにTCPステータス別を見ると、「SYNに対して応答なし」が4,000万件以上。つまり、ある機器が445番ポートに向けて接続要求（SYN）を浴びせるように送り続け、その大半が応答を得られずに終わっていたのです。

J主任には、思い当たることがありました。以前、セキュリティ機関から「ワームV」に関する注意喚起を受け取っていたのです。注意喚起によれば、ワームVはWindowsの脆弱性を悪用し、ファイル共有で使われる445/TCPを経由して感染を広げ、複数の組織でネットワーク障害を起こしているとのことでした。ワームVは二種類のIPアドレス範囲を並行してスキャンします。一つは「感染したPCと同じセグメント（同じネットワークのまとまり）の範囲」、もう一つは「`1.1.1.1`から`223.255.255.255`という広大な範囲」。各IPアドレスに1パケットずつ接続要求を送り、正常な応答が返ってきた相手に対して、脆弱性を突いて感染を試みる——まさに、ダッシュボードに現れた「445番ポートへの大量の接続要求」と「応答なしの山」に符合していました。

J主任はワームVが原因だと仮定して分析を進めます。送信元の突出した`10.100.130.1`が、感染源の有力候補です。一方で、宛先IPアドレス別の上位を見ても、ファイルサーバやWebサーバなど普段と変わらない顔ぶれで、ワームのスキャン先は上位に登場していませんでした。これは矛盾ではなく、ワームのスキャンの性質を表していました。広大なIPアドレス範囲に1パケットずつばらまくため、特定の宛先への集中が起きず、件数ランキングには現れないのです。そして「SYNに対して応答なし」が多いのも、存在しない相手や応答しない相手へスキャンを撃ち続けているからだと理解できました。

J主任は決断します。`10.100.130.1`の機器がワームVに感染している可能性が高い。ネットワークの停止をアナウンスしたうえで、L2SW（レイヤ2スイッチ）で、その機器がつながる物理ポートをシャットダウンしました。出血を止める、初動の止血措置です。

しかし、話はそれで終わりませんでした。調べてみると、`10.100.130.1`はルータとして動作しているAPに割り当てられたIPアドレスだったのです。APはNAPT（複数の機器が一つのIPアドレスを共有してインターネットにつながる仕組み）でアドレスを変換しており、その先にぶら下がる無線LANのPCのどれかが、本当の感染源でした。`10.100.130.1`の裏には、複数のPCが隠れていたのです。

ここからが、この事例の白眉とも言える調査です。M君は、APの通信ログとDHCPサーバログ（どのPCにどのIPアドレスをいつ貸したかの記録)を突き合わせ、感染PCを一台ずつ特定していきます。APの通信ログには、445番ポートへスキャンを行った変換前のIPアドレス（`192.168.0.32`、`192.168.0.8`、`192.168.0.44`、`192.168.0.12`）と、その時刻が記録されていました。一方、DHCPサーバログには、それらのIPアドレスが、各時刻にどのPCに貸し出されていたかが記録されています。

ここに巧妙な落とし穴がありました。DHCPのリース期間（IPアドレスの貸出期間）はわずか1時間。同じ`192.168.0.32`でも、時刻が違えば貸し出されているPCは別物です。たとえば`192.168.0.32`は、14時台にはあるPCに、16時台には別のPCに割り当てられていました。スキャンの時刻と、その時刻のリース状況を丁寧に照合しなければ、感染PCを取り違えてしまう。M君はこの突き合わせを正確に行い、感染していたのが6台のPC——PC101、PC133、PC277、PC301、PC321、PC340——であることを突き止めました。

決定打は、無線LANのパケットキャプチャ（通信内容の記録）でした。これら6台のPCが、ARPリクエスト（同じネットワーク内で相手のMACアドレスを調べる問い合わせ）をブロードキャスト（全員に一斉送信）で送り、同一セグメント内のPCを探索していたのです。これは、ワームVが「同じセグメントの範囲」をスキャンする動作そのものでした。セキュリティ機関から提供されていたワームVのインディケータ情報（攻撃の痕跡を示す指標。STIXという標準形式で提供）を使ってファイルを検索すると、6台ともワームVに感染していることが確認されました。

そして、感染の源流もたどり着きます。通信ログとワームVのファイル作成日時から、最初に感染したのは`192.168.0.32`のPCでした。このPCは社外に持ち出されて公衆無線LANに接続された際、セキュリティ修正プログラムが未適用で、マルウェア対策ソフトの定義ファイルも更新されていない無防備な状態だった。そこでワームVに感染し、何食わぬ顔で工場に持ち帰られ、社内ネットワークにつながれた瞬間、増殖を始めたのです。G社は、PCを社外に持ち出す際の情報漏えい対策はしていました。しかし「社外で感染したPCを持ち帰る」というリスクは、まったく想定していませんでした。守りの向きが、外向きだけだったのです。