カテゴリー: Front Door

Azure Front Doorのタイムアウト値変更

投稿日: 投稿者: tama-negi

 

Azure Front DoorとApplication Gatewayの構成で試していた所、Application Gatewayのタイムアウト値を60秒に変更しても30秒でタイムアウトになってしまうという事がありました。

      • Application Gatewayのタイムアウト値が30秒以内の場合はApplication Gatewayのタイムアウトエラーが表示される。
      • Application Gatewayのタイムアウト値が30秒より大きい場合はAzure Front Doorのタイムアウトエラーが表示される。

この状態からFront Doorのタイムアウト値も併せて変更が必要というではという事で確認してみました・・・ですがAzure Portal上で確認しても、それらしい設定値はありませんでした。

という事で今回は、Azure Front Doorのタイムアウト値の確認から設定変更までを試してみました。

※なお、Application Gatewayのタイムアウト値はバックエンドに対するタイムアウト値になります。フロントエンド側ではありません。

1.Application Gatewayのバックエンドに対するタイムアウト値設定

Azure Front Doorの前にApplication Gatewayのバックエンドに対するタイムアウト値設定を確認します。こちらはHTTP設定にあります。デフォルト20秒になっています。

2.Azure Front Doorのバックエンドに対するタイムアウト値確認

Azure Front Doorのバックエンドに対するタイムアウト値設定はAzure Portal上では確認できませんでした。Power Shellを使って確認してみました

Get-AzFrontDoorで確認しても見つからなかった為、色々調べていた所BackendPoolsSettingに含まれることが分かりました。こんな感じで確認してみました。

#FrontDoorの設定確認用Power Shell

$frontDoorName = “Front Door名”

$frontDoor = Get-AzFrontDoor -Name $frontDoorName
$frontDoor.BackendPoolsSetting 

実際に確認してみると、以下のように30秒であることが確認出来ました。

EnforceCertificateNameCheck :

SendRecvTimeoutInSeconds : 30
Id :
Name :
Type : 

調べてみた所、SendRecvTimeoutInSecondsがバックエンドに対するタイムアウト値に該当するようです。

3.Azure Front Doorのバックエンドタイムアウト値設定

Azure Front Doorのバックエンドに対するタイムアウト値設定をPower Shellを使ってやってみました。

今回は設定変更前後で値を取得しています。

#FrontDoorのタイムアウト値を変更するPower Shell
$frontDoorName = “Front Door名”

#設定前の値確認
$frontDoorConf = Get-AzFrontDoor -Name $FrontDoorName
$frontDoorConf.BackendPoolsSetting

#設定変更実施
$frontDoorConf.BackendPoolsSetting.SendRecvTimeoutInSeconds = 120
$frontDoorConf | Set-AzFrontDoor

#設定後の値確認
$frontDoorConfAfter = Get-AzFrontDoor -Name $FrontDoorName
$frontDoorConfAfter.BackendPoolsSetting

実際に設定結果(抜粋)を確認すると、以下の通り設定出来ている事が確認出来ました

#設定前

SendRecvTimeoutInSeconds : 30

#設定後

SendRecvTimeoutInSeconds : 120

実際にアクセスして試してみた所、Front Doorタイムアウトが表示されなくなり、設定がうまく出来ている事が確認出来ました。

Azure Front Doorのバックエンド正常性監視はこちらで試しております。

Azure Front Doorのバックエンド正常性監視

Azure Front Doorのルールエンジンを試してみた

投稿日: 投稿者: tama-negi

 

Azure Front Doorにルールエンジンと言う機能があります。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-rules-engine

こちらの機能の詳細はマイクロソフト様のサイトに記載の通り、Front Doorからバックエンドに送る前にどう処理をするかを規定するものになります。

以前であればルーティング規則でやる必要があったような内容もルールエンジンで実現出来ます。とくりにルーティング規則は課金が発生する為ルールエンジンに置き換える事でコスト削減も期待が出来ます。

具体的には、HTTP→HTTPへのリダイレクトや画像等の特定のパスへのアクセスのみをキャッシュする等の制御が可能になります。

今回は、HTTPからHTTPSへのリダイレクトとサブドメイン無しURLをサブドメイン付URLへリダイレクトをルールエンジンを使って試してみました。

      • ルール エンジンの構成で新規ルールエンジンを作成
        • HTTP→HTTPSへのリダイレクトルールを作成する
        • サブドメイン無しURLをサブドメイン付きURLへリダイレクトする
      • 作成したルールエンジンをルーティング規則を割り当てる

サブドメインのリダイレクトについてはAzureDNSの設定も必要になります。

ルーティング規則での実装は下記記事に記載しております。こちらも併せて参考にして頂ければと。

Azure Front DoorでHTTPからHTTPSへリダイレクトする

Azure Front Door＋Azure DNSでサブドメインのリダイレクト

1.Azure Front DoorのルールエンジンでHTTP→HTTPSへリダイレクトするルールを作成する

Azure Front Doorのメニューにルールエンジンの構成を選択すると下記画面が表示されますので追加を選択します。

ルールエンジンの構成画面が表示されます。設定内容は条件とアクションの2つになります。

      • 条件の追加(HTTPでアクセスが来た場合)
      • アクションの追加(HTTPSへリダイレクトする)

ルールエンジンの構成を設定します。

今回HTTPからHTTPSへリダイレクトさせる為に設定した内容は下記内容になります。(それ以外はデフォルト値になります。)

    • ルールエンジン
      • ルールエンジン名：rulesengine01
    • ルール(条件)
      • ルール名：rule01
      • 条件：要求プロトコル
      • 演算子：次の値と等しい
      • 要求プロトコル：HTTP
    • ルール(アクション)
      • アクション：ルーティングの構成
      • ルートの種類：リダイレクト
      • リダイレクトの種類：Moved(301)
      • プロトコルをリダイレクトします：HTTPSのみ

設定が終わったら保存します。

2.Azure Front DoorのルールエンジンでWWW無しアクセスをWWW付へリダイレクトさせるルール作成する

ルールエンジンの構成を設定します。今回サブドメイン無しからサブドメイン付きへリダイレクトさせる為に設定した内容は下記内容になります。(それ以外はデフォルト値になります。)

    • ルールエンジン
      • ルールエンジン名：rulesengine01
    • ルール(条件)
      • ルール名：rule02
      • 条件：要求URL
      • 演算子：リダイレクト前のURL(https://xxx.com)
    • ルール(アクション)
      • アクション：ルーティングの構成
      • ルートの種類：リダイレクト
      • リダイレクトの種類：Moved(301)
      • 送信ホスト：置換
      • 宛先ホストを置換します：リダイレクト後のURL(https://www.xxx.com)

設定が終わったら保存します。

3.ルールエンジンはすべてのルールを処理します

ルールエンジンですが設定されているルールをすべて処理します。

ですので、今回のルールを両方設定すると、http://xxx.com→https://www.xxx.comへのリダイレクトが出来ます。

それ以降のルールの実行を止める場合は、残りのルールの評価を停止するにチェックを入れます。

Azure Front Doorのバックエンド正常性監視

投稿日: 投稿者: tama-negi

 

Azure Front Doorのバックエンド状態（正常に応答しているかどうか）の確認をしてみました。

また、Azure  Monitorの機能を利用してバックエンドの状態が異常な場合に検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で出来ます。

Application Gatewayの正常性プローブの監視についてはこちらに記載しております。

Azure MonitorでApplication Gateway正常性プローブを監視

1.Azure Front Doorのメトリックで正常性プローブの応答率がわかる

マイクロソフト様のサイトを確認するとAzure Front Doorのメトリックで、バックエンドへの正常性プローブの応答率がわかるようです。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

※マイクロソフト様のサイトでは、バックエンドの正常性の割合と記載されています。

実際にAzure Portal上で確認してみました。

メニューのメトリックを選択すると、下記画面が表示されます。ここでBackend Health Percentageを選択するとバックエンドプール全体での応答率(正常な割合)が表示されます。

応答率になるので、バックエンドプールに所属するバックエンドがすべて正常な場合は100％になります。

※バックエンド落としてないにも関わらず、なぜか100％になってなかったりするので、この編は調査が必要かも。という感じです。

バックエンドホスト単位で確認するには、フィルターの追加を使います。

フィルターの追加を選択すると、BackendとBackend Poolが表示されますので、Backendを選択します。そうすると、値の部分に設定しているバックエンドホスト名が表示されます。確認したいバックエンドのホスト名を選択します。

選択するとバックエンドホスト単位での応答率が確認できました。

ここの数値が低い場合は、バックエンドホストがAzure Front Doorの正常性プローブに応答を返せてないという状態になります。

Azure Front Doorのタイムアウト値確認変更についても試しております。

Azure Front Doorのタイムアウト値変更

－－－

2.Azure Front Doorのバックエンドが正常かAzure Monitorで監視する

Azure MonitorでAzure Front DoorのBackend Health Percentageをメトリック監視する事が出来ます。

まず、Azure Front Doorのメニューで、警告を選択します。表示された画面で新しいアラートルールを選択します。

そうすると、アラートルールの作成画面が表示されます。

スコープはすでにFrontDoorが選択されています。(Azure Monitorから設定を行った場合はスコープで今回設定するFront Doorを選択します。)

条件を選択します。

   シグナルロジックの構成画面が表示されますので、Backend Health Percentageを選択します。

そうするとシグナルロジックの構成画面が表示されます。ここで実際の設定を行います。

      • ディメンション：バックエンドホスト、バックエンドプールすべて監視する
      • アラートロジック：しきい値(平均)が95％より小さい場合はアラートを発生させる
      • 評価基準：15分単位での確認とする

上記のような設定の場合は、下記のような画面になります。

バックエンドホスト単位、バックエンドプール全体の状態どれを監視するかを選択します。

個別に設定可否を判断する場合は、ディメンションで対象を選択します。すべてを選択する場合は、選択にチェックを入れるとすべての項目が選択されます。

※注意点ですが、選択にチェックを入れるとAzure Front Door側でバックエンドやバックエンドホストを追加すると自動的に監視項目にも追加になります。

何％以下（より小さい）というしきい値を設定すると、バックエンドホスト側へのアクセスに問題がある場合、Azure Monitorで検知ができます。

上記設定が終わったら、完了をクリックします。

アクショングループや、名前等を付けて保存すれば、Azure Monitorでの監視設定が完了になります。

3.Azure Monitorで実際に送信されたメール

実際にアラートメールを送信すると、以下のような内容が記載されたメールが送信されます。

Metric nameBackendHealthPercentage
Metric namespacefrontdoors/フロントドア名
DimensionsResourceId = /subscriptions/サブスクリプションID/resourcegroups/リソースグループ名/providers/Microsoft.Network/frontdoors/フロントドア名

ApplicationEndpoint = バックエンドホスト名(1)

ApplicationEndpointPool = バックエンドホスト名(2)

Time AggregationAverage
PeriodOver the last 15 mins
OperatorLessThan
Threshold95
Criterion TypeStaticThresholdCriterion

Azure Front DoorでWEBアクセスの送信元IP制限

投稿日: 投稿者: tama-negi

 

Azure Front DoorのバックエンドプールにApplication Gatewayを使用した場合の送信元IPアクセス制限を試してみました。

Front Door経由のWEBアクセスはすべてAzureFrontDoor.BackendでプールされるIPになります。

その為Application GatewayやWeb Apps等のバックエンド側ではアクセス元IPがわからない為NSGでのアクセス制御が出来ません。Front Doorでのアクセス制御が必要になります。

今回実施した内容は以下の２つになります。

      • NSGでFront DoorからのApplication GatewayへのアクセスをFront Doorのみに制限する
      • Front DoorのWeb Application Firewallポリシーのカスタム規則でIP制限を行う

Azure Front Doorのアクセス制限はNSGの設定で出来ない為、Web Application Firewallポリシーのカスタム規則で実施しています。

WAFの構築についてはこちらで試しております。併せて見て頂ければと。

Azure Web アプリケーションファイアウォールを作ってみた

1.Application GatewayサブネットのNSGでFront Doorからのアクセスのみに制限する

最初にApplication GatewayへのアクセスをFront Doorからのみ制限します。

Application Gatewayのサブネットに適用しているNetwork Security Groupの受信規則でService TagがAzureFrontDoor.Backendの許可設定を追加します。

      • ソース：Service Tag
      • ソースサービスタグ：AzureFrontDoor.Backend
      • ソースポート範囲；*(Any)
      • 宛先：VirtualNetwork
      • 宛先ポート範囲：80、443
      • プロトコル：TCP
      • アクション：許可

次にFrontDoorからのアクセス許可より優先順位が下に、InterNetからのアクセス拒否ポリシーを設定します。

  • ソース：Service Tag
  • ソースサービスタグ：InterNet
  • ソースポート範囲；*(Any)
  • 宛先：VirtualNetwork
  • 宛先ポート範囲：80、443
  • プロトコル：TCP
  • アクション：拒否

この2つのルールにより、Application GatewayではInternetから来るWEBアクセスが拒否されFront Door経由のアクセスのみが許可されます。

Application Gatewayのドメインへのアクセスを実施すると、このサイトにアクセスできませんというメッセージが表示されます。

2.Web Application Firewallポリシーのカスタム規則でIP制限を行う

Front Door側でアクセス元IPを制限する場合、NSGではできず、WAFのカスタム規則を利用します。

今回は、特定のIPからのアクセスのみを許可します。

    • Web Application Firewallのポリシーを防止にする
    • 特定のIPを含まない場合はトラフィックを拒否する設定をする

※防止にすると必要なアクセスがブロックされる場合もありますので注意して下さい。

Web アプリケーション ファイアウォールのポリシーのメニューで設定の中にあるポリシー設定を選択すると下記画面が表示されます。

モードで防止を選択し保存します。

次に設定にあるカスタム規則を選択します。

カスタムルースの追加を選択すると条件設定の画面が表示されますので、以下の通り設定します。

      • 一致の種類：IPアドレス
      • 一致変数　RemoteAddr
      • 操作：次の値を含まない
      • IPアドレスまたは範囲：許可するIP
      • 結果　トラフィックを拒否する

最後にカスタム規則の保存を行えば、作業が完了です。

これで特定のIPからのみアクセスが許可され、それ以外のアクセスはブロックされます。

Azure Front Doorのキャッシュ期間が指定出来るようになったようです

投稿日: 投稿者: tama-negi

 

Azure Froot Doorのキャッシュ期間が指定できるようになったようです。

下記マイクロソフト様サイトに記載がある通り、今まではランダムとなり指定できませんでした。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-caching

しかし、本日（2020年5月2日）にAzure Portal上で確認した所、キャッシュ期間という項目が追加になっていました。

いつの間にという感じなのですが、キャッシュ期間は最大365日を超える事が出来ませんとの記載がありましたので、最大1年という事のようです。（実際に入力時点の最大値は365日まででした。）

実際に設定してみた所、x-cache: TCP-HITとなったのでキャッシュ自体は有効になっているのが確認できたのですが、設定時間を経過しても同じ結果だったので、期間が有効な状況なのかはもう少し確認が必要でした。

キャッシュの更新についてはこちらを参考にして頂ければと。

Azure Front Doorのキャッシュを更新する

※Front Doorデザイナー＞ルーティング規則でキャッシュを有効化にするとこのメニューが表示されます。

Azure Front Door＋Azure DNSでサブドメインのリダイレクト

投稿日: 投稿者: tama-negi

 

サブドメイン無しURL(xxx.com)からサブドメインURL（www.xxx.com)へのリダイレクトをAzure Front DoorとAzure DNSの組み合わせで試してみました。xxxの部分は自分の環境に合わせて読み替えてください。

Azure DNSでAzure Front Dooorのエイリアス登録、Azure　Froot Doorでリダイレクトさせる事によりWWW無しURLからWWW付URLへリダイレクトさせています。

今回の検証で実施した作業は、以下の3つになります。

      • Azure　DNSで、@（xxx.com)のAレコードを作成する。
      • Azure　Froot Doorでxxx.comのフロントエンドを作成する。
      • Azure　Froot Doorルーティング規則でリダイレクトの設定を作成

※www.xxx.comの設定がすべて完了している前提とします。

1.Azure DNSで＠(サブドメイン無し)のAレコードを作成する。

Azure DNSでxxx.comのレコードを作成します。xxx.comのゾーンで作業を実施します。

Azure DNS＞概要＞レコードセットの追加を選択します。

レコードセットの追加の画面が表示されますので下記の通り設定します。

      • 名前：空白
      • 種類：A
      • エイリアスのレコードセット：はい
      • エイリアスの種類：Azureリソース
      • Azure　リソース：該当のFroot Doorを指定

選択し保存します。そうすると、レコードセットが作成されます。

これで、サブドメイン無しURLへアクセスが来た場合、Froot Doorへアクセスするようになります。

2.Azure Front Doorのフロントエンドでカスタムドメイン(xxx.com)を作成する

xxxx.comを受けるフロントエンドを作成します。

フロントドア＞Froot Doorデザイナー＞フロントエンドまたはドメインで＋（追加）を選択します。そうすると以下の画面が表示されます。

こちらで、カスタムホスト名に、xxxx.comを入力し追加すると、xxxx.comのフロントエンドができます。

なお、この時点でDNSのレコード存在チェックが実施されます。

※HTTPSでリダイレクトする場合は、xxx.comの証明書を登録する必要があります。(ブラウザアクセス時に証明書エラーが発生します)

3.Azure Front Doorでサブドメインへリダイレクトさせるルーティング規則を作成する

xxxx.comをwww.xxxx.comにリダイレクトさせるルーティング規則を作成します。

フロントドア＞Froot Doorデザイナー＞ルーティング規則で＋（追加）を選択します。

ルーティング規則追加の画面が表示されますので以下の通り選択します。

      • 名前：適時設定
      • 受け入れ済みのプロトコル：適時設定(リダイレクトするプロトコルを選択します。)
      • フロントエンドまたはドメイン：リダイレクトするURL( xxx.com)
      • ルートの種類：リダイレクト
      • リダイレクトの種類：Moved(301)
      • プロトコルをリダイレクトします：一致要求
      • 送信先ホスト：置換（www.xxxx.comを入力）

プロトコルは一致要求を選択すると、HTTPはHTTPで、HTTPSはHTTPSでリダイレクトしてくれます。

入力したら、追加をクリックします。

最後にフロントドアデザイナーの保存を行い設定が完了です。

保存完了後に、xxxx.comへアクセスしたら、www.xxxx.comにリダイレクトされるようになります。

—-

今回ルーティング規則で作成しておりますが、ルールエンジンでも同様の事が実現可能です。そちらについては下記記事に記載しております。

Azure Front Doorのルールエンジンを試してみた

Azure Front Doorのキャッシュを更新する

投稿日: 投稿者: tama-negi

 

Azure Front Doorにはコンテンツキャッシュの機能があります。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-caching

キャッシュの機能を利用する事により、バックエンドプール側の負荷を下げたり、レスポンスタイムの向上が期待できます。

キャッシュ自体は、アクセスされたURLパスを保持します。同じURLに対して2回目のアクセスからキャッシュが使用される動きとなります。

一方で、Front Door自体はバックエンドプール側のサイト更新を能動的に検知する事はありません。

Front Doorでコンテンツがキャッシュされてしまうと、WEBサーバ側でサイトが更新しても反映されない事態が起こります。

Front Doorでキャッシュを有効にしていた場合、Webサイトの更新に合わせて、FrontDoor側のキャッシュクリアを行う事が必要になります。

今回は、Azure Front Doorのキャッシュクリア方法について確認してみました。

Azure Front Doorのキャッシュ期間についてはこちらの記事も併せて見て頂ければと。

Azure Front Doorのキャッシュ期間が指定出来るようになったようです

1.Azure Froot Doorのキャッシュはクリアだけできる

Azure Front DoorのキャッシュをAzure Portal上で更新する事は出来ません。その為今回はPower Shellを使って実施してみました。

キャッシュを更新するには、以下のようにサイト更新後にキャッシュクリアを行う必要があります。

    1. サイト更新
    2. キャッシュクリア
    3. サイトへのアクセス

Front Doorのキャッシュクリアには、Remove-AzFrontDoorContentコマンドを使用します。

https://docs.microsoft.com/ja-jp/powershell/module/az.frontdoor/Remove-AzFrontDoorContent?view=azps-3.8.0

今回はサンプルで以下のようなPowerShellを作成してみました。（GitHubにも公開しています。）

#Front DoorのキャッシュクリアをするPower Shell

param (
    [String] [Parameter(Mandatory=$true)]  $ResourceGroupName ,
    [String] [Parameter(Mandatory=$true)]  $FrontDoorName ,
    [String] [Parameter(Mandatory=$true)]  $ContentPath
    )

Remove-AzFrontDoorContent -ResourceGroupName $ResourceGroupName -Name $FrontDoorName -ContentPath $ContentPath
| where Category == “FrontdoorWebApplicationFirewallLog”
 

以下のように実行して頂く事で、キャッシュのクリアが可能です。

c:\FrontDoorのキャッシュをクリアする.ps1 -ResourceGroupName “リソースグループ名” -FrontDoorName “フロントドア名” -ContentPath “削除するパス (例：/*)”

サイト更新後に、今回のようなPower Shellを利用してキャッシュクリアする事により、更新したけど反映されないという事が防げるかと思います。

※マイクロソフトサポート様に色々ご教授頂きながら進めさせて頂きました。本当に有難うございます。

フロントドアとWAFのログをLog Analyticsで確認

投稿日: 投稿者: tama-negi

 

Azure Froot Door のアクセスログやWAFログを診断設定でLog Analyticsへ転送しクエリで確認してみました。

Azure Front Doorのログではアクセス先のURL等の情報だけではなくキャッシュのヒットなどの情報も分かります。

WAFのログではどのルールでブロックされたのか？なども分かります。例えばレート制限時にはアクセス制限状況も分かります。

その為、Azure Front Doorの使用状況を把握するのには、診断設定で取得出来るログは非常に重要なログになります。

今回実際に実施した作業内容は下記の通りになります。

      • Azure Front Dorrの診断設定
      • Log Analyticsでのログ検索

設定にあたっては、マイクロソフト様サイトを参考に進めました。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

WAFの作成についてはこちらを参考にして頂ければと。

Azure Web アプリケーションファイアウォールを作ってみた

Application Gatewayのログについてはこちらを参考にして頂ければと。

Azure Application GatewayのアクセスログをLog Analyticsで確認する

1.Azure Froot DoorやWAFのログ取得設定は診断設定で行います

Azure Froot DoorのアクセスログはApplication Gatewayと同様に診断設定を利用します。

Azure Front Doorのメニューで診断設定を選択します。

下記画面が表示されますので診断設定を追加するを選択します。

診断設定の画面が表示されます。

logに表示されている2項目にチェックを入れます。(必要に応じてMetricにもチェックを入れます。)

今回はLog Analyticsで確認するのでLog Analytics への送信にチェックを入れて、送信先のワークスペース名を選択します。

診断設定の名前を付けて保存します。

※FrontdoorWebApplicationFirewallLogはFroot DoorでWeb Application Firewallの設定を行っている場合のみ出力されます。

2.Log AnalyticsでAzure Front DoorやWAFログの検索を行う。

診断設定で選択したLog Analyticsのワークスペースでログを開きます。(Azure Front Doorのメニューでログを選択しても同じ動作になります。)

今回取得設定したのは以下の2つのログになります。

      • FrontdoorAccessLog：Azure Front Doorのアクセスログ
      • FrontdoorWebApplicationFirewallLog：WAFのログ

アクセスログを表示する為のサンプルは下記の通りになります。

#アクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
 
#アクセスログをアクセス元のIPでカウントする。（アクセス数順で並び変える。）

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
| summarize total_hits = count() by clientIp_s
| sort by total_hits desc
 

FrontdoorAccessLogの主な出力項目としてはこんな内容が表示されます。

      • 時刻
      • リクエストURL
      • User-Agent
      • アクセス元のIP
      • キャッシュヒット
      • ルールエンジン(利用時)

Web Application Firewallのログは下記のクエリで確認可能です。

#Web Application Firewallのログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
 

アクセスログに表示される項目以外に、どのルールにマッチしたのか、ブロックされたのか等の情報が併せて表示されます。

なお許可された通信も表示されます。許可された通信以外(LogやBlock)を表示するには下記のようにします。

#Allow以外のアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s != “Allow”
 

Web Application FirewallでBlockされたログのみの場合は以下のようなクエリを利用します。

#Web Application FirewallでBlockされたアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s == “Block”
 

実行結果を確認するとどのルールでBlockされたのかもわかります。

3.Azure Froot Doorのバックエンドプール側のクライアントIPはFront DoorのIPになります。

Froot Doorを使う場合ですが、バックエンドプール側のアクセスログに表示されるclientIP_sがFroot DoorのBackend poolのIPアドレスになります。

その為、バックエンドプール側（Virtual Machine等）でアクセス元IPを確認する場合は、x-forwarded-forを確認する必要があります。

また、マイクロソフト様のサイトにも記載がありますが、Froot Doorからのヘルスチェックアクセスが結構な数のアクセスが来るので、アクセスログが大量になる事にも注意が必要です。

【参考】Web Application Firewallの作成は下記に記載しています。

 https://www.tama-negi.com/2020/05/10/azure-web-application-firewall/ ‎

Azure Front DoorでHTTPからHTTPSへリダイレクトする

投稿日: 投稿者: tama-negi

 

HTTPからHTTPSへのリダイレクトをAzure Front Doorのルーティング規則での実施を試してみました。

今回実施したのは主に以下の内容になります。

      • Azure Front DoorでHTTPS用のルーティング規則を作成
      • Azure Front DoorでHTTP用のルーティング規則を作成
      • HTTP用のルーティング規則内でHTTPSへリダイレクトさせる

1.Azure Front DoorのHTTPS用ルーティング規則を作成する

まずHTTPS用のルーティング規則を作成します。

Azure Portal上で、Azure Front DoorのFront Doorデザイナーのメニューをクリックします。

デザイナーが表示されますので、その中でルーティング規則で＋をクリックし、ルーティング規則を追加します。

受け入れ済みのプロトコルをHTTPSで設定とます。フロントエンドまたはドメインは受信するドメインを選択します。

ルートの種類は、進むを選択し、バックエンドプールは転送先のバックエンドを選択します。設定が終われば保存します。

2.Azure Front DoorのHTTP用のルーティング規則を作成しHTTPSへリダイレクト設定する

次にHTTP用のルーティング規則を作成します。

まず、受け入れ済みのプロトコルをHTTPとします。フロントエンドまたはドメインは受信するドメインを選択します。

次に、ルートの種類で、リダイレクトを選択します。併せて、転送プロトコルをHTTPSのみを選択します。

この転送プロトコルの設定でHTTPSへのリダイレクトを実現します。

なおリダイレクトの種類はMoved(301)を適用します。

設定を保存した後に、Front Doorデザイナーの方でも保存します。

－－－－

今回実施したHTTP→HTTPSへのリダイレクトはルールエンジンでも実現可能です。こちらについては下記記事に記載しておりますので併せて見て頂ければと。

Azure Front Doorのルールエンジンを試してみた

Azure Web アプリケーション ファイアウォールのカスタム規則設定をしてみた（国別ブロック）

投稿日: 投稿者: tama-negi

 

Azure WEBアプリケーションファイアウォール（WAF）で国別ブロックの設定を試してみました。

Azure WEBアプリケーションファイアウォール（WAF）ではカスタム規則の作成が可能です。このカスタム規則で、国別ブロックや特定のIPからのアクセスについてブロックする等の設定ができます。これはApplication Gateway（V1）のWAFでは設定出来ない内容でした。

また、Azure WEBアプリケーションファイアウォール（WAF）は単体利用ではなく、Azure Front Door等組み合わせて利用します。

マイクロソフト様サイトに記載の内容を参考に設定を行っています。

https://docs.microsoft.com/ja-jp/azure/web-application-firewall/afds/waf-front-door-create-portal

今回試してみた、国別ブロックは、カスタムルールで非常に簡単に実現できます。

※WAFで実現できる設定内容は、Application GatewayかFrontDoor（今回）の選択によって異なるようです。

1 .Azure WEBアプリケーションファイアウォールのカスタム規則を作成

WAFの画面で、カスタム規則を選択すると下記画面が表示されます。
カスタムルールの追加をクリックします。

そうるすと、カスタムルールの追加が表示されます。
一致の種類に、geoロケーションを選択すると国コードが表示されます。
国コードを選択すると、プルダウンで国が表示されるので、それを選択するだけです。
1つのカスタムルールで選択できるのは10までになります。

今回は特定の国だけをブロックしたいので、操作は次である（合致するという意味）、結果はトラフィックを拒否するを選択します。
カスタムルール名、優先度を設定し、追加ボタンをクリックすればカスタムルールが出来上がります。

最後に、カスタム規則の画面の保存ボタンをクリックすれば新たに作成したカスタムルールが適用されます。これ押し忘れると、作成したカスタムルールは適用も保存もされません。

Azure Web アプリケーションファイアウォールの作成手順は下記に記載してみました。

hhttps://www.tama-negi.com/2020/05/10/azure-web-application-firewall/

Azure Web アプリケーションファイアウォールを作ってみた

——–