title | emoji | type | topics | published | published_at | |||
---|---|---|---|---|---|---|---|---|
Azure Front DoorのWAFとAzure Application GatewayのWAF |
🧇 |
tech |
|
true |
2022-11-02 11:07 |
- どっちもWAFあるけど何が違うんだっけ
- 触ってみよう
- 直近で消えるサブスク上で検証してるのでメモ書き程度
- AFDのWAFとAppGWのWAFは効く場所が異なる
- AFDの場合はAzure外部のエッジに入るタイミング
- AppGWの場合はAzure内部かつAppGWのデプロイされたVNETに入ろうとするタイミング
- WAFポリシーは使いまわせるんだっけ?レベルの知識
- 結論、別物
- Premium用のWAFポリシーを利用したいのでセキュリティ最適化のPremium SKUとする
- WAFポリシーを作成
- Azure Front Door Premium用にWAFポリシーを作成すると、マネージドなルールが既定で有効化されている
- デフォルトでは、WAFポリシーは検出モード
- 実際にアクセスのブロックのテスト等を行いたい場合には「防止モード」にする
- WAFポリシーのカスタムルールとして、「geoロケーション」の「日本」からのアクセスをブロックするルールを作成
- Front Doorの背後にWebAppsを配置して自宅PCからアクセスしてみたが、ブロックされなかった
- ブラウザキャッシュか?と思ってキャッシュ削除やプライベートウィンドウを試したがブロックされず。。
- AFD側のキャッシュかも?と思って「キャッシュの消去」を実施したところ、想定通りブロックされた
- WAFポリシーのカスタムメッセージが文字化けして表示された
- こっちのWAFにはデフォルトでマネージドなルールセットが有効化されている
- リージョン内のリソースであり取得できる情報もAFDと異なるので当然だが、カスタムルールで利用できる設定項目も微妙に異なる
- 「geoロケーション」で「日本」からのアクセスをブロックするルールを作成
- Application Gatewayを作成する
- VNETにデプロイするサービスなのでそれらも適当に作成
- バックエンドプールもとりあえず空で作成
- リスナーとか諸々デフォルトで作成
- WAFポリシーを連携
-
バックエンドプールが空の状態でとりあえずアクセスしてみたら502エラーが返ってきた
- これはメンテナンスメッセージで正常な動き
- 利用可能なバックエンドがない場合に出るメッセージらしい
-
ので、UbuntuにApache入れてバックエンドプールに追加
-
その状態でApplication Gatewayへアクセスすると403エラーが返ってきた
- WAFポリシーの適用によって未承認のアクセスとして認識された
次の 2 つのシナリオのカスタム エラー ページがサポートされています。 メンテナンス ページ - 502 無効なゲートウェイ ページの代わりに、このカスタム エラー ページを送信します。 これは、Application Gateway にトラフィックをルーティングするバックエンドがないときに表示されます。 たとえば、予定メンテナンスがある場合、または予期しない問題がバックエンド プール アクセスに影響する場合です。 未承認のアクセス ページ - 403 未承認のアクセス ページの代わりに、このカスタム エラー ページを送信します。 これは、Application Gateway WAF が悪意のあるトラフィックを検出し、そのトラフィックをブロックするときに表示されます。
https://learn.microsoft.com/ja-jp/azure/application-gateway/custom-error
- カスタムエラーメッセージを出してみたくなり、上記リンクの手順に従って設定してみた
- リスナーの設定から502/403エラーの場合のリダイレクト先を設定できる
- 適当にBLOBストレージにhtmlファイルを置いて参照させる
- 本来はRBACとかでやるのかもしれないが、今回はBLOB側をanonymousに許可
- Application GatewayのパブリックIPにhttpアクセスすると下図のように表示された
Azure Front DoorとApplication Gatewayで迷ったときのために違いを確認する意味で検証してみました。もっと色々触ってみないと、という感じです。