「PACファイルって聞いたことはあるけど、どう書けばいいのか分からない」「設定したのに反映されない…」そんな悩みを抱えていませんか？
PACファイルはプロキシ制御だけでなく、C&Cサーバへの通信を遮断するセキュリティ対策としても注目されています。
本記事では、PACファイルの基礎から応用、よくあるトラブルとその解決策までを、初心者にもわかりやすく解説します。
この記事は以下のような人におすすめ！
- そもそもPACファイルとは何か知りたい人
- PACファイルの書き方や構文がわからず、正しく動作しているか不安な人
- C&Cサーバへの不正な通信をPACファイルで遮断できるか知りたい
PACファイルとは
PACファイル（Proxy Auto-Configファイル）は、インターネット通信の経路を自動的に制御するための設定ファイルです。
主に、社内ネットワークや企業のセキュリティ対策として活用されており、特定の通信だけをプロキシサーバ経由にしたり、直接通信に切り替えたりすることができます。
特に、マルウェアが外部の「C&Cサーバ（コマンド＆コントロールサーバ）」へ通信しようとする場合など、特定のドメインやIPアドレスに対してプロキシの設定を変えることで、通信を遮断する対策にも応用できます。
つまり、PACファイルは単なる便利なツールにとどまらず、セキュリティ対策の重要な一手段としても活用されています。
1-1. PACファイルの概要と役割
PACファイルとは、クライアントのWebブラウザがどのプロキシサーバを経由して通信すべきかを、JavaScript形式で動的に判断するための設定ファイルです。拡張子は .pac で、内部には FindProxyForURL(url, host) という関数が定義されます。
この関数が返す内容によって、以下のように通信経路が決定されます：
| 戻り値 | 意味 |
|---|---|
| DIRECT | プロキシを通さず直接通信 |
| PROXY | 指定したプロキシサーバを使用 |
| SOCKS | SOCKSプロキシを利用（高度な設定） |
1-1-1. 役割のポイント：
- 動的に通信ルートを制御できる
たとえば、社内ドメインはプロキシを通さず、外部通信だけプロキシ経由にするなどが可能です。 - セキュリティ対策に有効
不正アクセスやマルウェアによる通信を制限し、C&Cサーバへの接続を防ぐ設定も可能です。 - 柔軟な環境対応
利用者のネットワーク環境（社内・自宅・VPN）に応じて、自動的に通信経路を切り替えられます。
このように、PACファイルは柔軟性と実用性を兼ね備えており、特に企業ネットワークでは欠かせない存在となっています。
1-2. PACファイルを使うメリットと導入用途
PACファイルを導入することで得られるメリットは多岐にわたります。以下に、代表的な利点をわかりやすく整理してみましょう。
1-2-1. PACファイルの主なメリット：
- 運用コストの削減
手動でのプロキシ設定を不要にし、大規模環境でも一括で管理可能です。 - 通信経路の自動切替
ローカルとインターネットを自動判別し、適切な経路を選択します。 - セキュリティ強化
不正な通信やC&Cサーバとの接続をブロックする設定が可能になります。 - ユーザーの利便性向上
ネットワーク環境に依存せず、利用者が意識せずに安全な通信経路を使えるようになります。
1-2-2. PACファイルの活用シーン：
| 活用ケース | 詳細内容 |
|---|---|
| 社内ネットワークのみプロキシ使用 | 社外アクセスは直接通信、社内はプロキシ経由でログ取得・監視を行う |
| テレワーク環境での切替 | VPN接続中はプロキシ使用、VPN未接続時は直接通信を許可 |
| マルウェア通信の制御 | C&CサーバのドメインやIPにフィルタリングをかけ、感染拡大を防ぐ |
したがって、PACファイルは単なる利便性のためだけでなく、情報漏洩やサイバー攻撃に対する防御線としても有効です。
PACファイルの基本構造と書き方
PACファイルはJavaScript形式で記述されるため、ある程度プログラミングに馴染みのない方には少し難しく感じるかもしれません。
しかし基本的な構造を理解してしまえば、非常にシンプルで柔軟な設定が可能です。
特に、企業ネットワークやセキュリティ意識の高い環境では、C&Cサーバ（コマンド＆コントロールサーバ）への通信をブロックする用途としてもPACファイルが活用されています。
つまり、ネットワーク上での不要または危険な通信を防ぐ「動的なルールブック」としての役割を果たすのです。
以下では、PACファイルの中核を担う FindProxyForURL 関数と、利用可能な戻り値について詳しく解説します。
2-1. FindProxyForURL関数の基本文法と引数説明
PACファイルの中心にあるのが FindProxyForURL(url, host) という関数です。
この関数は、アクセスしようとしているURLとそのホスト名を引数として受け取り、それに応じたプロキシの設定方法を返します。
2-1-1. 基本構文の例：
function FindProxyForURL(url, host) {
if (shExpMatch(host, “*.example.com”)) {
return “PROXY proxy.example.com:8080”;
}
return “DIRECT”;
}
2-1-2. 各要素の意味：
| 要素 | 説明 |
|---|---|
url | アクセス先の完全なURL（例: https://malware-site.com） |
host | URLから抽出されたホスト名（例: malware-site.com） |
shExpMatch | ホスト名のパターンマッチ（ワイルドカードも可能） |
return | 通信方法（プロキシ経由／直接通信など）を返す |
この構文により、特定のドメインやIPに対してのみプロキシを経由させたり、C&Cサーバのような危険な通信先を迂回・遮断したりといった制御が可能になります。
たとえば、以下のような記述は、C&Cサーバと思しきドメインを遮断する例です。
if (dnsDomainIs(host, “malicious-cnc.com”)) {
return “PROXY 127.0.0.1:9”; // 通信不能なプロキシを指定してブロック
}
このように、FindProxyForURL関数はPACファイルの“頭脳”であり、セキュリティポリシーに応じて柔軟な対応が可能です。
2-2. 利用可能な戻り値（DIRECT／PROXY／SOCKS など）
FindProxyForURL関数は、アクセス先に応じて通信経路を返します。返せる値は複数あり、それぞれ異なる意味を持ちます。
2-2-1. 戻り値の一覧とその役割：
| 戻り値 | 説明 |
|---|---|
DIRECT | プロキシを使用せずに直接通信を行う |
PROXY | 指定したプロキシサーバ経由で通信（例：PROXY proxy.example.com:8080） |
SOCKS | SOCKSプロキシ経由で通信（例：SOCKS socks.example.com:1080） |
| 複数指定（カンマ） | 複数のプロキシを順に試す（例：PROXY proxy1:8080; PROXY proxy2:8080; DIRECT） |
2-2-2. 使用例：
return “PROXY proxy1.company.local:8080; DIRECT”;
この例では、まず指定したプロキシが利用できるかを試し、利用できない場合は直接通信を行います。
2-2-3. C&Cサーバ対策の実用例：
if (dnsDomainIs(host, “cnc-botnet.org”)) {
return “PROXY 127.0.0.1:9”; // 実質的にブロック
}
return “DIRECT”;
このように、戻り値を巧みに使うことで、マルウェアがC&Cサーバと通信しようとするのを未然に防ぐことが可能になります。
末が外部のC&Cサーバと接続して情報を送信するケースが増えています。PACファイルを正しく設定することで、そうした不正通信を事前に遮断する防壁となるのです。
PACファイルの記述例
PACファイルの魅力は、JavaScriptベースで記述するため非常に柔軟に動作を制御できる点にあります。特定のドメインやIPアドレス、さらには時間帯や接続環境に応じてプロキシを使い分けることが可能です。
特に、マルウェアによるC&Cサーバ（コマンド＆コントロールサーバ）との通信を検知・遮断する目的でPACファイルを設定するケースが増えており、その実用性は年々高まっています。
ここでは、PACファイルの具体的な記述例を、基本的なものから応用的なものまで段階的に紹介します。
3-1. 基本的なドメインやIPの振り分け
まずは、PACファイルの基本とも言える「ドメイン別」や「IPアドレス別」にプロキシを振り分ける方法です。
3-1-1. 例1：特定のドメインだけプロキシ経由
function FindProxyForURL(url, host) {
if (dnsDomainIs(host, “.internal.example.com”)) {
return “PROXY proxy.internal.example.com:8080”;
}
return “DIRECT”;
}
この設定では、社内ドメイン「.internal.example.com」へのアクセスだけをプロキシ経由にし、それ以外は直接通信します。
3-1-2. 例2：C&Cサーバとされるドメインをブロック
function FindProxyForURL(url, host) {
if (shExpMatch(host, “*malicious-cnc.org”)) {
return “PROXY 127.0.0.1:9”; // 通信不能なプロキシで実質的に遮断
}
return “DIRECT”;
}
このように、C&Cサーバに指定されたドメインをリストアップし、無効なプロキシ（127.0.0.1:9）を返すことで、マルウェアの外部通信を封じることができます。
3-1-3. 例3：IPアドレスベースでプロキシ制御
if (isInNet(host, “192.168.0.0”, “255.255.255.0”)) {
return “PROXY proxy.local:8080”;
}
この例では、ローカルネットワーク（192.168.0.x）に属するホストにはプロキシを適用します。
3-2. 応用例：曜日・時間帯／複数プロキシ／ローカル環境対応
PACファイルでは、JavaScriptのロジックを利用することで高度な制御が可能です。以下に応用的な設定例を紹介します。
3-2-1. 例1：平日のみプロキシを使用
var day = (new Date()).getDay(); // 0=日曜, 1=月曜, …, 6=土曜
if (day >= 1 && day <= 5) {
return “PROXY proxy.weekday.example.com:8080”;
}
return “DIRECT”;
これは、平日（月〜金）だけプロキシを使用し、週末は直接通信とする例です。
3-2-2. 例2：時間帯によってプロキシを変更
var hour = (new Date()).getHours();
if (hour >= 9 && hour <= 18) {
return “PROXY proxy.daytime.example.com:8080”;
}
return “PROXY proxy.night.example.com:8080”;
上記のように、業務時間中とそれ以外でプロキシを切り替えることも可能です。
3-2-3. 例3：複数プロキシのフォールバック設定
return “PROXY proxy1.example.com:8080; PROXY proxy2.example.com:8080; DIRECT”;
この記述では、proxy1 が使用不可なら proxy2 を試し、それも無理なら DIRECT に切り替わります。可用性の高い構成を実現できます。
3-2-4. 例4：VPN接続時と非接続時で通信経路を切り替え
if (isInNet(myIpAddress(), “10.0.0.0”, “255.0.0.0”)) {
return “PROXY proxy.vpn.example.com:8080”;
}
return “DIRECT”;
この記述は、クライアントのIPが10.0.0.0/8に属している（VPN内）ならプロキシを使用し、それ以外は直接通信にする設定です。
テレワーク環境でよく利用される構成です。
PACファイルの配置方法と言語環境対応
PACファイルは、正しく動作させるために適切な場所に配置し、クライアント（主にWebブラウザ）からアクセスできるようにする必要があります。
また、同様の自動構成技術であるWPAD（Web Proxy Auto-Discovery Protocol）との違いを理解しておくことも重要です。
特にセキュリティ面においては、PACファイルの誤設定が原因でC&Cサーバ（コマンド＆コントロールサーバ）との通信を許可してしまうリスクもあります。したがって、配置方法や運用ルールを正しく理解することが、ネットワーク防御の第一歩となります。
4-1. 配置場所の選び方（HTTPサーバー vs ローカル）
PACファイルの配置先は大きく分けて2つあり、それぞれにメリットと注意点があります。
4-1-1. 方法1：HTTPサーバーに配置
PACファイルをHTTPサーバーに配置し、URLで指定する方法が最も一般的です。
例: http://proxy.example.com/proxy.pac
4-1-2. メリット：
- 複数端末への一括配布・更新が容易
- ネットワーク全体で統一されたポリシーを適用可能
- クラウド型セキュリティ製品との連携がしやすい
4-1-3. 注意点：
- サーバーの稼働率が重要（停止時にプロキシが効かなくなる）
- HTTPサーバーの設定ミスによる情報漏洩や改ざんリスクも存在
4-1-4. 方法2：ローカルファイルでの指定
ユーザーの端末にPACファイルを配置し、ファイルパスで指定する方法です。
例: file:///C:/proxy/proxy.pac
4-1-5. メリット：
- オフライン環境でも動作可能
- 単体テストや一時的な設定確認に便利
4-1-6. 注意点：
- 配布や更新が手動で非効率
- 利用者が内容を改変しやすく、C&Cサーバなどへの通信を許してしまう危険性がある
4-1-7. 配置方法の比較表：
| 配置方法 | 一括管理性 | セキュリティ | オフライン対応 | 更新のしやすさ |
|---|---|---|---|---|
| HTTPサーバー | 高 | 中〜高 | 低 | 高 |
| ローカルファイル | 低 | 低 | 高 | 低 |
従って、企業ネットワークなどでC&Cサーバ対策を徹底する場合には、HTTPサーバーへの配置を推奨します。
4-2. MIMEタイプやWPADとの違い
PACファイルをHTTPサーバーに配置する際は、正しいMIMEタイプの設定が非常に重要です。
これを誤ると、ブラウザがPACファイルとして認識せず、プロキシ設定が無効になります。
4-2-1. 正しいMIMEタイプ設定：
Content-Type: application/x-ns-proxy-autoconfig
4-2-2. なぜMIMEタイプが重要なのか？
PACファイルは単なるJavaScriptではなく、プロキシ設定用のスクリプトとして解釈される必要があります。
つまり、適切なMIMEタイプで配信しなければ、プロキシ動作自体が無効になるため、C&Cサーバへの通信もフィルタリングされないまま通過してしまう可能性があります。
4-2-3. WPADとの違い
WPAD（Web Proxy Auto-Discovery Protocol）は、PACファイルのURLを自動検出するための仕組みです。
これにより、ユーザーが明示的にPACファイルのURLを設定しなくても、自動的にプロキシ設定が適用されます。
| 項目 | PACファイル | WPAD |
|---|---|---|
| 設定方法 | URLまたはファイルパスで手動設定 | DHCPまたはDNSを使って自動検出 |
| カスタマイズ性 | 高（JavaScriptで柔軟に制御可能） | 低（自動検出機能は基本的に固定的） |
| セキュリティ | 中（管理次第で高セキュリティ運用可） | 低（攻撃者による悪意のあるPACの注入リスク） |
4-2-4. WPADの注意点：
WPADを無防備に使うと、ネットワーク内にいる攻撃者が偽のPACファイルを配信し、C&Cサーバへ誘導するというリスクが生じます。
したがって、WPADを使用する場合は厳重なネットワーク監視とDNS制御が必須です。
つまり、PACファイルの配置には信頼できるインフラと正しい設定が欠かせません。
適切に管理されたPACファイルは、C&Cサーバへの不正通信を事前に遮断する有効な武器になります。
逆に、不適切な設定は、ネットワークを脆弱にする原因にもなり得るのです。
動作確認とデバッグ方法
PACファイルは非常に柔軟な設定が可能な反面、構文ミスや条件分岐の誤りにより意図しない通信経路が選択されてしまうことがあります。
特に、C&Cサーバ（コマンド＆コントロールサーバ）への通信を遮断する目的で使用している場合には、設定ミスがセキュリティ上の大きなリスクとなります。
したがって、PACファイルを作成した後は必ず動作確認とデバッグを行うことが重要です。
この章では、一般的なWebブラウザでの確認方法と、専用ツール・コマンドラインによるテスト方法について解説します。
5-1. ブラウザでの確認手順（Chrome／Firefox／Edge）
5-1-1. Chromeの場合：
- 設定メニューを開く
「設定」→「システム」→「プロキシ設定を開く」をクリック - インターネットプロパティを開く
Windowsの場合、「インターネットのプロパティ」が開くので「LANの設定」を選択 - 自動構成スクリプトにPACのURLを入力
例：http://proxy.example.com/proxy.pac - ブラウザでテスト
C&Cサーバの疑似URL（例：http://malicious-cnc.org）にアクセスして、通信が遮断されるか確認します。
5-1-2. Firefoxの場合：
- 設定 → 一般 → ネットワーク設定 → 接続設定を開く
- 「自動プロキシ設定URLを使用する」にPACファイルのURLを入力
- 「OK」で保存し、対象URLにアクセスして挙動を確認
5-1-3. Edgeの場合：
EdgeもChromeと同様に、OSのプロキシ設定に準拠しています。Windowsの「インターネットオプション」でPACを指定すれば有効になります。
5-1-4. 確認ポイント：
- 意図したドメインだけプロキシ経由になっているか
- C&Cサーバと思しきドメインが無効プロキシで遮断されているか
- 意図しないドメインがプロキシ適用されていないか
5-2. 専用ツールやコマンドラインでのテスト方法
PACファイルの動作をより詳細に検証したい場合、ブラウザに依存せずテストできる専用ツールやコマンドラインの利用が便利です。
5-2-1. PacParser（PythonやLinuxで使用可能）
PacParserはPACファイルをプログラムから読み込み、関数を評価できるライブラリです。
LinuxやmacOSなどの検証に便利です。
pactester -p ./proxy.pac -u http://malicious-cnc.org -h malicious-cnc.org
出力例：
PROXY 127.0.0.1:9
→ 無効なプロキシが返されていれば、C&Cサーバ対策として機能していることを示します。
5-2-2. Node.js + PACモジュール
Node.js環境で「pac-resolver」などのモジュールを使えば、プログラムとしてPACファイルの動作を確認可能です。
const { createPacResolver } = require(‘pac-resolver’);
const fs = require(‘fs’);
const pacScript = fs.readFileSync(‘./proxy.pac’, ‘utf8’);
const FindProxyForURL = createPacResolver(pacScript);
FindProxyForURL(‘http://malicious-cnc.org’, ‘malicious-cnc.org’).then(console.log);
5-2-3. Fiddler や Charles Proxy（GUI型）
GUIでプロキシの動作やPACの挙動を可視化できるツールです。設定後、対象URLへのリクエストがどう扱われるかを視覚的に確認できます。
5-2-4. デバッグ時のポイント：
- JavaScriptの文法エラーを含んでいないか（特にセミコロン忘れや条件式の誤り）
return文が確実に実行されるよう、elseやreturnの順番に注意dnsDomainIs()やshExpMatch()の使い方が正しいか
このように、PACファイルの動作検証はブラウザとツールの両方で行うことがベストです。
なぜなら、C&Cサーバ対策としてPACファイルを導入する以上、万一の抜け穴が存在すれば、マルウェアの通信を許してしまう結果になりかねないからです。
その結果、検証作業を怠った場合、PACファイルが逆にセキュリティホールとなってしまう危険性すらあります。従って、運用前には必ず正確かつ多面的なテストを実施しましょう。
注意点とトラブル解決
PACファイルは非常に柔軟かつ強力なツールですが、同時に思わぬトラブルを引き起こす原因にもなります。
とくに、C&Cサーバ（コマンド＆コントロールサーバ）との通信をブロックするセキュリティ目的で使用している場合、設定ミスや挙動の誤解は致命的です。
この章では、PACファイル運用でよくある問題点とその対策、そしてセキュリティ面での注意事項について、実務視点で詳しく解説します。
6-1. よくある問題（キャッシュ、DNS、myIpAddressの不具合など）と対策
PACファイルはJavaScriptベースで動作するため、環境やブラウザ、ネットワークの状態によって不安定な挙動が発生することがあります。
ここでは代表的なトラブルと解決策を紹介します。
6-1-1. キャッシュが残って変更が反映されない
問題：
PACファイルを更新しても、ブラウザに以前の内容がキャッシュされてしまい、新しい設定が反映されないことがあります。
対策：
- PACファイルのURLにクエリパラメータ（例：
?ver=20250823）を付加して更新 - ブラウザを再起動、またはキャッシュクリアを実施
例: http://proxy.example.com/proxy.pac?ver=20250823
6-1-2. DNS関連の関数が正しく動作しない
問題：dnsDomainIs() や isInNet() などの関数がDNS解決エラーを起こすことがあります。特に不安定なネットワークでは、ホスト名の解決に失敗してC&Cサーバとの通信を許してしまう可能性があります。
対策：
- ホスト名ではなくIPベースのマッチングを併用する
- DNS障害を想定して、最終的なデフォルト戻り値を「安全側（PROXY）」に設定する
6-1-3. myIpAddress() が誤ったIPを返す
問題：
特にVPNや複数NIC環境では、myIpAddress() が意図しないローカルIP（または0.0.0.0）を返すことがあり、通信制御が想定外の動作になることがあります。
対策：
- 可能であれば
myIpAddress()の使用を避け、環境変数や複数の条件で代替 - 設定を必要最小限にし、挙動が確実な関数に絞る
6-2. セキュリティ上のリスクと安全な運用ポイント
PACファイルはプロキシ制御の自動化に優れていますが、その自由度の高さが裏目に出てセキュリティホールになることもあります。
6-2-1. 主なセキュリティリスク：
| リスク内容 | 説明 |
|---|---|
| C&Cサーバとの通信を誤って許可 | 記述ミスやテスト不足により、危険ドメインが除外されてしまうケース |
| PACファイルの改ざん | HTTPで配信している場合、**中間者攻撃（MITM）**により悪意ある内容に書き換えられる可能性 |
| WPAD悪用によるなりすまし | WPAD有効環境で攻撃者が偽PACファイルを配信し、全通信をC&Cサーバに転送 |
6-2-2. 安全に運用するためのポイント：
- HTTPSでPACファイルを配信し、改ざんを防止する
- 内容にデフォルトのセーフ設定（例：return “PROXY 127.0.0.1:9”;）を含める
- 定期的にPACファイルの挙動を自動検証するスクリプトやCIで監視
- 社内の信頼できるDNSのみでWPADを有効化し、社外では無効にする
6-2-3. 実装時のベストプラクティス（チェックリスト）：
- C&Cサーバのドメイン/IPが確実にマッチする条件で記述されているか？
- 不明なドメインへのアクセスはすべてDIRECTではなく、安全側へ？
- MIMEタイプは正しく設定されているか（application/x-ns-proxy-autoconfig）？
- PACファイルのURLはHTTPSで保護されているか？
