Azure上にpaloaltoを構築してみた

「Azure上でpaloaltoを作成して、Azure上にある仮想マシンからインターネットに向かう通信をすべてpaloalto経由にする」というAzure上でのNVA構成を試してみました。

単純にAzure上で仮想アプライアンスを作成する場合ってどうなのだろうか？が気になったのと、仮想アプライアンスの中でもpaloaltoが一番知識があったのでやってみました。

今回はAzureのマーケットプレイスから「VM-Series Next-Generation Firewall from Palo Alto Networks」を利用して作成していきます。

今回作成する構成図

上記でも概要図を載せましたが、より詳細に書くと以下のような構成になります。

今回はこの環境を作成して、右側の仮想マシンからpaloaltoを経由してインターネットに向けて通信を行いました。

環境の作成

まずは環境を構築していきます。

マーケットプレイスからpaloaltoを作成

AzureのTOPページから「paloalto」などと検索して、マーケットプレイスの「VM-Series Next-Generation Firewall from Palo Alto Networks」を選択します。

今回はBYOLではなくPAYG（その中でもすべての機能を利用できる[Bundle2]）を選択し、ライセンスも一緒に購入します。

[基本] タブの設定

[基本] タブを設定します。

ここで指定するリソースグループはリソースが一切存在しないリソースグループを選択する必要がありますので注意が必要です。

リソースが存在する場合には以下のように警告が表示されて、paloaltoをデプロイすることができません。

[Networking] タブの設定

[Networking] タブを設定します。

仮想ネットワークは新規作成し、今回は構成図に記載の通りのIPアドレスを利用します。

[VM-Series Configration] タブの設定

[VM-Series Configration] タブを設定します。

今回はパブリックIPのSKUは[Standard]として新規作成します。

PAN-OSのバージョンは「latest」を選択しますが、選択肢としては現時点（2022年4月24日時点）では以下がありました。

仮想マシンのサイズはVM-300相当の[Standart D3 v2]を選択します。

ディスクにSSDを利用したい場合には、ここで[Standart DS3 v2]などを選択することになります。

最後に[確認および作成] タブでエラーなどが発生しなければ下部の「作成」をクリックして作成完了です。

テスト用の仮想マシンを作成

paloaltoの仮想マシンのデプロイには時間がかかるので、その間にテスト用の仮想マシンをサクッと作成します。

以下の流れで仮想マシンを作成していきます。

• リソースグループを作成
• NSGを作成＋RDP接続許可のルールを追加
• 仮想ネットワークを作成
• 仮想マシンの作成

今回は以下のAzureCLIのコマンドで作成しましたので参考にしてください。

#リソースグループの作成
$rg = az group create -l "japaneast" -n "Test-VM-RG" | ConvertFrom-Json

#NSGの作成
$nsg = az network nsg create -n "NSG-Test-VM" -g $rg.name | ConvertFrom-Json

#NSGにルールを追加　※送信元IPには適切な値を入れてください
az network nsg rule create -n "Allow-RDP" --nsg-name $nsg.newnsg.name --priority 100 -g $rg.name --destination-port-ranges 3389 --protocol "Tcp" --source-address-prefixes "xxxxxxxx"

#仮想ネットワークの作成
$vnet = az network vnet create -n "Vnet-Test-VM" -g $rg.name --address-prefixes "172.16.0.0/24" --subnet-name "Subnet-Test-VM" --subnet-prefixes "172.16.0.0/25" --nsg $nsg.newnsg.name | ConvertFrom-Json

#テスト用仮想マシンの作成
az vm create -n "Test-VM" -g $rg.name --image "Win2019Datacenter" --vnet-name $vnet.newvnet.name --subnet $vnet.newvnet.subnets.name

Azureポータル上からGUIで作成しても問題ありません。

paloaltoのOS内設定

paloaltoのデプロイが完了したら、払い出されたPublicIPをブラウザで入力してログインします。　※私はいつもchromeを利用しています。　

以下ようにpaloaltoのGUIのwebコンソールが表示されますので、今回はGUIで設定していきます。

続いてインターネット向けに通信ができるように最低限の設定をしていきます。

インターフェースの設定

今回作成したpaloaltoは「Azure上にある」ためL3ですのでVLANなどのL2について気にする必要がありません。

なので「ethernet1/1にVLANのタグをつけたサブインターフェースを作成する」といった設定をする必要もないかと思ったので、今回はサブインターフェースを作成せずにインターフェースにIPを設定していきます。

設定する前にAzure上で各インターフェースがどのsubnetに所属しているのか、IPアドレスが何かを調べておきます。

今回はeth1に[Subnet-Untrust]が設定されており、IPは[10.0.0.68]でしたのでその値をOS内でも設定していきます。

paloalto内では[NETWORK]‐[Interfaces]より設定します。

[Interface Type]を「Layer3」として、先ほど調べた[IPアドレス]の値を入力します。

続けてeth2も同じように設定します。

ゾーンの設定

今回は[Untrust]と[Trust]のゾーンを設定して、eth1とeth2に対応させていきます。

先ほど「eth1が[Subnet-Untrust]」であることを確認したので、[Untrust]ゾーンをeth1に対応させます。

paloalto内では[NETWORK]‐[Zones]より設定します。

必要に応じて[Log Setting]や[Zone Protection Profile]などの設定も追加してください。

続けて[Trust]ゾーンを作成してeth2に対応させます。

仮想ルーターの設定（スタティックルートの設定）

仮想ルータの設定でスタティックルートを設定します。

paloalto内では[NETWORK]‐[Virtual Routers]より設定します。

今回は既存で存在する[default]の仮想ルータを利用し、まず[Router Settings]にてインターフェースを追加します。

次に[Static Routers]を設定します。

今回は[Untrust]ゾーンのeth1を利用して通信がインターネットに出ていくので、デフォルトルートがeth1に向かうように設定を入れます。

また、[Next Hop]の値には「subnetのデフォルトゲートウェイ」を指定する必要がありますので注意してください。

今回eth1は、Azure上で「10.0.0.64/26」として定義されたsubnetを利用するので[10.0.0.65]がデフォルトゲートウェイのIPとなりますのでその値を設定しています。

テスト用仮想マシンに向かうスタティックルート（戻りのルート）も記載します。

セキュリティポリシーの設定

今回はインターネット向けの通信をすべて許可する設定を入れます。

paloalto内では[POLICIES]‐[Security]より設定します。

設定値としては送信元ゾーンを[Trust]、宛先ゾーンを[Untrsut]とし、それ以外の値もすべて[any]として許可します。

肌色のような色がついている下２つのポリシーは編集/削除などできないデフォルトのポリシーです。

NATポリシーの設定

最後にNATポリシーを設定します。

paloalto内では[POLICIES]‐[NAT]より設定します。

今回は送信元ゾーンを[Trust]、宛先ゾーンを[Untrust]として設定します。

[Translated Packet]部分では[Source Address Translation]に以下のように設定を入れます。

• Translation Type：Dynamic IP And Port
• Address Type：Interface Address
• Interface：ethernet1/1
• IP Address：10.0.0.68/26

すべてプルダウンで選択可能です。

コミット

最後にコミットして設定を反映させます。

これでpaloalto内の設定が完了しました。

（必要があれば）eth0のパブリックIPのSKUを[Standard]に変更

paloalto仮想マシンのデプロイ時にパブリックIPを新規作成し、その際に[Standard]を選択したはずなのですが、デプロイ後に確認してみると[Basic]となっていました。

なので、もし私と同じ状態になっている場合、eth0のNICのIP構成からパブリックIPを一度デタッチし、パブリックIPをアップグレードさせて、再度eth0のNICのIP構成にアタッチしてSKUを[Standard]にしてください。

ちなみに、MgmtサブネットのNICのパブリックIPが[Basic]であってもインターネット向けの通信は通りますのでここで変更しなくても問題はありません。

Vnetpeeringを作成

ここで再度Azureの設定に戻り、テスト用VMがある仮想ネットワークと、paloaltoがある仮想ネットワークをVnetpeeringで接続させます。

本当はここもAzureCLIで作成したかったのですが、AzurCLIですと同一リソースグループにあるVnet同士のpeering接続しか設定できなさそうであったため今回はAuzreポータルから作業しました。

RouteTableを作成・Subnetに紐づけ

最後の作業としてルートテーブルを作成して、テスト用の仮想マシンが存在しているsubnetに紐づけます。

システムルートの状態では仮想マシンの通信はpaloaltoに向かないため、ルートテーブルを利用してpaloaltoに向くように設定します。

以下の流れで作成・設定していきます。

• ルートテーブルを作成　＋　ルールを２つ追加
• ルートテーブルをsubnetに紐づける

以下のAzureCLIのコマンドで作成しましたので参考にしてください。

#RouteTableを作成
$RouteTable = az network route-table create -n "RouteTable-Test-VM" -g "Test-VM-RG" | ConvertFrom-Json

#RouteTableにルールを追加（インターネット通信がpaloaltoに向かうようにする）
az network route-table route create --address-prefix "0.0.0.0/0" -n "To-Internet" --next-hop-type "VirtualAppliance" -g "Test-VM-RG" --route-table-name $RouteTable.name --next-hop-ip-address "10.0.0.132"

#RouteTableにルールを追加（自分の端末からの通信だけは直接テスト用仮想マシンにアクセスできるようにする）
az network route-table route create --address-prefix "xx.xx.xx.xx/xx" -n "To-Internet" --next-hop-type "Internet" -g "Test-VM-RG" --route-table-name $RouteTable.name

#RouteTableをSubnetに紐づける
az network vnet subnet update -n "Subnet-Test-VM" -g "Test-VM-RG" --vnet-name "Vnet-Test-VM" --route-table $RouteTable.name

2つ目のルールは、記載しないと自分の端末からテスト用仮想マシンへの通信が成立しなくなってしまうので記載が必要です。

このルートテーブルをsubnetに紐づけた時点からテスト用仮想マシン発の通信がpaloaltoに向くようになります。

環境の作成としてはこれで完了です。

仮想マシンからインターネットに向けて通信を流す

ルートテーブルを紐づけた時点でテスト用仮想マシンのインターネット向けの通信はpaloaltoに流れていますが、改めて通信を流して確認していきます。

[www.yahoo.co.jp]に通信する

テスト用の仮想マシンで[www.yahoo.co.jp]にアクセスします。

[www.yahoo.co.jp] は正引きすると [183.79.250.123] でしたので、paloaltoのログにこのIPが流れているかを確認します。

paloalto内の[MONITOR]‐[Logs]‐[Traffic] よりログを確認します。

ログのクエリで( natdst eq 183.79.250.123 )と入力し、確認してみるとログとして検出されるのでpaloaltoを経由してインターネット接続していることがわかります。

[183.79.250.123]をセキュリティポリシーでDenyする

セキュリティポリシーで宛先が[183.79.250.123]となる通信をdenyさせて、通信ができなくなるかを試してみます。

paloaltoでは上から順にポリシーが評価されていき、一致したポリシーがあるとそれ以降のポリシーは評価されないので、上記で作成した「Allow-To-Internet」よりも上に「Deny-yahoo」というポリシーを作成し、コミットします。

コミット完了後にテスト用仮想マシンでブラウザアクセスを試すと以下のようにyahooのTOPページが開かなくなりました。

また、paloaltoのログを確認すると「Deny-yahoo」のポリシーでdenyとなっていることが確認できます。

やってみて気づいたこと

PAN-OSは[10.2.0]であった。

paloaltoデプロイ時に[latest]を選択すると、デプロイされたpaloaltoのPAN-OSは[10.2.0]でした。

[latest]以外の選択肢の中に[10.2.0]は存在しなかったので少し驚きましたが、デプロイ時点での最新のバージョンが選択されていると考えると文字の通りかとも思いました。

NATポリシーはプライベートIPを指定してよい

何気に苦戦した部分ですが、NATポリシーにおける[送信元アドレス]はプライベートのIPを利用します。

パブリックIPを指定するものかと思っていたらプライベートIPの指定で問題ありませんでした。

そもそもeth1にはAzureリソースのパブリックIPを付与していませんので、インターネットに出ていく際に、どの値のパブリックIPが利用されるのかはこちらからは分かりません。

考えてみればあたり前ですが気づくのに時間がかかりました。

デプロイされたパブリックIPのSKUが[Standard]になっていない

上記でも記載しましたが、デプロイ時にMgmtのNICに付与するパブリックIPを新規作成する際にSKUを[Standard]に指定したはずなのですが、デプロイ後に確認してみるとなんと[Basic]になっていました。

なのでスタンダードへと変更する場合には、デプロイ後にパブリックIPをMgmtのNICから一度デタッチして、[Standard]にアップグレードしてから再度アタッチする必要があります。

MgmtサブネットのNICのパブリックIPが[Basic]であってもインターネット向けの通信は通りますが、[Basic]のほうが機能面でも制約が多く、個人的には[Standard]を利用するほうが将来性があってよい気がしているので[Standard]に変更するという内容も記載してみました。

さいごに

今回初めてAzure上で仮想アプライアンスを構築してみましたが、Azureリソースのことも考える必要があるので、paloaltoの知識だけでなく、Azure側の知識も必要だということが分かりました。

もともとpaloaltoは触っていたこともあるので試しにやってみましたが、気になる点が多々出てきたので、これを機に「Azure上にあるpaloalto」についてもっと調べていこうと思います。＾＾