株式会社DigeonPublicationへの投稿
📡

ステルスSSID、百害あって一利なし

結友
に公開
4件
Wi-Fi
Security
Network
WPA3
hacklore
tech

ステルスSSID、百害あって一利なし

はじめに

「SSIDを隠せばセキュリティが上がる」

無線LAN設定でこのような運用をしてませんか？
ステルスSSID（Hidden SSID）は、ぱっと見セキュリティ対策に見えますが、現実は効果がないどころか、むしろセキュリティリスクを高めます。

本記事では、ステルスSSIDがなぜ「意味がない」のか、そしてどのような対策が本当に有効なのかを解説できたらと思います
LLMに査読させまくりましたが、誤りがあればコメントで優しく教えていただけると幸いです。

あとこの記事の大半は企業の無線LANが主な話題となります

ステルスSSIDとは何ぞ

通常、Wi-Fiアクセスポイント（AP）は自身のSSID（ネットワーク名）を定期的にブロードキャストしています。
これにより、端末のWi-Fi一覧にネットワーク名が表示されます。

ステルスSSIDは、このBeacon Frame内のSSIDフィールドを空（長さ0）または NULL文字で埋める設定のことです[1]。
Wi-Fi一覧には表示されないか、空のBeacon Frameにより非表示ネットワークと表示され、接続するにはSSIDを手動で入力する必要があったり、複数ある場合唐突にくじ引きが始まり、OSの仕様によってはUX最悪です。

なぜステルスSSIDは「セキュリティ対策」として広まったのか

ステルスSSIDが今でも使われ続けている背景には、Wi-Fi黎明期にあります。

WEP時代の「多層防御」という幻想

2000年代初頭、Wi-FiのセキュリティはWEP（Wired Equivalent Privacy）が主流でしたが、WEPには設計上の致命的な欠陥があり、2001年には数分で解読可能であることが実証されました。
この時代、WEPの脆弱性を補うための「多層防御」として以下の対策が推奨されていました

  • ステルスSSIDの有効化
  • MACアドレスフィルタリング
  • DHCPの無効化（固定IP運用）

当時のセキュリティガイドラインや書籍には、これらが「ベストプラクティス」として記載されていおり、WEPが弱いことは分かっていたため、「少しでも攻撃者の手間を増やす」という発想だったのです。

時代は変わったが、慣習は残った

2004年にWPA、2006年にWPA2が登場し、そして2018年にWPA3が登場しました。
これによりWi-Fiのセキュリティは劇的に向上し、適切に設定されたWPA2/WPA3であれば、ステルスSSIDやMACアドレスフィルタリングは不要です。

しかし、以下のような理由でステルスSSIDは使われ続けています

  • 慣習
    • 「昔からこうしている」
    • 「前任者がそう設定した」
  • セキュリティチェックリスト
    • 古いガイドラインが更新されず、監査項目に残っている
  • 心理的安心感
    • 「見えない方が安全そう」という直感
  • 誤った情報の流布
    • ネット上の古い記事や、それをソースにした内容の無いアフィカス記事が検索上位に現れる

なぜステルスSSIDは意味がないのか

1. SSIDは簡単に発見できる

ステルスSSIDを設定しても、APは「Beacon Frame」を送信し続けてます。
SSIDフィールドが空になっているだけです。

さらに重要なのは、正規の端末がそのネットワークに接続する際、SSIDを含む通信が発生することです。
SSIDが観測される主なポイントは以下の通りです。

フレーム 発生タイミング SSIDの扱い
Probe Request 端末がネットワークを探索 端末がSSIDを指定して送信
Probe Response APがProbe Requestに応答 APがSSIDを含めて応答
Association Request 端末が接続を開始 SSIDを含む
Reassociation Request ローミング・再接続時 SSIDを含む

つまり、接続・再接続・ローミング・周辺探索のどこかで、SSIDを含む管理フレームが観測されるのです。
IEEE 802.11-2020 Section 9.3で定義されるこれらのフレームには、ステルス設定に関わらずSSIDが含まれます。

Wiresharkなどのパケットキャプチャツールでこれらのフレームを傍受すれば、誰でも「隠された（ように見える）」SSIDを発見できます。

つまり、ステルスSSIDは「玄関の表札を外しただけ」のようなもので、家の存在自体を隠すことはできません。

Wiresharkで実際に確認してみる

実際にWiresharkでステルスSSIDがどのように見えるか確認してみましょう。

準備するもの

  • Wireshark（無料のパケットキャプチャツール）
  • モニターモード対応のWi-Fi NIC
  • Linux環境（Ubuntu等）

キャプチャ手順

  1. インターフェース名の確認
iw dev
  1. モニターモード対応かチェック
iw list

出力に以下のような記載があればモニターモード対応です。

Supported interface modes:
         * managed
         * monitor
         * AP
         etc...

* monitor がなければ、そのNICはモニターモード非対応のため別のNICが必要です。

  1. モニターモードに切り替え
sudo iw dev <インターフェース名> set type monitor
  1. Wiresharkでキャプチャ開始

wiresharkを管理権限で起動

sudo wireshark
  • メニューから「キャプチャ」→「オプション」
  • 「すべての802.11インターフェースにおいてモニターモードを有効化します」にチェック
  • 「すべてのインターフェースにおいてプロミスキャスモードを有効化します」にチェック
  • 対象のWi-Fiインターフェースを選択して「開始」
  1. フィルタでProbe Request/Responseを抽出
wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05
  • 0x04: Probe Request
  • 0x05: Probe Response

特定のSSIDを探す場合は、以下のフィルタを使用。

(wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05) && wlan.ssid contains "your_ssid"



実際にとあるステルスSSIDが自宅でのキャプチャに成功している様子

intel:XX:XX:XXがノートPCが送信したパケット
パケットには当該SSIDが含まれている

wiresharkのスクリーンショット

写真の通り自宅で当該パケットがキャプチャできてしまっている

自宅ラボでキャプチャしてる様子、42Uのサーバーラックを添えて

確認できる内容

フレーム種別 表示されるSSID 説明
Beacon Frame （空） ステルス設定のAPからのビーコン
Probe Request Corp-Wi-Fi 端末が発信するSSID名
Probe Response Corp-Wi-Fi APからの応答にSSIDが含まれる

Beacon FrameではSSIDが隠されていても、Probe ResponseにはSSIDが平文で含まれる。
端末がそのネットワークに接続しようとした瞬間、SSIDは露出します。

2. 端末がSSIDを「叫び続ける」問題

ここからが本題です。
ステルスSSIDの本当の問題点は、接続する端末側にあります。

IEEE 802.11では、端末がネットワークを発見する方法としてパッシブスキャンとアクティブスキャンの2種類が定義されています。

通常のSSID（ブロードキャスト有効）の場合：パッシブスキャン

  • APが定期的にBeacon Frameを送信（約100ms間隔）
  • 端末は受動的にそれを受信してネットワークを認識
  • 端末からSSIDを含む情報は発信されない

ステルスSSIDの場合：アクティブスキャンが必須

  • APはBeacon FrameにSSIDを含めない
  • 端末はProbe RequestフレームでSSIDを指定して問い合わせる（Directed Probe Request）
  • APがProbe Responseで応答して初めて接続可能

この「Directed Probe Request」が問題です。
端末は場所を問わず、登録済みのステルスSSIDを探し続けます。
カフェでも、電車の中でも、海外でも。

これは、あなたが接続したことのあるネットワーク名を、周囲に公開し続けていることを意味します。

バッテリー消費への影響

ステルスSSIDには、セキュリティ以外にも問題があります。
バッテリー消費です。

前述のとおり通常であればパッシブスキャンでAPからのBeaconを受信するだけなので少ない電力消費で済みますが、ステルスSSIDに接続するためには、端末はアクティブスキャンを行う必要があります。これは電波の送信を伴うため、受信のみのパッシブスキャンと比較して電力を消費します。

特にモバイル端末では、Wi-Fiのスキャンはバックグラウンドで頻繁に行われます。
登録済みのステルスSSIDが多いほど、その分だけProbe Requestの送信回数が増え、バッテリー消費に影響します。

「セキュリティのため」と思って設定したステルスSSIDが、実はバッテリー寿命も縮めているのです。

バッテリー消費が増えるのは事実だけどそんなもん微々たるもんやろっていうツッコミは勘弁してください。その通りです

3. Evil Twin攻撃への脆弱性

Probe Requestの問題は、Evil Twin攻撃（偽アクセスポイント攻撃）のリスクを高めます。

攻撃の流れ

  1. 攻撃者は公共の場所でProbe Requestを傍受
  2. 「Corp-Wi-Fi を探している端末がいるな」と把握
  3. 「Corp-Wi-Fi」という名前の偽APを立ち上げる
  4. 端末は本物と偽物を区別できず、偽APに自動接続
  5. 攻撃者は通信を傍受（中間者攻撃）し、認証情報などを窃取

実際に使われる攻撃ツール

Evil Twin攻撃は理論上の脅威ではなく、誰でも入手可能なツールで簡単に実行できます。
セキュリティ専門家がペネトレーションテストで使用するツールですが、攻撃者も同じものを使用します。

代表的なツール

ツール名 概要 特徴
Wi-Fi Pineapple Hak5社製のペンテスト用デバイス ハードウェア一体型。
GUIで操作可能。
$100〜$400程度
aircrack-ng 無線LANセキュリティ監査ツールスイート OSSで無料。
Kali Linuxに標準搭載
hostapd-wpe 偽AP構築ツール RADIUS認証の傍受に特化
Fluxion Evil Twin攻撃自動化ツール キャプティブポータルでパスワード窃取

KARMA攻撃

特に危険なのがKARMA攻撃です。
これはWi-Fi Pineappleなどに実装されている攻撃手法で、以下のように動作します

  1. 攻撃者のデバイスが周囲のProbe Requestを傍受
  2. あらゆるSSIDに対して「はい、私がそのネットワークです」と応答
  3. 端末は正規のAPだと思い込んで接続
  4. 攻撃者は通信を傍受

ステルスSSIDを使用している端末は、常にProbe Requestを発信しているため、KARMA攻撃の格好のターゲットとなります。

4. 複数のステルスSSIDでリスクが倍増

複数拠点でそれぞれ異なるステルスSSIDを使用している場合、端末はすべてのSSIDについてProbe Requestを発信し続けます。

登録するステルスSSIDが増えるほど、攻撃者に提供する情報が増え、Evil Twin攻撃の対象となるSSIDも増えます。

OS別のProbe Requestの挙動

OS MACランダム化 自動接続 注意点
Windows 10/11 既定値は環境依存 可 組織ではMDM等で統制が必要
macOS 13+ デフォルト有効 可 Ventura以降で追跡防止強化
iOS 14+ デフォルト有効 不安定 iOS 16以降で自動接続のバグ報告多数
Android 10+ デフォルト有効 可 メーカーにより挙動が異なる（PETS 2021）

特にiOSでは、ステルスSSIDへの自動接続が動作せず毎回手動接続が必要になるケースが報告されています。Appleは公式にステルスSSIDの使用を推奨していません。

私自身、あるAPがステルスSSIDのため、毎回手動で繋がなければならず憤慨しております

MACアドレスランダム化との関係

近年のOS（iOS 14+、Android 10+、Windows 10+）には、MACアドレスランダム化（プライベートアドレス）機能が搭載されています。
これはProbe Requestの問題とどう関係するのでしょうか？

MACアドレスランダム化とは

Wi-Fi接続時に、端末の本来のMACアドレス（ハードウェア固有のID）ではなく、ランダムに生成したMACアドレスを使用する機能です。

目的 効果
トラッキング防止 店舗や公共Wi-Fiでの行動追跡を困難にする
プライバシー保護 端末の一意識別を防ぐ

一方、ネットワーク管理者にとっては悩ましい側面もあります。

  • DHCPリースが肥大化する（同一端末が複数エントリとして記録される）
  • デバイスの特定・棚卸しが困難になる
  • MACアドレスベースのアクセス制御が機能しない

これらの課題は802.1X認証で解決できます（詳細は「正しい対策」セクションで解説）。

ステルスSSIDの問題は解決しない

MACアドレスランダム化は、端末の識別を困難にしますが、Probe RequestにSSID名が含まれる問題は解決しません。

攻撃者は個々の端末を追跡できなくても、「Corp-Wi-Fiを探している端末がいる」という情報は取得でき、Evil Twin攻撃は依然として可能です。

正しい対策

では、無線LANのセキュリティを本当に高めるにはどうすればよいのか

即効性のある対策

  1. ステルスSSIDを廃止し、SSIDを公開する
    逆説的ですが、SSIDを公開することで

    • 端末がProbe Requestを発信しなくなる
    • Evil Twin攻撃のリスクが軽減される
    • iPhoneでの接続性が改善される

  2. 全拠点でSSIDを統一する
    複数拠点で同一のSSIDを使用することで

    • 端末に登録するSSIDが1つで済む
    • Probe Requestの発信も1つに削減
    • 管理の簡素化

  3. 強力なパスフレーズを設定する

    • 16文字以上のランダムな文字列を推奨
    • 辞書攻撃に耐性のある、推測不可能なものを使用

認証方式の選択（松・竹・梅）

レベル 方式 特徴 適した環境
梅 WPA2-AES (PSK) 最低限の暗号化。辞書攻撃に弱い
脆弱性が報告されているため最新のファームウェアの利用が前提		 既存環境の延命
竹 WPA3-Personal (SAE) 辞書攻撃耐性向上。導入コスト低 SOHO
松 WPA3-Enterprise (802.1X) ユーザー単位認証。最高のセキュリティ 中〜大規模組織

竹+α: PPSK/DPSK（端末ごとPSK）

802.1Xが難しいが、共有PSKの限界を補いたい場合の選択肢です。

方式 概要 対応製品例
PPSK (Private PSK) 端末ごとに異なるPSKを発行 Aruba, Ruckus等
DPSK (Dynamic PSK) ユーザーごとに動的にPSKを生成 Cisco Meraki等
  • 退職者対応: 該当PSKのみ無効化可能（全端末の再設定不要）
  • トレーサビリティ: どのPSKで接続したかログで追跡可能
  • 制約: ベンダー依存、対応機器が必要

松: WPA3-Enterprise (802.1X)

共通パスワード（PSK）方式の根本的な限界は、「誰が接続したか」を特定できないことです。

WPA3-Enterpriseでは

  • ユーザーごとに個別の認証情報を使用（IEEE 802.1X認証）
  • 接続ログから「誰が」「いつ」接続したかを追跡可能
  • 退職者のアクセス権を即時無効化可能

WPA3-Enterpriseの導入ハードル

「Enterpriseは大企業向けで、導入が難しい」というイメージがありますが、実際には小規模オフィスでも導入可能な選択肢が増えています。

単一拠点の場合：シンプルな選択肢

複数拠点という制約がなければ、導入のハードルは大幅に下がります。

選択肢 概要 適した規模 初期コスト
NAS内蔵RADIUS Synology / QNAP等のNASにRADIUS機能が内蔵 〜50名 NAS購入費のみ
ルーター内蔵RADIUS 一部の業務用ルーターにRADIUS機能が内蔵 〜30名 ルーター購入費のみ
マネージドRADIUS JumpCloud、Foxpass、SecureW2等のSaaS 〜数百名 月額数千円〜
アプライアンス製品 PacketFence、ClearPass等の専用製品 中〜大規模 数十万円〜

Synology NAS の例:
すでにSynologyのNASを使用している場合、「RADIUS Server」パッケージをインストールするだけで、追加コストなしにWPA3-Enterpriseを導入できます。

マネージドRADIUS（Cloud RADIUS）の例:
JumpCloudやFoxpassなどのサービスでは、RADIUSサーバーの構築・運用をすべてベンダーに任せられます。
Google WorkspaceやMicrosoft Entra ID（旧Azure AD）との連携も容易です。

複数拠点の場合：設計が必要

複数拠点がある場合は、認証サーバーの配置やネットワーク設計を検討する必要があります。
次回の記事では、クラウド上にRADIUSサーバーを構築し、複数拠点を一元管理する方法を解説します。

SSID統一の設計指針

複数拠点でSSIDを統一する際の設計ポイントです。

方針 説明
SSIDは1つに統一 拠点ごとに異なるSSIDを使わない。
SSID名に組織名を入れない Corp-WiFi、Acme-Office のような命名は避ける。
攻撃者に組織情報を提供してしまう
認証で差を付ける 802.1X認証を使用し、ユーザー/デバイス単位でポリシーを適用
PSKの場合は部門別SSIDにしない 部門ごとにSSIDを分けると、Probe Requestが増える。
VLANやアクセス制御で分離する
ローミング設計 同一SSIDで全拠点をカバーし、シームレスなローミングを実現

まとめ

項目 ステルスSSID SSIDブロードキャスト
SSIDの秘匿性 ほぼ効果なし（容易に発見可能） -
Probe Request 端末が常時発信（情報漏洩） 発信しない
Evil Twin攻撃 リスク増大 リスク軽減
バッテリー消費 増加（アクティブスキャン） 低い（パッシブスキャン）
iPhoneの接続性 手動接続が必要 自動接続可能

ステルスSSIDは「セキュリティ・シアター」（見せかけのセキュリティ）の典型例です。
実効性のある対策に切り替えましょう。

参考資料

IEEE 規格

IETF RFC

  • RFC 3748 - Extensible Authentication Protocol (EAP)
  • RFC 4017 - EAP Method Requirements for Wireless LANs

ベンダー公式ドキュメント

研究論文

ガイドライン・その他

脚注

  1. Wi-Fiには「隠れ端末問題（Hidden Node Problem）」という別の用語がありますが、これは通信品質に関する問題であり、本記事で扱う「Hidden SSID」（SSID通知の設定）とは無関係です。 ↩︎

  2. 電波法第59条は「特定の相手方に対して行われる無線通信」の傍受後の漏洩・窃用を禁止しています。
    ブロードキャストされる管理フレーム（Beacon等）の受信自体は、この規定の対象外と解釈されています。 ↩︎

株式会社Digeon
株式会社DigeonPublication

Digeonは神戸大学発のAIベンチャーです。 「息をするようにAIを使える社会をつくる」をミッションに、生成AI・LLM・業務自動化などの社会実装知見を発信します。

Discussion

AyrtonAyrton

はじめに：少し質問させてください

記事を拝読した中で疑問があり、少し質問をさせてください。

前提として

質問者のスキルレベル

申し訳ないのですが、運用経験や多少のNW知識を有しているレベルですので、
考慮漏れや検討不足がありましたらご指摘願います。

ステルスSSID擁護派ではありません

ステルスSSIDは「玄関の表札を外しただけ」のようなもの
社内SSID名の漏洩それ自体が情報資産

との記載の通り、可能な限り情報の暴露は避けたい
趣旨からステルスSSIDが適用されている、と考えております。

最近では表札のない家庭も多いですが、
それによってセキュリティリスクが大幅に減る訳ではなく、郵便や宅配の誤配を伴う危険性
もあるように、実用性と背反している部分も多少似ているかもしれません。

疑問点

リスク要因の二軸化

記事は、社外環境におけるPC端末の問題点として検証されているものの、
企業拠点周辺におけるリスク要因と合わせて検証する事が、実務的に相応しいように感じました。

自社ビルなら別ですが、フロアのみ専用の場合やフロアに数社混在の場合は
ステルスSSIDをやめると、近接エリアで企業SSIDが常に暴露されている状態となる認識です。

公衆エリアでSSIDが漏れるか、企業拠点周辺でSSIDの暴露リスクを許容するか
という二択ではないかと認識しております。

運用面からの検討

社外でPC端末を使用する人の多くは、メールやチャットとの連携のニーズもあり
AD連携するためにも自前のWiFiからネットワーク接続している事が多い想定です。

また、社外PCの運用ルールとして、信頼できるネットワーク外においては
機内モードを義務付ける事で、常に「Probe Request」を発信することは回避出来るので
運用面も含めた検討があっても良いのでは、と思った次第です。

総括

企業拠点周辺において、電波の弱いエリアで正規APを装った攻撃者に対するリスク
としても、SSID公開／非公開で攻撃成立条件は変わらない想定です。

対策の主軸である認証・端末検証・電波設計と共に設計されるべきと考えますので、
「百害あって一利なし」というよりも「定量的検証が不足した通説」
というようなトーンが実務的に合っているように思われ、不躾ですが質問させていただきました。

結友結友

丁寧なコメントをいただきありがとうございます。

ステルスSSIDをやめると、近接エリアで企業SSIDが常に暴露されている状態となる

ステルスSSIDの有無に関係なく、正規端末の接続・ローミング時にSSIDは観測されます。
そもそもSSIDは隠す必要がない情報であり、隠そうとすること自体が設計として誤りだと考えています。
それでも「見えないほうがいい」という感覚があるのであれば、記事の後半にも書いたように、企業名やAPの機種が特定できるような命名（初期値のSSIDを含む）を避けることのほうが有効です。

機内モード運用について

「運用でカバー」というやり方は、私は嫌いです。
エンドユーザーにセキュリティを担保させるのは、それはセキュリティではなく脆弱性です。
運用コストを現場に丸投げすることは不正の正当化にもつながりかねないため、「そうしなくても安全」な仕組みを技術的に作るべきだと考えています。

Evil Twin攻撃について

正直なところ完璧を目指すと青天井でリソース的な限界があります。
ステルスSSIDを無効化することで、攻撃の「きっかけ」を減らすことができます（そもそもステルスSSID自体が不要なので、正確には「増やしたリスクを0に戻す」ですが）。
その上で、記事内でも触れているように、認証・端末検証・電波設計・監視・教育などを積み重ねて現実解を作っていくのが良いと考えています。

タイトルについて

キャッチーさを優先してつけたので、ご指摘はごもっともです。
ただ正直に言うと、この記事自体が「ステルスSSIDが嫌い」という不純な動機に基づいています。
ジェレミー・クラークソンの言葉を借りるなら、
「おお、セキュリティの啓発記事だ。『ステルスSSIDが嫌い』と書くだけでこの厚み？」
となるわけです。

貴重なフィードバックをいただきありがとうございます。こうした議論も大変励みになります。

k4444k4444

大変参考になりました。
業務としてネットワークを主に見ているのですが、以前よりステルスSSID排除を考えていたのでこの記事を参考に周囲にも認知させていきたいです。

メーカーによっては6GHz帯を利用する場合ステルスSSIDの使用はできません。みたいな設定を見ることもあるので、そういう点でもステルスSSIDはもうレガシーな機能なのかなと思っています。

AyrtonAyrton

結友さん、ご返信有難うございました。

運用面と一体になった設計を、いつも念頭においているのですが
確かに、利用者に委ねる部分は「運用でカバー」となってしまいますね。

ログイン時のスクリプトか、端末管理ソフト等で自動制御出来なければリスク面で穴となるので、
SSIDを分かりにくくした上で公開するのが肝要だと思いました。