自分が運用するWebサイトを「外から見たときにどう見えるか」を確認するのに、Wiresharkは非常に役立ちます。本記事ではサイト全体のセキュリティチェックポイントと、特に重要なログイン経路の解析手順を、WordPressを例にまとめます。
※ 本記事の手法は「自分が所有・管理するサイト・アカウント」に対してのみ適用してください。
1. Wiresharkで分かること・分からないこと
分かること：通信の暗号化状態、TLS設定、平文で漏れている情報、不要な通信、Cookieやヘッダの内容、特定エンドポイントの振る舞い。
分からないこと：サーバ内部の脚弱性（SQLインジェクション等）、コード品質、ファイル権限。これらはOWASP ZAP、Nikto、wpscanなどと併用します。Wiresharkは「通信路の検査」に特化したツールと考えると位置づけが明確です。
2. 事前準備
HTTPS復号を可能にする
実用上、HTTPSの中身を見れないとセキュリティ診断はできません。ブラウザの環境変数 SSLKEYLOGFILE にログ出力先ファイルを指定し、Wireshark側でEdit / Preferences / Protocols / TLS の「(Pre)-Master-Secret log filename」にそのファイルを指定すると、キャプチャ済みパケットが自動的に復号されます。Chrome 、Firefox 、Edge が対応しています。
キャプチャしたいシナリオを決めておく
シナリオを事前に準備しておくと、後からパケットを追いやすくなります。代表的な流れは、未ログイン状態でログインページを開く、認証情報を送信してログイン、管理画面で何か操作（例：投稿保存）、ログアウト、ログアウト後に再び管理ページへのURLを叩く、という一連です。各操作の間に少し間をあけると、タイムスタンプで区切りを見つけやすくなります。
フィルタでノイズを減らす
表示フィルタで、自サイトのIPもしくはログイン関連のURI（wp-login や wp-admin 、wp-json）に限定します。TLSハンドシェイクも見たいときは tls フィルタも併用します。
3. サイト全体のセキュリティチェックポイント
HTTPS強制は機能しているか
平文HTTPで初回アクセスしたときに、即座に301もしくは302でHTTPSにリダイレクトされるか、リダイレクト後にHSTSヘッダ（Strict-Transport-Security）が返されるか、を確認します。リダイレクト前のHTTP応答でCookieを発行していたら要注意です（平文で発行されたCookieは盗聴できるため）。
TLS設定の健全性
ClientHelloとServerHelloの詳細を展開して、以下を確認します。
TLSバージョンが1.2以上であること、選択された暗号スイートがAES-GCM やChaCha20などAEAD系であること、古いRC4 や 3DES が残っていないこと、証明書チェーンが完全であり、有効期限とSANにドメインが含まれていること。証明書の詳細はCertificateハンドシェイクメッセージで見られます。
機微情報の漏えい
復号後のHTTP応答ヘッダで、Server ヘッダにサーバ製品名とバージョンが露出していないか、X-Powered-By ヘッダでPHPバージョンが見えていないか、エラーページにスタックトレースやファイルパスが出ていないかを見ます。WordPressでは、wp-json の応答にユーザー名一覧が含まれていないかも重要なチェックポイントです。
セキュリティヘッダ
以下のヘッダが応答に含まれているかを確認します。
Strict-Transport-Security（HTTPS強制）、Content-Security-Policy（XSS対策）、X-Content-Type-Optionsでnosniff（MIMEスニッフィング防止）、X-Frame-OptionsもしくはCSPのframe-ancestors（クリックジャッキング防止）、Referrer-Policy（リファラ漏えい制御）。
Cookie属性
Set-Cookieヘッダを抽出して、Secure（HTTPSでのみ送信）、HttpOnly（JSから読めない）、SameSite（CSRF対策）が付与されているかを確認します。WordPressのセッションCookie（名前がwordpress_logged_in_で始まるものなど）にはこれらが必須です。
不要な外部通信
StatisticsのEndpointsで通信先IP一覧を見て、自サイトへのアクセスで不審な第三者ドメインへのリクエストが発生していないか、想定外のCDNや解析サービス、古いプラグイン由来の外部API呼び出しがないかを見ます。侵害された場合の兆候を見つける手かかりになります。
4. ログイン経路の詳細解析
サイトのセキュリティで最も重要なポイントがログイン経路です。ステップごとに見るべきポイントを整理します。
ステップ一：ログインページの取得
HTTPSで配信されていること、リダイレクト後にHSTSヘッダがついていること、リダイレクト前のHTTP応答でCookieを発行していないことを確認します。さらにHTMLレスポンスの中身をFollowで見て、不要なコメントやデバッグ情報、内部パス、バージョン番号が漏れていないかをチェックします。
ステップ二：認証情報の送信（最重要）
ログインボタンを押したときのPOSTリクエストを選び、Followでリクエストとレスポンス全体を確認します。チェック項目は大きく以下の通りです。
通信路の暗号化：POSTがHTTPS（443番ポート）で送られていること。フォームのaction属性が平文HTTPを指していたり、異なるドメインに送られていたりしないこと。
リクエストヘッダ：OriginとRefererが同一オリジンを指していること、Cookieが正しく送られていること（CSRF対策の前提）。
POSTボディの内容：redirect_to パラメータの値が外部ドメインを指していたらオープンリダイレクト脚弱性の可能性。不要なパラメータが送られていないかも見ます。パスワードが平文でボディに入っているのはHTTPS下では正常です（通信路は暗号化されているため）。
認証応答：成功時に302で管理画面へリダイレクトされ、Set-CookieでセッションCookie（wordpress_logged_in_で始まる名前など）が発行され、これに必ずSecure 、HttpOnly 、SameSite が付与されていること。失敗時のエラー文言が「ユーザー名が違います」と「パスワードが違います」で区別されていると、ユーザー名の存在を列挙されてしまうため、「認証情報が違います」と統一した表現にするのが望ましいです。
ステップ三：ログイン後の管理画面アクセス
管理画面で読み込まれる全リソース（CSS 、JS 、画像）がHTTPSであることを確認します。混在コンテンツがあるとセッションリスクになります。またWordPressの状態変更操作（投稿保存など）では _wpnonce パラメータが付与されていること（CSRF対策）、ブロックエディタからのREST APIリクエストに X-WP-Nonce ヘッダが付与されていることを確認します。
ステップ四：ブルートフォース耐性の確認
自サイトに対してわざと誤ったパスワードで複数回ログイン試行してみます。何回失敗するとロックアウトされるか（理想は五から十回程度）、ロックアウト時にHTTP 429が返るか、Retry-After ヘッダがあるか、IP単位かアカウント単位か、を見ます。WordPressデフォルトでは制限がないため、Limit Login Attempts Reloaded や Wordfence などのプラグインで制限する必要があり、その動作をWiresharkで検証できます。
ステップ五：セッション管理の検証
「ログインを保持する」をチェックした場合としない場合でCookieのMax-AgeやExpiresを比較します。ログアウト時の応答でSet-Cookieに過去日付のexpiresが設定され、すべての認証関連Cookieが削除されていること、ログイン前後でテスト用Cookie（wordpress_test_cookie など）が再生成されていること（セッション固定攻撃対策）、を確認します。ログアウト後に古いCookieを使ってリプレイした場合にサーバが拒否するかも重要なチェックポイントです。
ステップ六：典型的な脚弱性パターンの観察
ユーザー名列挙：クエリで ?author=1 をつけてアクセスしたときに著者ページへリダイレクトされ、URLにユーザーのslugが露出していないか、wp-json のusers エンドポイントが未認証でユーザー一覧を返していないかを見ます。WordPressはデフォルトで露出するため、要対策です。
xmlrpc：xmlrpc.phpにPOSTで認証試行が可能なところです。使っていなければ無効化を推奨します。
CAPTCHA と 二要素認証：CAPTCHA画像やトークンが毎回新規生成されているか、二要素認証コード送信が別経路（メール 、SMS 、TOTP）で行われているか、コード総当たり制限が機能しているかを見ます。
5. 実例：ログイン検査シナリオ
以下はひととおりのログイン検査シナリオです。
- Wiresharkでキャプチャを開始
- シークレットウィンドウでログインページを開く
- わざと存在しないユーザーでログインしてエラー文言を確認
- わざと間違ったパスワードで三回ログインし、レート制限の有無を確認
- 正しい認証情報でログイン
- 管理画面で投稿を一つ編集して保存し、nonce付与を確認
- ログアウト
- ブラウザバックで管理画面へアクセスし、ログイン画面に戻されるかを確認
これだけで、全リクエストのHTTPS化、セッションCookieの属性、POST応答のSet-Cookie 、エラー文言のユーザー名漏えいの有無、状態変更操作へのnonce付与、ログアウト後のCookie無効化、という主要項目を一通りチェックできます。
6. 発見したら対策すべき具体例
CookieにSecureが欠如していたら、wp-config.phpでforce_ssl_adminを有効化します。HttpOnlyが欠如していたら、デフォルトで付与されるはずなのでプラグインの干渉を疑います。ユーザー名列挙が可能なら、プラグインで ?author= クエリをブロックし、REST APIのusersエンドポイントを制限します。ブルートフォースが無制限なら、Limit Login Attempts Reloaded や Wordfence を導入します。xmlrpc.phpが露出していて使っていないなら、.htaccess でブロックします。HSTSがないなら、サーバ設定でStrict-Transport-Securityヘッダを追加します。
7. Wiresharkで見つけにくいものと併用ツール
Wiresharkは「通信路の検査」が得意ですが、以下は別ツールが向いています。既知脚弱性の網羅にはOWASP ZAP や Nikto 、WordPress特有の脚弱性にはwpscan 、TLS設定の総合評価にはtestssl.sh や SSL Labs 、セキュリティヘッダ評価にはsecurityheaders.com、といった併用が効果的です。
8. 倫理的な注意
- 必ず自分が所有・管理するサイトとアカウントにだけ実施する
- 共用ホスティングでは、ポートスキャン等は事業者の規約を確認する
- ブルートフォーステストは自分のIPからのみ、他ユーザーに影響しない時間帯で実施
- パケットキャプチャには認証情報が含まれるため、保存したpcapファイルは暗号化保管し適切に削除する
まとめ
Wiresharkは「自サイトが外部からどう見えているか」を肉眼で見せてくれるツールです。特にログイン経路はサイトセキュリティの要であり、HTTPS徹底、Cookie属性、エラーメッセージの慎重さ、nonce付与、レート制限、セッション無効化の六点をすべてクリアしているかを一度検査してみる価値があります。見つかった課題はプラグイン設定やサーバ設定の調整で一つずつつぶしていけば、それだけでサイトの防御力は大きく上がります。
コメント