令和6年度 春期 情報処理安全確保支援士試験 午後 問2｜VPNの「入口」とWebサーバの「窓口」が同時に狙われた日—情報処理安全確保支援士で学ぶDDoSと多要素認証フィッシングの実例

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

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

• 出典: 令和6年度 春期 情報処理安全確保支援士試験 午後 問2

• 主なテーマ: DDoS攻撃（HTTP GET Flood）、IPS/IDSのしきい値検知と誤検知、VPNを狙った攻撃、多要素認証のリアルタイムフィッシング（AiTM）、SPA（Single Packet Authorization）とリプレイ攻撃耐性、CDN・クラウドWAF・ISPによるDDoS防御、UTM、アクセス制御の見直し

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

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

リモートワークが当たり前になり、社外から社内ネットワークへ入る「入口」としてVPN（Virtual Private Network：インターネット上に暗号化された専用トンネルを作り、社外から社内へ安全に接続する仕組み）を使う企業は珍しくありません。同時に、取引先や一般の利用者に向けてWebサーバという「窓口」を開いている企業も多いはずです。この入口と窓口は、どちらも「外部に開いている」という共通点を持ちます。そして外部に開いているものは、必ず攻撃の標的になります。

情報処理安全確保支援士試験の令和6年春期 午後 問2は、まさにこの二つの脅威——VPNを狙った侵入と、Webサーバを狙ったDDoS（Distributed Denial of Service：分散型サービス妨害。多数の機器から大量の通信を送りつけ、対象を機能不全に追い込む攻撃）——を一本の物語の中で扱っています。しかも、VPNを狙う攻撃のなかでも、近年急増している「多要素認証を突破するリアルタイムフィッシング」という、対策が一歩遅れがちな手口が中心に据えられています。

この記事を読むと、「多要素認証を入れたのに突破される」とはどういうことなのか、ポート（通信の出入り口に割り当てられた番号）を隠す対策がなぜ盗聴で破られ、SPAという仕組みならなぜ破られないのか、そしてDDoSに対して自社の設備だけで戦うことの限界がどこにあるのかが見えてきます。受験者にとっては記述式で差がつく論点が詰まっており、経営者・管理職にとっては「セキュリティ製品を入れた＝守れた」という思い込みを見直す教材になります。

インシデントの概要

舞台は、従業員3,000名を抱える製造業のH社です。H社は自社製品を作るだけでなく、その部品を製造する約500社の取引先と日々取引をしています。取引先は、H社が用意した「取引先向けWebサーバ」にHTTPS（通信内容を暗号化したWeb通信）でアクセスし、利用者IDとパスワードでログインしたうえで、発注や納品といった取引業務を行っていました。一方、誰でも見られる「公開Webサーバ」では、H社製品の紹介に加えて、問合せや要望の受付も行っています。重要なのは、この二つのWebサーバはどちらも、止まれば業務に支障が出るという点です。取引が止まれば部品の供給網が乱れ、公開窓口が止まれば顧客との接点が消えます。

H社では、社内に置いたPC（以下、H-PC）とは別に、一部の従業員にVPNクライアントソフトウェアを入れたリモート接続用PC（以下、R-PC）を貸し出し、リモートワークを実現していました。R-PCとH社のあいだのVPN通信には、VPNゲートウェイ（VPN-GW：社外からのVPN接続を受け止める出入口の装置）が使われ、H社が使っているこの装置を「VPN-H」と呼びます。ネットワーク全体は、情報システム部のL部長とT主任を含む、わずか6名で運用されていました。3,000名規模の会社のネットワークを6名で守る——これは特別に手薄なわけではなく、多くの企業に共通する現実的な体制です。

H社のネットワークでは、DMZ（非武装地帯：インターネットと社内のあいだに置く、外部に公開するサーバ用の中間領域）に取引先向けWebサーバ、公開Webサーバ、DNSサーバ、プロキシサーバ、メールサーバ、そしてVPN-Hが並んでいました。これらの手前にはUTM（Unified Threat Management：統合脅威管理。ファイアウォールやIPSなど複数の防御機能を一台にまとめた装置）が置かれ、通信の出入りを制御しています。

ところがこのUTM、設定を見ると気になる点がありました。ファイアウォール機能（通信の許可・拒否を制御する機能）は有効でしたが、IPS機能（Intrusion Prevention System：不正な通信を検知して遮断する機能）とWAF機能（Web Application Firewall：Webアプリへの攻撃を検知・遮断する機能）は、どちらも無効になっていたのです。守りの装置は持っているのに、肝心の機能を眠らせている——この状態が、後の調査で重い意味を持ってきます。

そんなとき、同業他社でサイバー攻撃による被害が立て続けに2件発生したという報道が、L部長とT主任の耳に入ります。1件はVPN-GWが攻撃を受け、社内ネットワークに侵入されて情報漏えいが起きた事案。もう1件はDDoS攻撃による被害です。「うちでも同じことが起きるのではないか」——二人はそう考え、自社の備えを点検する調査を始めました。これは事故が起きてからの後始末ではなく、起きる前の予防の物語です。

何が起きたのか

調査はまず、VPN-GWを狙った攻撃から始まりました。T主任は、攻撃者がVPN-Hに侵入する道筋を二つに整理します。

一つ目は「認証情報を推測して入る」道。利用者IDとパスワードを当ててしまえば、VPN-Hは正規の利用者と区別がつきません。二つ目は「製品の弱点を突いて入る」道。VPN-Hの製品名や型番を調べ上げ、その製品に既知の脆弱性（プログラムの欠陥）があれば、それを悪用して侵入するという手口です。装置の「身元」がわかってしまえば、攻撃者は弱点をピンポイントで狙えます。

T主任はそれぞれに対策案を立てました。認証情報を推測される道に対しては、VPN-Hの認証を強化する。具体的には、インターネットからVPN-Hにアクセスするときに多要素認証（MFA：Multi-Factor Authentication。パスワードに加えて、スマートフォンへの通知やSMSの確認コードなど、複数の要素で本人確認する仕組み）を求める。製品の弱点を突かれる道に対しては、脆弱性が出たら直す対策に加えて、そもそも装置の存在を外から見えにくくする「ステルス化」を検討します。攻撃者がポートスキャン（どのポートが開いているかを外から探る行為）をしても応答を返さなければ、装置の存在自体に気づかれにくくなる、という発想です。

ここまでは、教科書どおりの堅実な対策に見えました。しかし、多要素認証の強化を検討するなかで、T主任は近年の攻撃の巧妙さに直面します。

多要素認証は「パスワードが盗まれても大丈夫」と思われがちです。ところが攻撃者は、その安心の隙を突く新しい手口を編み出していました。リアルタイムフィッシング、あるいは中間者型攻撃（AiTM：Adversary-in-the-Middle。攻撃者が利用者と正規サイトのあいだに入り込み、やり取りをその場で中継してしまう手口）と呼ばれるものです。

その流れはこうです。まず攻撃者はフィッシングメール（正規を装ってだます偽メール）を使い、VPNダイアログ（VPN接続時に利用者IDとパスワードを入力させる画面）そっくりに作った罠のWebサイトへ正規利用者を誘導し、利用者IDとパスワードを入力させます。ここまでは普通のフィッシングと同じです。怖いのはこの先でした。攻撃者は盗んだIDとパスワードを、その場で本物のVPNダイアログに入力します。すると正規の手順どおり、正規利用者のスマートフォンにSMSでセキュリティコード（一度きりのワンタイムコード）が送られます。利用者は「さっき自分が操作したからコードが来たんだな」と思い込み、受け取ったコードを、先ほどの罠のWebサイトに入力してしまいます。攻撃者はそのコードを横から読み取り、本物のセキュリティコード入力画面に間髪入れず打ち込む——こうして多要素認証は突破され、攻撃者は社内ネットワークへ不正に接続できてしまうのです。

ここで多くの読者が「ではURLリンクをクリックしないよう注意喚起すればいい」と考えるでしょう。L部長もまさにそう提案しました。ところがT主任の返答は現実的でした。H社では業務の手続の督促などで、従業員にURLリンク入りのメールを日常的に送っている。リンクのクリックそのものを禁止することはできない。不審なURLかどうかを見極めさせるのも難しい。だからこそ、たとえ罠のサイトを開いてしまっても不正な接続をされない、別の防ぎ方が必要だ——二人はそう結論づけました。

VPNの入口を固める一方で、T主任はもう一つの脅威、DDoS攻撃の調査にも取りかかりました。H社で未対策の攻撃を洗い出すと、偽の送信元IPアドレスとランダムな宛先ポート番号を設定したUDPデータグラム（相手の応答を待たずに送る通信の単位）を大量に送りつけるUDP Flood攻撃、接続要求だけを浴びせるSYN Flood攻撃、DNSの仕組みを悪用して他者への攻撃の踏み台にされるDNSリフレクション攻撃、そして大量のHTTP GETリクエスト（Webページの「ください」という要求）を浴びせるHTTP GET Flood攻撃が並びました。

T主任は、これらの攻撃によるサーバへの影響は、眠らせていたUTMのIPS機能とWAF機能を有効にすれば軽減できると見立てます。ただし、その設定には落とし穴がありました。アノマリ型のIPS機能（あらかじめ決めたしきい値を超えた通信を異常とみなして検知する方式）は、トラフィック量のしきい値を高くしすぎれば攻撃を見逃します。だからといって低くしすぎても弊害が出る——平常時の正常な通信まで「異常」と判定してしまい、業務を止めかねないのです。攻撃を防ぐはずの機能が、設定を誤れば自社の足を引っ張る。守りの装置とは、入れれば終わりではなく、ちょうど良い加減を見極めて初めて役に立つものだ、という現実がここにありました。

そしてVPNのステルス化の検討は、思わぬ深みへと進んでいきます。T主任が提案したのは、VPN-Hに「Deny-All」（すべての通信要求に応答しない設定）をかけたうえで、あらかじめ決めた順番でポートを叩いた相手にだけ接続を許す仕組み——いわゆるポートノッキング（決まった順序でポートを「ノック」した者だけを通す方式。この設定をPと呼びます）でした。一見すると、順番という「合言葉」を知らない攻撃者は門前払いになり、安全に思えます。しかしL部長の「注意点は?」という問いに、T主任は冷静に弱点を指摘しました。順番を攻撃者が知らなくても、もし攻撃者が何らかの方法で通信パケットを盗聴できれば、設定Pは破られてしまう、と。

なぜか。盗聴した通信をそのまま、同じ順番で送り直せばいいからです。これがリプレイ攻撃（盗み見た正規の通信を録音テープのように再生して、本人になりすます手口）です。合言葉を理解する必要すらない。聞こえたとおりに繰り返すだけで、門は開いてしまうのです。

そこでT主任が持ち出したのが、SPA（Single Packet Authorization：単一パケット認可。たった一つのパケットで送信元の正当性を認可する仕組み）でした。SPAの仕様を見ると、リプレイ攻撃に対する備えが何重にも織り込まれています。送信元の正当性は、HMACベース（共通の秘密の鍵とハッシュ関数を使って計算する改ざん検知の方式）のワンタイムパスワードで検証されます。さらにSPAパケットにはランダムなデータが含まれ、もし以前受信したものと同じランダムデータを持つパケットが届けば、それは「使い回し」とみなして破棄されます。加えて、パケットの末尾には先行する部分のハッシュ値（データから計算される指紋のような値）が入っており、改ざんされていればやはり破棄。しかも検証結果は送信元に返さないため、攻撃者は成功したのか失敗したのかすら知ることができません。

だからこそ、T主任は言い切りました。SPAなら、攻撃者がパケットを盗聴できたとしても突破はされない、と。盗み見たパケットをそのまま再生しても、SPAパケットは一つひとつがユニーク（唯一無二）であり、同じものを再利用すれば即座に破棄される。リプレイ攻撃そのものが成立しないのです。

L部長は、VPN通信機能と同等の機能を持ちながらSPAを採用している製品がないか、ベンダーに相談することにしました。そして紹介されたのが、S社のアプライアンス（特定の用途に特化した専用機器。以下、S-APPL）でした。S-APPLは、VPN通信機能、SPAパケットを検証する機能、多要素認証機能、そしてVPN確立後にアクセスできるサーバをPCごとに制限する「接続サーバ許可機能」を備えています。接続元のPCにはエージェントソフト（Sソフト）を入れ、PCごとのIDと秘密情報を双方に設定する。これらの対策が、VPNを狙う攻撃への総合的な答えになっていきました。

最後に残ったのが、DDoSへの具体的な対策です。ここでT主任は、自社の設備だけでは越えられない壁にぶつかります。DDoS攻撃で大量のトラフィックが押し寄せると、通信回線そのものが詰まって使えなくなる。これは社内のUTMをいくら強化しても防げません。回線の入口より手前で溢れてしまうからです。解決策は、通信回線の帯域（通信の太さ）を広げるか、あるいは外部のサービスを利用すること。そして取引先向けWebサーバについては、アクセスできる経路そのものを絞り込むという、攻撃の影響をさらに小さくする一手が見えてきます。こうしてH社は、VPNの入口とWebサーバの窓口、その両方の守りを固め直し、新たな運用へと踏み出していきました。