【実務・中級編】 Wi-FiにおけるPMF（Protected Management Frames: 802.11w）の構造と無効化攻撃防護 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは、シニアネットワークエンジニアの私だ。

現場で無線LANの設計や運用に携わっていると、「なぜか特定の端末だけ頻繁に切断される」「オフィスの一角で、接続が不安定になるだけでなく、怪しい挙動が観測される」といった、一筋縄ではいかないトラブルに直面することがある。電波干渉やチャンネルの混雑を疑い、サイトサーベイをやり直しても原因が掴めない……。そんなとき、疑うべきは「目に見えない空中の脅威」、すなわち悪意あるパケットによる攻撃だ。

今回は、Wi-Fiのセキュリティを語る上で避けて通れない、しかし意外と見落とされがちなPMF（Protected Management Frames: IEEE 802.11w）の核心に迫ろう。教科書的な仕様のなぞりではなく、実際のパケットが無線空間をどう飛び交い、どのように悪意をいなしているのか。現場の知見を交えて徹底的に解説する。

—

1. なぜ「切断攻撃」は成立してしまうのか？――Wi-Fi管理フレームの脆弱性

私たちが普段何気なく使っているWi-Fiは、WPA2やWPA3といった強力な暗号化によって、データの秘匿性を守っている。AES（CCMP）やGCMPを用いた暗号化のおかげで、空中に飛び交うパケットをスニッフィングされても、中身を簡単に読み解かれることはない。

しかし、ここで一つ致命的な矛盾がある。「接続を確立する前」や「切断を命じる」ための管理フレーム（Management Frames）は、歴史的経緯から長らく平文（暗号化なし）でやり取りされてきたという点だ。

デアソシエーション（Deauth）攻撃のメカニズム

無線LANの通信において、攻撃者は標的の端末（クライアント）とアクセスポイント（AP）の間に割り込む必要すらない。空中に向けて、次のようなフレームを偽装してばら撒くだけでいい。

1. Deauthentication（認証解除）フレーム: 「あなたとの接続を終了します」とAPに成りすましてクライアントに送りつける。
2. Disassociation（アソシエーション解除）フレーム: 「通信の紐付けを解除します」と告げる。

これを受信したクライアントは、「APから切断命令が来た」と誤認し、容赦なく接続を切断してしまう。悪意ある攻撃者がこれを利用すると、ターゲットを意図的にオフラインにし続けたり（サービス妨害: DoS）、再接続の瞬間にハンドシェイクを盗み見たりすることが可能になる。これが、いわゆるデアソシエーション攻撃（Deauth Attack）の正体だ。

—

2. PMF（IEEE 802.11w）による管理フレームの保護

この空中の無法地帯に秩序をもたらしたのが、2009年にIEEE 802.11wとして策定され、その後WPA2のオプション、そしてWPA3で完全義務化されたPMF（Protected Management Frames）だ。

PMFの本質はシンプルで力強い。「これまで丸見えだった管理フレームにも、データフレームと同様に暗号化と整合性チェック（MIC）を適用する」というアプローチである。

保護対象となるフレーム

すべての管理フレームが暗号化されるわけではない。ブロードキャストやマルチキャストで初期接続に使われるフレーム（BeaconやProbe Requestなど）は暗号化できないが、特定の端末間（ユニキャスト）でやり取りされる重要な管理アクションフレームはしっかりと保護される。

  • Deauthentication（認証解除）
  • Disassociation（アソシエーション解除）
  • Actionフレーム（ローム要求、QoS、スペクトラム管理など）

これらがPMFによって保護されると、仮に攻撃者が同じデアソシエーションパケットを空中に放り投げても、APやクライアントが持つセッション鍵から算出される正しいMIC（Message Integrity Code）が含まれていないため、受信側で「偽装パケット」として即座に破棄される。攻撃者は手出しができなくなるというわけだ。

—

3. 実際の通信フローとハンドシェイクの裏側

では、PMFが有効な環境では、接続と保護のネゴシエーションはどのように行われているのだろうか。シーケンスの裏側を覗いてみよう。

クライアント (STA)                         アクセスポイント (AP)
    |                                            |
    | ------- 1. Probe Request / Beacon -------> | （機能の広告）
    | <------ 2. Probe Response / Beacon ------- | * PMF機能ビットを提示 (Capable / Required)
    |                                            |
    | <----------- 3. Authentication ------------> | （認証）
    |                                            |
    | ------------ 4. Association ---------------> | （関連付け）
    |          * RSN情報要素(RSN IE)にて          |
    |            PMFの有効性を通知                 |
    |                                            |
    | <======== 5. 4-Way Handshake =============> | （暗号鍵の導出）
    |          * PTKに加え、IGTK (Integrity        |
    |            Group Temporal Key) も生成        |
    |                                            |
    | ~~~~~~~~~ 6. Protected Management ~~~~~~~~ | （暗号化された管理フレームのやり取り）
    |          * 万が一のDeauthもIGTKで検証・破棄  |

パラメーターの要件（Capable と Required）

無線LANのコンフィグレーションやプロファイルを見ていると、PMFの設定項目として以下の3択に直面するはずだ。

1. Disabled（無効）: PMFを使用しない。古いレガシー機器との互換性確保のために残されているが、セキュリティ上のリスクが大きい。
2. Capable（有効・対応）: PMFをサポートするが、必須ではない。非対応のクライアントが混在していても接続を受け入れる。
3. Required（必須）: PMFを強制する。対応していない古いクライアントは一切接続を拒否する（WPA3環境ではこれがデフォルトとなる）。

実務の現場では、セキュリティ監査の基準を満たすために既存のWPA2環境であってもPMFを Required もしくは Capable（移行期）に設定することが求められる。

—

4. 実務で役立つ設定とデバッグのTips

ここからは、実際にインフラを構築・運用するエンジニアに向けて、具体的な設定例とトラブルシューティングのノウハウを共有しよう。

オープンソースAP（Hostapd）での設定例

Linuxベースのアクセスポイントソフトウェアである hostapd を用いて、PMFを強制（Required）する設定ファイルの記述例だ。

# /etc/hostapd/hostapd.conf
interface=wlan0
driver=nl80211
ssid=Secure_Enterprise_Wi-Fi
hw_mode=g
channel=6

# WPA2/WPA3のハイブリッド、またはWPA3専用の設定
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK WPA-EAP
wpa_pairwise=CCMP

# --- ここからPMFの設定 ---
# ieee80211wの値: 0 = 無効(Disabled), 1 = 有効/任意(Capable), 2 = 必須(Required)
ieee80211w=2

# ビーコン保護（BIP: Broadcast/Multicast Integrity Protocol）を有効化する場合の設定
# ※一部の古いクライアントがドロップする原因になるため環境に応じて調整
group_mgmt_cipher=AES-128-CMAC

トラブルシューティング：PMF起因の接続不良を見抜く

「新しいセキュリティポリシーを適用したら、一部の社内端末や古いIoTゲートウェイがWi-Fiにつながらなくなった」――これはインフラエンジニアが最も冷や汗をかく瞬間だ。

原因の多くは、クライアント側のWi-FiドライバやファームウェアがPMF（IEEE 802.11w）に未対応であるにもかかわらず、AP側で ieee80211w=2 (Required) に設定してしまっているケースである。

デバッグの手順

1. クライアント側のログを確認する
Linux端末であれば、dmesg や journalctl で wpa_supplicant の挙動を追う。

# Linuxクライアントでのリアルタイムログ監視例
   journalctl -u wpa_supplicant -f

ログ内に Deauthentication や Association rejected because PMF is required but client does not support it といったエラーが出ていれば、原因は明白だ。

2. パケットキャプチャで空中線を覗き見する
エアモニタリングモード（Monitor Mode）に入れたWi-Fiアダプタと Wireshark を使い、アソシエーション要求（Association Request）のパケットを確認する。

  • RSN Capabilities フィールドを展開し、Management Frame Protection (MFP) のビットが立っているかを確認する。
  • クライアントが MFP Capable すら広告していない場合、その端末はPMFを理解できない。

実務の現場では、セキュリティ要件とデバイスのライフサイクルの板挟みになることが多い。どうしてもレガシーデバイスを収容しなければならない場合は、PMFを Capable に落とすか、当該端末専用の別SSID（レガシー用、かつMACアドレスフィルタリングや別セグメントでの隔離を徹底したもの）を切るという苦渋の決断が必要になる。

—

5. おわりに

Wi-Fiはケーブルが見えない分、パケットの挙動を想像する力がエンジニアリングの成否を分ける。PMF（802.11w）は、一見すると地味なプロトコルの拡張に見えるが、無線LANの信頼性を根底から支える極めて重要な盾だ。

WPA3の普及に伴い、PMFはもはや「オプションの機能」ではなく「あって当たり前のインフラの基礎体力」になりつつある。設計書にただ設定値を書き写すだけでなく、そのパケットが空中でどのような意味を持ち、どのような攻撃を防いでいるのかをイメージしながら、堅牢でセキュアなネットワークを構築していってほしい。

あなたの構築したネットワークが、今日もクリーンで安全なパケットで満たされていることを願っている。

スポンサーリンク

コメント

タイトルとURLをコピーしました