はじめに
Microsoft Entra Private Access を利用することで社外から、社内ネットワーク上のリソースにアクセスさせる構成が可能になるが、その構成下で Windows Defender Firewawll でのネットワーク上の制御をどこまで行えるかを実験してみることにした。
TL;DR
実験ケース
前提
今回は Microsoft Edge、Google Chrome の2つのブラウザをインストールしている Windows 11 端末において、Microsoft Private Access を利用して社内ネットワークにデプロイされた Web サーバーにアクセスするケースで、Google Chrome からの接続のみ Windows Defender Firewawll を利用しブロックすることが可能かを実験する。
念のため Windows や GSA クライアントバージョンは以下(検証日時点で最新のはず)
- Windows 11 24H2 OSビルド 26100.6584
- GSA Client ver.2.20.56.0
Quick Access (IP アドレスの範囲) + Private DNS のパターン
事前準備
Private Access で社内ネットワークにアクセス可能にするための構成の仕方はいくつかある。まず、Quick Access といわれるデフォルトで構成されている簡易的な Private Access で公開する用の Entra 上でのアプリケーションを利用する方法だ。Quick Access のアプリケーション セグメントの指定の仕方も複数の方式が存在しているが、今回は IPアドレスの範囲(CIDR)で Web サーバーの IP アドレスを含むように設定を行った。また、Web サーバのホスト名(URL)についてはコネクタ サーバーが参照している DNS にて名前解決を可能とする、Private DNS を有効にした。これにより、外部ネットワーク上にある Private Access が有効な Windows 端末から、URL で社内 Web サーバにアクセスできる。
- Web サーバは 10.4.4.5 でホスト
- URL は http://nhswtt03-misc.navyhaze.com で構成
- クライアント Windows 上の GSA クライアントでのプロファイルは以下の通り。Private Access ルールで Web サーバーの IPアドレスが含まれており、Private DNS ルールで URL の DNS サフィックスが構成されている事が確認できる。
接続確認
先ずは、Windows Firewall で特に何も設定せずにアクセス。どちらのブラウザでも問題なく Web サーバーにアクセス可能。
- Microsoft Edge
- Google Chrome
GSA クライアントの Advanced Diagnostics の機能での Hostname Acquisition の状況は以下の通り。Generated IP Address は空欄で、Original IP Address にホストに割り当てられている IP アドレスが表示されている。
Windows Defender Firewawll の有効化
Microsoft Entra Private Access で対象の Web サーバーにアクセスできることを確認したので、Windows Defender Firewall を設定し、Google Chrome のみ接続を制限可能かチェックしてみる。
- Windows Defender Firewawll の送信の規則に対して、ブロックのルールを作成
- プログラムは Google Chrome の実態の PE ファイルのパスを指定
- スコープとして、リモート IP アドレスに Web サーバーの IP アドレス(10.4.4.5) を指定。
- プロトコル及びポートのリモート ポートに 80 を指定(HTTPS構成していないけど何となく443も入れてますが、気にしないでください。)
確認結果
上記構成を有効にし、再度 Microsoft Edge と Google Chrome で接続してみると、以下の通り Edge のみアクセスが成功する。
- Microsoft Edge
- Google Chrome
この Quick Access(IP アドレス) + Private DNS パターンであれば、Windows Defender Firewall を使い、特定のプログラム、接続先に対しての制御を行うことが可能であることを確認した。
個別のエンタープライズアプリ(IP アドレス設定、FQDN 設定) で Private DNS なしパターン
事前準備
Private Access で社内ネットワークにアクセス可能にするための構成のもう一つとして、公開するアプリを個別のエンタープライズアプリとして Entra で構成する方がある。Private DNS との組み合わせでも動くが、Private DNS を無効化した状態での FQDN を設定した際の動作差異を確認するため、Private DNS はこのパターンでは無効化する。Web サーバの IP アドレス、FQDN 自体は先述のパターンと同様とする。
- 今回のケースでクライアント Windows 上の GSA クライアントでのプロファイルは以下の通り。Private Access ルールで Web サーバーの FQDN と IPアドレスが構成されている事が確認でき、Private DNS ルールのプロファイルが消えている状態になった。
接続確認
先ずは、Windows Firewall で特に何も設定せずにアクセス。どちらのブラウザでも、FQDN、IP アドレスの両方で問題なく Web サーバーにアクセス可能であることを確認(画像省略)
GSA クライアントの Advanced Diagnostics の機能での Hostname Acquisition の状況は以下の通り。FQDN でのアクセス時は Generated IP Address に GSA で利用する独自の IP アドレス(合成 IP) が6.6.0.186 として振られた事が分かる。
Windows Defender Firewawll の有効化 1
Microsoft Entra Private Access で対象の Web サーバーにアクセスできることを確認したので、Windows Defender Firewall を設定し、Google Chrome のみ接続を制限可能かチェックしてみる。
先ずは以前のものと同様に、サーバーに設定されている IP アドレス(10.4.4.5)を リモート IP として設定(その他の設定も同様なので画像省略)
接続確認 1
FQDN でまずは接続確認。Microsoft Edge では当然問題なく、Web サーバーにアクセス成功。次に Google Chrome でアクセスしてみる。結果は問題なく、Web サーバーにアクセス成功
- Google Chrome
当然ブラウザのキャッシュをクリアするなどもちゃんと確認。でもやはりアクセスできる状態。
続いて IP アドレスを入力して、ブラウザアクセスを確認。Microsoft Edge はアクセス成功。一方 Google Chrome についてはアクセスが失敗する。
- Google Chrome
Windows Defender Firewawll の有効化 2
上記の通り、今回のケースでは Windows Defender Firewall に Web サーバーに設定されている IP アドレス(10.4.4.5)を リモート IP として設定してもアクセス可能であった。それでは、Private Access(Global Secure Access) が生成する合成 IP(Synthetic IP) アドレス宛ての通信を制御する場合はどうなのかを確認するため、Advanced Diagnostics で確認できている、6.6.0.186 の IP アドレスを Windows Defender Firewall の リモート IP アドレスとして指定してみる。
接続確認 2
もはや、Microsoft Edge での接続確認の結果は別にいう必要はないと思うが、FQDN、IPアドレス どちらでも接続もちろんできている。
肝心の Google Chrome での接続結果だが、FQDN を指定してアクセスした際にアクセスが失敗するようなった。きちんと Global Secure Access の合成 IP でブロックされている事を、Windows Firewall のブロック ログを有効化にし確認した。
一方 IP アドレスを直接指定したアクセスは成功するようになった。これは Windows Firewall に設定したブロック対象の IP アドレスは本来の Web サーバーに割り当てている IP アドレスから、合成 IP アドレスに変更したため、ブラウザが接続先として指定する Web サーバーの IP アドレスではないため、期待される動作といえる。
Windows Defender Firewawll の有効化 3
Global Secure Access で付与する 合成 IP は実際のクライアント端末から Outbound の宛先として設定されるわけではない。Wireshirk でパケット キャプチャを行っても、6.6.0.0/16 宛の通信は見つからない。パケット キャプチャを行うと、実際に Private Access の通信として、TCP パケットが送られている Destnation は Global Secure Access の PoP(Point of Presensce) として公開されている IP アドレスが確認できるはずだ。
実際の検証環境でパケット キャプチャをした結果でも、Microsoft の Learn ページに記載されている、IP アドレス宛ての通信を確認できた。
その為、これらの Global Secure Access の PoP の通信に対してのブロック ルールを Windows Defender Firewall で入れてみる。
接続確認 3
Google Chrome で FQDN と IP アドレスそれぞれで、接続を試してみると、両方とも Web サーバーにアクセス成功する。
(Microsoft Edge も確認してアクセス成功している。念のため)
※ 今回はあくまでアプリケーションやポートを明示的に設定している為、このような結果になっているが、単純に IP アドレスのみを対象にブロックした場合は Global Secure Access 自体のトンネリングの確立自体が失敗すると思われる。
結論
上記の実験結果から、以下の表のような制御となると考えられ、Private Access で Windows Defender Firewall を利用した通信制御を行う場合は構成により接続先の本来の IP アドレスと、合成 IP の違いを意識して制御が必要となる。また、合成 IP は名前解決時に Global Secure Access にて付与され、固定されないため、現実的には 6.6.0.0/16 のレンジで 合成 IP が使われるレンジ一括での制御でしか制御できないと思われる。
| Private Access のアプリ公開設定方法 | Windows Firewall ブロック設定 | 制御結果 |
|---|---|---|
| IP アドレス設定 + Private DNS | ホスト IP アドレス | 成功(ブロックされる) |
| IP アドレス設定 | ホスト IP アドレス | 成功(ブロックされる) |
| FQDN 設定 | ホスト IP アドレス | 失敗(ブロックされない) |
| FQDN 設定 | 合成 IP アドレス | 成功(ブロックされる) |
| FQDN 設定 | Global Secure Access PoP アドレス | 失敗(ブロックされない) |
Appendix.今回調べた情報と考察(個人メモ レベル)
Global Secure Access 利用時の DNS 名前解決の動作
Global Secure Access が有効になっている場合は、DNS 名前解決の動作が通常とは異なるようになる。Global Secure Access クライアントをインストールすることで、 NDIS lightweight filter driver が追加されている事を確認できる。
Global Secure Access クライアントはこの NDIS LWF Driver で必要な通信の宛先を変更していると推測できるだろう。
また、Private DNS の動作については、Microsoft Learn で公開されている。
これらの情報と、今回の実験結果から以下の動作と推測できる。
- Private DNS が有効な場合は NRPT にて対象のドメイン、FQDN を 6.6.255.254 へ DNS 問い合わせ。
- NDIS LWF Driver (GSA クライアント) で DNS クエリをフックし、Global Secure Access のプロファイルの対象の FQDN については、合成 IP アドレスを作成。(正規の DNS でのアドレス解決結果も Original IP Address として保持)
- 名前解決を要求したアプリケーションに対して、Private DNS の結果、または合成 IP アドレスを返す。
- その後の通信についても NDIS LWF Driver (GSA クライアント) でフックし、合成 IP (6.6.0.0/16)あて、または Private Access アプリケーションで定義されている IP アドレスである場合は、Global Secure Access のトンネル側にルーティング
Global Secure Access の合成 IP のレンジ
パートナー製品との共存設定のガイドにバイパスする IP アドレスとして、6.6.0.0/16 の記載があるので、恐らくこれが合成 IP アドレスで利用するアドレス範囲なのだろう。
ZScalerの例
Windows Firewall のかかるポイント
理解がかなりざっくりだが、WFP の制御は NDIS LWF Driver 前に入ると理解した。特にルールでアプリケーションを指定した場合。なので、送信先 IP アドレスはアプリが名前解決の結果受け取った、Priavate DNS 経由の IP アドレスまたは、合成 IP アドレスに対しての Windows Firewall の Block ルールを適用できる。
ざっくりと以下のようなイメージになると理解した。(誤っている点があれば是非指摘いただけると助かります。)
Discussion