問題:誰でも接続してネットワークにアクセスできてしまう
数年前、ランサムウェアインシデントの調査支援のため、ある中規模企業に呼ばれたことがある。攻撃者はただ会議室に入り込み、開いているイーサネットポートにラップトップを接続しただけだった。そこから3日間、誰にも気づかれることなくネットワーク内を横断し続けた。ファイルサーバーが自己暗号化を始めるまで、誰もアラートすら受け取らなかった。
根本原因はあきれるほど単純だった。ネットワークエッジに何の制御も存在しなかったのだ。個人のラップトップ、不正なRaspberry Pi、業者のタブレット——あらゆるデバイスがどのポートにも接続でき、即座に内部リソースへアクセスできた。これは珍しいことではない。多くの企業ネットワークは今でも暗黙の信頼に基づいて運用されている。物理的に接続できるなら、それだけでアクセスが許可されるのだ。
ネットワークアクセス制御(NAC)は、ネットワーク自体がすべてのデバイスにアクセスを許可する前に審問を行うことで、この問題を解決する。あなたは誰ですか?ポリシーに準拠していますか?ここにいる権限がありますか? PacketFenceは主要なオープンソースNACプラットフォームだ。RADIUS、VLAN割り当て、キャプティブポータル強制を通じて、有線802.1Xと無線ネットワークの両方に対応している。
クイックスタート:PacketFenceを5分で動かす
PacketFenceを最速で評価するには、ZEN(Zero Effort NAC)仮想アプライアンスを使うのが一番だ。公式サイトからダウンロードし、VirtualBoxまたはVMwareにインポートするだけで、ポート1443にWebGUIが立ち上がった事前設定済み環境が起動する。手動セットアップは不要だ。
最小限のラボ構成
実際のデプロイテストには、最低限以下が必要だ:
- PacketFenceサーバー1台(Ubuntu 22.04またはRHEL 9、最低4 vCPU / 8 GB RAM)
- 802.1XとRADIUSをサポートするマネージドスイッチ1台(Cisco、HP Aruba、Juniperが対応)
- テスト用クライアントマシン1台(WindowsまたはLinux)
Ubuntu 22.04へのPacketFenceインストール:
# PacketFenceリポジトリを追加する
curl -sSL https://packagecloud.io/inverse-inc/PacketFence/gpgkey | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/packetfence.gpg
echo "deb https://packagecloud.io/inverse-inc/PacketFence/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/packetfence.list
sudo apt update
sudo apt install -y packetfence
# コンフィギュレーターを実行する
sudo /usr/local/pf/bin/pfcmd configurator run
コンフィギュレーターがインターフェースの割り当て、データベースのセットアップ、初期管理者資格情報の設定を順に案内してくれる。完了したら、https://<server-ip>:1443からGUIにアクセスできる。
詳細解説:PacketFenceがアクセスを制御する仕組み
RADIUSのフロー
デバイスが802.1X対応スイッチポートまたはWi-Fi SSIDに接続すると、正確には以下の手順が実行される:
- スイッチが接続デバイスにEAP-Request/Identityを送信する
- デバイスが資格情報(証明書、ユーザー名/パスワード、またはMACアドレス)で応答する
- スイッチがRADIUS Access-RequestをPacketFenceに転送する
- PacketFenceが内部データベース、Active Directory、またはLDAPを照合する
- PacketFenceがAccess-AcceptまたはAccess-Rejectを返答し、RADIUS属性経由でVLAN割り当てを通知する
- スイッチがそれに従い、ポートを正しいVLANに配置する
PacketFenceは内部でFreeRADIUSを使用しており、自動的に設定される。FreeRADIUSの設定ファイルを直接触る必要はほぼない。
スイッチをネットワークデバイスとして設定する
PacketFence GUIでConfiguration → Network Devices → Switchesに移動し、スイッチを追加する。以下はCisco IOSスイッチの最小限の同等設定だ:
# Ciscoスイッチ上での設定
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control
radius server PACKETFENCE
address ipv4 192.168.1.10 auth-port 1812 acct-port 1813
key YourSharedSecret
interface GigabitEthernet0/1
switchport mode access
dot1x port-control auto
authentication host-mode multi-auth
spanning-tree portfast
PacketFence側では、スイッチタイプ(Cisco Catalyst)、RADIUSシークレットを設定し、どのVLANをどのロールにマッピングするかを定義する。ベンダー固有の属性マッピングはそのまま使える——PacketFenceにはAruba、Juniper、Extreme、Merakiなど数十種類の組み込みテンプレートが付属している。
VLANロール:NACポリシーの核心
PacketFenceはロールを使ってネットワークアクセスレベルを割り当てる。デフォルトのロールは以下の通りだ:
- registration — 隔離VLAN、キャプティブポータルにリダイレクト
- isolation — 非準拠または不審なデバイス用
- default — 通常の認証済みアクセス
- カスタムロール(ゲスト、業者、IoTなど)
各ロールをネットワークインフラ上に既存のVLAN IDにマッピングする。スイッチはPacketFenceのRADIUS応答に基づいて、ポートを動的に正しいVLANに配置する。
非802.1Xデバイス向けMACアドレス認証バイパス
プリンター、IPカメラ、IoTセンサーは802.1Xを実行できない。PacketFenceはこれらをMAB(MAC Authentication Bypass)で処理する。スイッチがMACアドレスをRADIUSユーザー名として送信し、PacketFenceが許可リストと照合するか、専用ロールに自動登録する。
# PacketFence CLIでMABの例外を追加する
/usr/local/pf/bin/pfcmd node add 00:1A:2B:3C:4D:5E category=iot status=reg
# またはREST APIを使用する
curl -k -X POST https://localhost:9090/api/v1/nodes \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"mac": "00:1a:2b:3c:4d:5e", "category": "iot", "status": "reg"}'
応用編:Active Directory連携とコンプライアンスチェック
PacketFenceをActive Directoryに接続する
多くのエンタープライズ環境はすでにActive Directoryを運用している。PacketFenceはドメインに直接参加できる——Configuration → Active Directory Domainsに移動し、Configuration → SourcesでどのADグループをどのPacketFenceロールにマッピングするかを定義する。
# ADドメインに参加する(PacketFenceサーバー上で実行)
/usr/local/pf/bin/pfcmd domain add EXAMPLE.COM \
--server dc1.example.com \
--username Administrator \
--password 'YourPassword'
参加後、EAP-TLSまたはPEAP-MSCHAPv2を使用するWindowsマシンはドメイン資格情報で透過的に認証される。キャプティブポータルは不要だ。ドメイン参加済みマシンは接続するだけで、自動的に正しいVLANに配置される。
エンドポイントコンプライアンススキャン
PacketFenceはNessusおよびOpenVASと連携し、フルアクセスを許可する前にデバイスをスキャンできる。デバイスが接続するとスキャンVLANに配置される。PacketFenceがNessusスキャンをトリガーし、その結果に基づいてデバイスは通常のVLANに移行するか、isolationで隔離される。
スキャンエンジンはConfiguration → Compliance → Scan Enginesで設定し、新しいデバイスが初めて登場した際に自動適用する登録時スキャンプロファイルを作成する。
Cisco WLCまたはArubaとのWi-Fi連携
無線の場合、PacketFenceはWLC(Wireless LAN Controller)のRADIUSサーバーとして機能する。コントローラーのRADIUS認証先をPacketFenceのIPに向けるだけだ。PacketFenceはクライアントに割り当てるVLANをコントローラーに通知するTunnel-Private-Group-ID RADIUS属性を返す。企業向けWi-FiでWPA3と802.1Xを組み合わせた認証基盤を構築している場合、PacketFenceはその中央RADIUSとして自然に組み込める。
# 例:PacketFenceがトンネルVLAN割り当てのために返すRADIUS応答属性
# /usr/local/pf/conf/radiusd/packetfence-tunnel.conf
reply {
Tunnel-Type = VLAN
Tunnel-Medium-Type = IEEE-802
Tunnel-Private-Group-ID := "%{reply:PacketFence-Vlan}"
}
PacketFenceはSSIDごと・ユーザーグループごとの動的VLAN割り当てもサポートしている——ゲストとエンプロイーで異なるVLANを割り当てつつ、同一の物理APインフラを共有できる。
現場から学んだ実践的なヒント
まずはモニターモードから始める
最もよく見かける失敗は、ネットワーク全体で一晩のうちに802.1X強制をオンにしてしまうことだ。デバイスが壊れ、ヘルプデスクが溢れ、経営陣がプロジェクト全体の中止を命じることになる。
代わりにPacketFenceをモニターモードで起動しよう。VLANの変更を実際には行わず、「実施していたら何が起きていたか」をログに記録するだけのモードだ。2〜4週間これを続けることで、問題のあるデバイス——プリンター、VoIP電話、XPを動かす古いワークステーション——が浮かび上がり、実際のポートを有効化する前に例外リストを整備できる。
DHCPフィンガープリントでデバイスを自動分類する
PacketFenceはDHCPオプション55(パラメーターリクエストリスト)を検査することで、デバイスタイプを自動的に識別する。iPhoneはWindows 11ラップトップとは異なる特徴を持ち、Cisco 8800シリーズのIP電話とも異なる。管理インターフェースでDHCPリスニングを有効にすることで、手動操作なしにPacketFenceが新しいデバイスを自動分類する:
# pf.confでDHCPリスナーを有効にする
[interface eth0]
type=management,dhcplistener
ip=192.168.1.10
mask=255.255.255.0
アラートと不正デバイス検出
ネットワーク上に未知のMACアドレスが現れた場合、PacketFenceで検知できる。Configuration → Security Eventsで未知MACに対するdetectトリガーを持つセキュリティイベントを設定し、メールまたはSlack Webhookへの通知を連携させる。これによりPacketFenceは受動的なゲートキーパーから、能動的なレイヤー2侵入検知ポイントへと進化する。LibreNMSとSNMPによるネットワーク可視化と組み合わせることで、NACが弾いたデバイスの挙動もリアルタイムで把握できる。
バックアップとHA構成の検討
本番環境ではセカンダリノードが必要だ。組み込みのクラスタリングはCorosync/Pacemakerと共有MariaDB Galeraクラスターを使用する。最低限、毎日のデータベースバックアップを実施しよう:
# PacketFenceデータベースをバックアップする
mysqldump -u pf -p pf | gzip > /backups/pf_$(date +%F).sql.gz
# 設定ディレクトリをバックアップする
tar czf /backups/pf_conf_$(date +%F).tar.gz /usr/local/pf/conf/
PacketFenceノードが1台停止しても、既存のセッションは継続する——しかし新しい接続や再認証は失敗する。KeepalivedとVRRPでフローティングIPを構成することでRADIUSサービスの可用性を高め、この障害モードを最初から想定した上で設計しておくことが重要だ。
フラットネットワークから強制されたペリメーターへ
NACがセキュリティチェックリストに登場するのは、たいていインシデントの後だ。本来は最初に来るべき対策だ。冒頭で紹介した会議室への侵入は、基本的なPacketFenceの導入があるだけで完全に防げていた——そのデバイスはregistration VLANに配置され、未知MACアラートが発報され、ファイルサーバーには近づけなかったはずだ。
ファイアウォールルールを書くよりも学習曲線は急だが、PacketFenceのドキュメントはしっかりしており、コミュニティフォーラムも活発だ。まずはZENアプライアンスをラボで試し、VLANロールとRADIUSフローに慣れよう。その後、本番スイッチに1セグメントずつ展開していく。数週間の慎重なロールアウトを経れば、完全にフラットで全デバイスを信頼していたネットワークは、接続を試みるすべてのデバイスに積極的に問いかけるネットワークへと生まれ変わる。

