【VPN・リモートアクセス編】外部公開された入口をどう守るか｜CTF思考フレームワーク #24

こんにちは、アンペンです。

VPNは「裏口」ではなく「表に出ている正規の入口」

VPNという言葉には、暗号化、社内接続、安全な通信という印象があります。しかし、攻撃者目線では少し違います。VPNはインターネット側から到達できる、認証付きの入口です。つまり、Webログイン画面やSSHと同じように、外から存在を観察されます。

もちろん、VPNが悪いわけではありません。問題は、入口が古いまま残っている、認証が弱い、MFAがない、許可された利用者が多すぎる、ログ監視が弱い、といった運用上の隙です。CTFでは、この「入口としての性質」を読むことで、次に確認するべきポイントが見えてきます。

VPNって暗号化されているなら、安全なんじゃないの？

暗号化は通信の保護です。入口の公開状態、認証の強さ、利用者管理、ログ監視は別問題として確認します。

観察：外から見える入口を洗い出す

CTFで最初に見るのは、外から公開されているサービスです。VPN製品は、Webポータル、SSL-VPN、IPsec、OpenVPN、WireGuard、RDPゲートウェイなど、環境によって見え方が違います。まずは対象範囲内でポートとバナーを確認し、どの種類の入口なのかを推測します。

nmap -sV -Pn -p 443,500,4500,1194,51820,8443 target.example
curl -I https://target.example/
openssl s_client -connect target.example:443 -servername target.example

ここで得たいのは、単なるポート一覧ではありません。443番にWebポータルがあるのか、8443番に管理画面らしきものがあるのか、500/4500番でIPsec系が見えるのか、1194番でOpenVPNらしさがあるのか、51820番でWireGuardの可能性があるのか。観察結果から「どの入口を見ているのか」を言語化します。

また、HTTPヘッダーや証明書の情報も手がかりになります。製品名、バージョン、組織名、古い証明書、社内向けのホスト名が見えることがあります。CTFでは、そこから既知の設定ミスやデフォルトパスへ進むことがあります。実務では、外部に出してよい情報かどうかを点検します。

仮説：入口が危ないのはどんなときか

VPNやリモートアクセスが危険になる典型は、技術そのものより運用にあります。たとえば、古い製品バージョンが放置されている、MFAがない、退職者アカウントが残っている、共有アカウントがある、管理画面が同じ場所にある、失敗ログを見ていない、といった状態です。

CTFで「VPNっぽい入口」が見えたときは、まず認証突破を急ぐのではなく、周辺情報を集めます。ログイン画面に製品名が出ているか。エラーメッセージに違いがあるか。証明書にサブドメイン名があるか。robots.txtや公開ドキュメントに管理者向けURLが残っていないか。これらは、攻撃ではなく観察として確認できます。

ログイン画面が見えたら、IDとパスワードを試す流れになる？

CTFで明示されていない限り、むやみに試行しません。まずは製品、公開情報、証明書、エラーの違いなど、観察で得られる根拠を集めます。

検証：入口の種類ごとに確認する

VPN・リモートアクセスの確認では、入口の種類ごとに見るポイントが変わります。Webポータルなら、レスポンスヘッダー、HTML内の製品名、パス、証明書、リダイレクト先を見ます。IPsecなら、UDP 500/4500の存在やIKEの応答が手がかりです。OpenVPNやWireGuardは、ポートとプロトコルだけでは断定しにくいので、設定ファイルや問題文の情報と合わせて判断します。

失敗しやすい見方：VPNを見つけただけで危険と決めない

VPNが外から見えること自体は、必ずしも脆弱性ではありません。リモートワークや保守のために、外部公開が設計上必要な場合があります。問題は、意図して公開されているか、認証が十分か、運用されているか、監視されているかです。

Writeupでも、「VPNポートが開いていた。危険」とだけ書くと弱いです。「443番にSSL-VPNポータルがあり、証明書とHTMLから製品名を確認した。ログイン画面にはMFA表示がなく、バージョン情報が見えていた。CTF範囲内で既知のデフォルトパスを確認した」のように、観察と判断を分けると読みやすくなります。

守る側：VPNを踏み台にしないための管理

守る側で最初に行うべきなのは、入口の棚卸しです。どのドメインやIPでVPN・リモートアクセスを公開しているか。誰が使っているか。MFAは必須か。証明書やクライアント設定は失効管理されているか。ログは見ているか。これらを表にして、所有者と責任範囲を明確にします。

次に、認証を強くします。パスワードだけに依存せず、MFAを必須にします。退職者や委託先のアカウントを定期的に見直します。共有アカウントをなくし、利用者ごとのログを残します。接続元の国やIP範囲を制限できるなら、業務に必要な範囲に絞ります。

最後に、ログと検知です。VPNは成功ログだけでなく、失敗ログが重要です。短時間に失敗が増えていないか、普段と違う国や時間帯から接続されていないか、成功直後に内部リソースへ不自然なアクセスがないかを見ます。VPNは入口なので、入口を通った後の行動まで見ないと、侵入の早期発見につながりません。

MFAを入れれば、それでVPN対策は終わり？

MFAは強い対策ですが、入口の棚卸し、古い製品の更新、アカウント管理、ログ監視まで合わせて考えます。

演習での進め方：観察から優先順位を作る

VPN・リモートアクセス系の演習では、最初から「突破する方法」を探すより、外から見える入口を整理する方が安定します。対象に複数のポートがある場合、まず通常のWeb、管理画面、VPNポータル、リモートデスクトップ系の入口を分けます。同じ443番でも、通常サイト、SSL-VPN、リバースプロキシ、RDPゲートウェイでは意味が違います。

次に、入口ごとに「何が分かっていて、何がまだ分からないか」を書きます。たとえば、vpn.example.com が証明書に載っていることは分かっている。ログイン画面は見えている。製品名はHTML内に出ている。バージョンは不明。MFAの有無は画面からは断定できない。このように分けると、無理に結論へ飛ばずに済みます。

優先順位は、問題文のヒント、現在到達できるか、製品名が分かるか、認証前に見える情報があるかで決めます。CTFでは、問題文が「外部公開された入口」「古いリモートアクセス」「認証情報の使い回し」などを示唆していることがあります。その場合、単にポートが開いているものより、問題文の語彙と一致する入口を先に見ます。

ここで大切なのは、失敗した確認も残すことです。たとえば、8443番を確認したが通常のWeb管理画面ではなかった、HTTPヘッダーに製品名は出なかった、証明書のSANに追加のサブドメインはなかった、という結果も意味があります。失敗を残すと、なぜ別の入口へ移ったのかが読者に伝わります。

報告での見せ方：危険度は根拠と一緒に書く

VPNの記事でありがちな弱さは、「公開されているから危険」「MFAがなさそうだから危険」と短くまとめてしまうことです。公開自体が設計上必要な場合もありますし、MFAの有無はログイン後や運用資料を見ないと分からないこともあります。そのため、危険度を書くときは、必ず根拠と不確実な点をセットにします。

たとえば、「外部からSSL-VPNポータルに到達できる。製品名がHTMLから読み取れる。バージョンは未確認。ログイン画面上にMFAの表示はないが、実際の適用有無は未確認。したがって、現時点では『外部公開入口として棚卸し対象』であり、追加確認としてバージョン、MFA、ログ監視、利用者棚卸しが必要」と書けば、実務でも使える報告になります。

CTFでも同じです。答えに直接関係しなかった確認を省きすぎると、解法が飛びます。入口の種類を推測し、候補を絞り、不要な仮説を落とし、最後に有効な手がかりへ進む。この流れがあると、読者は「なぜそこを見たのか」を理解できます。

CTFのWriteupでは、入口から内部へどう考えたかを書く

VPN・リモートアクセス系のWriteupでは、認証情報や答えだけを書くと学びが少なくなります。外から何が見えたのか、製品や入口の種類をどう推測したのか、どの情報を根拠に次の確認へ進んだのかを書きます。

たとえば、「Nmapで443番と8443番が開いていた。443番は通常のWeb、8443番は証明書とHTMLからSSL-VPNポータルと判断した。ログイン画面の製品名からバージョンを推測し、問題文のヒントと合わせて設定ファイルの露出を疑った」という流れなら、読者は思考を追えます。

次に読みたい記事

次回は、SMB・ファイル共有編です。VPNのような入口から内部へ入った後に、ファイル共有がどのような手がかりやリスクになるのかを見ていきます。

SMB・ファイル共有編へ進む →