今回は脆弱性保護機能のテストをしたいと思います。VMトライアルラインセスでは動作しなかったため、AWS環境で実施しています。構成は下記の通りです。
1. 前提
Publicセグメント内にあるLinuxのみ外部からの接続を許可する形にして、セキュリティグループは10.0.0.0/16で許可。SSHポートフォワードを設定してPalo向けのHTTPSおよびWindows2016へのRDP接続をしています。
Internal-ZoneのWindows2016とDMZ-ZoneのAmazonLinuxはそれぞれのセグメント向けにスタティックルートを設定しています。一時的にインターネットからパッケージを引っ張ってきたりChromeをインストールするために、NATGatewayも設定しました。また、Paloaltoに後から追加したDMZとInternal用NICのセキュリティグループは下記の通り設定しています。
| Sourceアドレス | プロトコル | タイプ |
|---|---|---|
| 10.0.0.0/16 | TCP | すべてのTCP |
| 10.0.0.0/16 | UDP | すべてのUDP |
| 10.0.0.0/16 | ICMP | すべてのICMP |
2. 脆弱性保護プロファイル作成
では、脆弱性保護プロファイルを作成していきます。管理画面にログイン後、画面上の「OBJECTS」タブから画面左の「脆弱性防御」をクリックして、画面下の「追加」をクリックします。
名前を入力して、画面したの「追加」をクリックします。
ルール名を入力し、脅威名を「any」、アクションを「両方のリセット」として「OK」をクリックします。
「OK」ボタンをクリックします。
3. セキュリティポリシーへの適用
次は、事前作成済み（Internal->DMZ向けTCP80番ポート許可）のルールに脆弱性保護プロファイルを適用します。対象のセキュリティポリシーの名前をクリックします。
アクションタブをクリックして、プロファイル設定の脅威防御のプルダウンから先ほど作成したプロファイルを選択し「OK」をクリックします。
適用されるとプロファイル欄に！マークがつきます。ではコミットしましょう。
4. 動作確認
まずは、Windows2016にRDP接続してブラウザからアクセスしてみます。（DMZのLinuxにはapacheをインストールだけしている状態です）
次にURLの最後に?hoge=../../etc/passwdと追加した状態でアクセスさせます。リセットされた旨の画面が表示されました。
ではログを確認してみましょう。画面上の「MONITOR」タブから画面左の「トラフィック」をクリックするとブラウザアクセス成功時のログが確認できます。
次に同じ画面の「脅威」をクリックすると、下記の通りリセットされているのがわかります。
5. その他
今回は脅威防御プロファイルの簡単な動作について検証してみました。QiitaでのPaloAlto取り扱いは今回が最後の記事となります。今まで5回ほどPaloaltoの内容について取り上げてきましたが、実際の導入では状況に応じた構成の検討やチューニング、その他考慮しなければいけない事など多岐にわたります。また今回のようにAWS上で構成する場合license絡みの作業や、ちょっとしたお作法があったりします。リクエストがあれば別の機会で取り扱ってみたいと思います。