これは何
- Azure Firewallの明示的なプロキシを試してみる話
- 現時点での注意点も記載
Azure Firewall Explicit Proxy
先日Azure Firewallの明示的なプロキシ機能がPublic Previewとなりました。これによってプロキシサーバーを立てたり、外部のプロキシを経由させることなくAzure Firewallに一本化することが可能です。
- アナウンス(as of Aug, 31, 2023)
- Docs
- 解説Blog
何がうれしいのか
-
クライアントからAzure Firewall経由でインターネットアクセスしたい場合に、Azure Firewallをプロキシとして設定することはできず、あくまで0.0.0.0/0->Azure FirewallのUDRによってトラフィックを制御することで実現していた
-
このやり方だと、同じネットワークセグメントに属するクライアント全てに否応なく影響が出る
-
Azure Firewallをプロキシとして構成できるようになると、クライアント側から指定できるため、ネットワークセグメント全体のトラフィックを曲げることなくクライアントごとの設定として利用できる
-
加えて、この明示的なプロキシはAzure Firewallのアプリケーションルールでフィルタされるため、アプリケーションルールで利用可能なFQDNタグやWebカテゴリといったAzure PaaSらしい機能がそのまま利用可能
-
外部のプロキシを指定する場合だと、特にFQDNの管理が面倒だが、Azure Firewallであればそこをタグで管理できる
検証
以下のようなシンプルな環境を用意
デフォルト状態でのインターネットアクセスは以下のような状況
Internet access via Azure default NAT
Azure Firewall アプリケーションルールの作成
- とりあえずhttp/httpsで
www.google.com以外のすべてのFQDNにアクセスできるようにしておく
明示的なプロキシの有効化
- 先の通信をAzure Firewall Explicit Proxy経由にしていく
- Azure Firewallに関連付けているFirewall Policyを開き、[明示的なプロキシ]から[明示的なプロキシを有効にする]をチェック
- HTTP/HTTPSをAzure Firewall側のどのポートで待ち受けるかを指定(Squidの3128のイメージ)
- HTTP/HTTPSで共通のポート番号を指定するのは不可
- ここでは60000/50000とした
- プロキシの自動構成は一旦なしで設定
クライアント側の設定
- Windows Serverの[Proxy Settings]から、[Manual proxy setup]で
http=10.0.1.4:60000;https=10.0.1.4:50000を指定 - すると、UDRを設定していないにもかかわらずAzure FirewallのPublic IPでインターネットに抜けていることがわかる
Use a proxy server:on
Use a proxy server:off
プロキシの自動構成
- Azure Firewallの[プロキシの自動構成]を試す
- プロキシの構成はクライアント側では？と思ったが、どうやらこれはAzure Firewallの特定ポート経由でストレージアカウント上に保存されたPACファイルを参照できる仕組みのよう
- 以下のようなPACファイルを作成し、ストレージアカウント上に保存
var http_proxy = "PROXY 10.0.1.4:60000";
var https_proxy = "PROXY 10.0.1.4:50000";
function FindProxyForURL(url, host) {
if (url.startsWith('https:')) {
return https_proxy;
} else {
return http_proxy;
}
}
-
PACファイルのSASURLおよび公開するポート番号を指定
Proxy Auto Setting w/ Storage SAS -
SASURLが必要になるのであれば、わざわざAzure Firewall上で公開する必要あるのか？という気もする
- 本題に戻り、クライアント側のProxy Settingから[Use setup script]をオンにし、
http://<Azure Firewall Private IP>:<Port>/<PAC file Name>という形で指定する - httpsでは読み込まれなかったため注意、クライアント-Azure Firewall間は内部通信なので問題なし
- Azure Firewallのプロキシ自動構成機能がhttpでしか待ち受けないというだけかも
Proxy Auto Setting w/ Azure Firewall Private IP
アプリケーションルールのフィルタ確認
- 前述のようにこのFirewallポリシーでは
www.google.comのみDenyとしている -
www.google.comにアクセスしてみると正しく遮断された
- それ以外の、例えば
www.youtube.comは何事もなくアクセスできた
- アプリケーションルールでフィルタをしているため、アプリケーショーンルールの中で使えるようなFQDNタグやWebカテゴリなどの機能が利用できるのも嬉しい点
SASURLの期限が切れていたらどうなるか？
- SASには期限がつきものなので、期限切れの場合にどうなるかは要注意ポイント
- 前提として、Firewall Policyに対して、何等か変更がかかる(PUT処理)のタイミングでSASの先のPACファイルを取りに行く
- つまり、期限が切れていても暫くは動作はする
SAS期限切れの状態でアプリケーションルールをいじってみる-その１
-
SASが切れた状態で本環境のアプリケーションルールから
denyGoogleの規則を削除してみる（=全許可の状態になる） -
すると、"規則の削除失敗"というエラーが表示されるが、Azure Portal上は確かに削除される
actually deleted on Azure Portal -
この状態で、プロキシのクライアントから
www.google.comへ再度アクセスすると、ルールを削除しているにもかかわらずブロックされる
SAS期限切れの状態でアプリケーションルールをいじってみる-その２
-
その１の状態でSASを再発行し、Azure Firewallを正しい状態に戻す
Application Rule: All Allow -
www.google.comにアクセス可能なことを確認
-
SASの期限が切れた後で、アプリケーションルールを削除し、ルールなし(＝全拒否)の状態にする
-
先ほど同様エラーは出るものの、ルールは削除される
-
クライアントから
www.google.comにアクセス可能なままとなっている
Firewallポリシーの他の変更はどうか
- 試しにDNSの設定を変更してみると、こちらも同様エラーが出るのだが、状態は変更前の状態に戻された
おわり
- Azure Firewallがある環境においては、オンプレや外部のプロキシを通さずとも、Azure Firewallのアプリケーションルールベースでフィルタリングできるのが管理しやすい
- FQDNタグを利用すれば、Microsoft系のサービスについてのアクセスも容易に制御できるため、運用はかなり楽になりそう
- 注意点としては、AzureFirewallにPACファイルを認識させる場合にSASURL経由となるため、有効期限の更新管理が必要となる点で、ここが原因によるエラーだと気づきにくいのも罠
- 何よりリソースの状態と挙動に不整合が起きるのでだいぶよろしくない
- SASで期限を気にするくらいならPACファイルを配置するサーバを立てた方がいいのでは？
という感じでした
Discussion