送信元IPアクセス制限をAzure Front Door+Azure Application Gatewayでやってみた

 

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

実際に実施した内容は以下の2つになります。

    • Application GatewayサブネットのNetwork Security GroupでFront Doorからのアクセスのみに制限する
    • Front DoorのWeb Application Firewallポリシーのカスタム規則でIP制限を行う

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

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

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

実際の設定画面は下記のようになります。

その次に、上記許可ポリシーより優先順位が下に、Service TagがInternetからポート80,443のアクセス拒否するポリシーを入れます。

これにより、直接Internetから来るアクセスが拒否され、Front Door経由のアクセスのみが許可されます。

直接、Application Gatewayのドメインへのアクセスを実施すると、このサイトにアクセスできませんというメッセージが表示されます。また、Front Door経由のアクセスをすれば正常にサイトアクセスできます。

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

Front Door経由のアクセスはすべてAzureFrontDoor.BackendでプールされるIPになります。したがって、Application Gateway側ではアクセス元IPがわからない為、Network Security Groupでの設定が出来ません。

Front Door側で同様の制限を行う必要がありますが、Front Doorのアクセス制限はNetwork Security Groupの設定での制限ができません。

結果、Front Doorに設定されているWeb Application Firewallポリシーのカスタム規則でIP制限を行う事になりました。

特定のIPからのアクセスのみを許可する場合は、以下の設定になります。

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

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

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

設定で防止を選択し保存します。

次に、設定にあるカスタム規則を選択します。カスタムルースの追加を選択するとカスタムルールの追加が表示されます。

 

カスタムルール名、優先度を適時設定した後に、条件を下記設定とします。

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

これで許可するIPアドレス以外のアクセスをすべて拒否する設定が出来ました。

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

 

Azure Monitorを使ってAzure Application Gateway正常性プローブのステータス変化を検知する

 

Azure Application Gatewayのバックエンド正常性の状態変化を検知する検証を行ってみました。

今回は、Azure  Monitorの機能を利用して検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で可能です。

1.Application Gatewayのメトリックで正常性プローブの状況がわかる

Application Gatewayのメトリックでは、正常なホストの数、異常なホストの数を検知する事ができます。これはV1、V2どちらでも可能です。
このホストの数は、正常性プローブによって正常もしくは異常と判断されたバックエンドの数になります。マイクロソフト様のサイトに記載があります。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-metrics#backend-metrics

マイクロソフト様のサイトを読むと、以下のような事が言えます。

    • 正常なホストの数が0の場合は、すべてのバックエンドプールに問題が発生しており、サイトが表示されない状態
    • 異常なホストの数が1以上の場合は、1つ以上のバックエンドプールで異常が発生している状態(特定のバックエンドにあるホストが停止している状態

したがって、この状態を監視することにより、Application Gateway経由のバックエンド正常性がわかるのではないかと考えてみました。

2.すべての正常性プローブがNGになった場合に検知する

Azure MonitorでApplication Gatewayのメトリックを監視することができます。

まず、モニター>アラート>新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、リソースの選択でアプリケーションゲートウェイを選択します。

    選択が終わったら、完了を押します。

ルールの作成画面に戻りますので、次に条件の項目で追加を選択してください。

そうすると、下記のようにシグナルロジックの構成が表示されます。

ここに項目が表示されるのですが、今回対象とする項目は下記2つになります。

    • Unhealthy Host Count が異常なホストの数になります
    • Healthy Host Count が正常なホストの数になります

すべて正常性プローブがNGになった場合の検出は正常なホストの数で設定をします。

Healthy Host Countを選択をすると下記のような画面が表示されます。バックエンドのサーバが1つ(ルールもHTTP用1つ)で検証していますので、以下のように1となります。

これが、0になると、正常なバックエンドがなくなる為、すべてのアクセスが停止する状態になります。ですので以下のような設定とします。

    • しきい値:Static
    • 演算子:より小さい
    • 集計の種類:平均
    • しきい値(演算子の方):1

1より小さいとなりますので、バックエンド正常性がNGだった場合(一時的な状態を含む)が検出される事になります。

評価基準は適時選択してください。最後に完了ボタンを選択します。

ルールの作成画面に戻りますので、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性がすべてNGになった場合に、アラートを発生させることができます。

3.1つでも正常性プローブに異常があった場合に検知する

1つ以上の正常性プローブがNGになった場合の検出は異常なホスト数で行います。

シグナルロジックの構成で、Unhealthy Host Countを選択します。

そうすると、下記画面が表示されます。

すべてのバックエンド正常性がOKなので、0になります。

これが0より大きい場合は、バックエンド正常性に問題が発生している事を示します。ですので、下記のように設定にします。

    • しきい値:Static
    • 演算子:より大きい
    • 集計の種類:平均
    • しきい値(演算子):0

評価基準は適時選択し完了ボタンを選択します。

ルールの作成画面に戻りますので、同様に、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性で1つでもNGになっている場合に、アラートを発生させることができます。

 

Azure Front DoorやWeb Application Firewallのログを取得してLog Analyticsで確認してみた

 

Azure Froot Doorのアクセスログ取得設定およびLog AnalyticsでアクセスログやWeb Application Firewall(Froot Doorに設定した場合)のログ確認をしてみました。

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

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

1.Azure Froot DoorやWeb Application Firewallのログを取得するのは診断設定

Azure Froot Doorのアクセスログは、診断設定を利用します。これはApplication Gatewayと同じ方法になります。

診断設定を選択すると下記画面が表示されますので、logとmetricにチェックを入れます。今回はLog Analyticsで確認するので、Log Analytics への送信にチェックを入れて、送信先のワークスペース名を指定します。

選択が終わったら、診断設定の名前を付けて保存します。

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

2.Log Analyticsでログの検索を行う。

Froot Doorのメニューの中に、ログという項目があります。この項目を選択すると、診断設定で選択したLog Analyticsのワークスペースが開かれます。

FrontdoorAccessLogがアクセスログになります。以下のようなクエリを利用する事でアクセスログが表示されます。

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

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

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

Web Application Firewallのログは、FrontdoorWebApplicationFirewallLogになります。

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

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
 

上記検索だとAllowされたLogも表示される為、許可された通信を含むすべてのアクセスログが表示されます。Allow以外のログについては以下のようなクエリで検索可能です。

#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.Froot Doorのバックエンドプール側のアクセスログについては注意が必要

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 Application GatewayのARMテンプレートをPower Shell使ってエクスポートする

 

検証でAzure Application Gatewayの設定を行っていたのですが、設定項目が多く、いろいろな所の設定変更していくと、どこを変更した分からなくなる事が多々ありました。恥ずかしながらその結果、元に戻せてなくて設定がうまく行かないケースがありました。

Azure PortalでARMテンプレートのエクスポートするようにしたのですが、何度も繰り返しているのが面倒になってきたので、Power Shellでエクスポートをという事を試してみました。併せてGet-AzApplicationGatewayで設定情報を取得も実施してみました。

実施にあたっては以下のサイトを参考に進めました。

https://docs.microsoft.com/en-us/powershell/module/az.resources/export-azresourcegroup?view=azps-3.8.0
https://docs.microsoft.com/en-us/powershell/module/az.network/get-azapplicationgatewayhttplistener?view=azps-3.8.0

今回作成したものは GitHub上に公開しています。

https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/ApllicationGateway-Template-Export-20200422

1.Azure Application Gatewayのテンプレートエクスポート+情報取得

今回は、Get-AzApplicationGateway でApplication Gatewayの情報を取得しています。

また、Export-AzResourceGroupで、テンプレートのエクスポートを行います。Application Gateway名を指定することで、Application Gatewayのみのテンプレートをエクスポートします。

#Application Gateway Template Export

#取得するApplication Gatewayのパラメータ

$SubscriptionId = “サブスクリプションID”
$RG = “リソースグループ名”
$APGW = “Application Gateway名”
$TemplatePath =“テンプレートのパス(例:C:\temp)”

#Getコマンドで情報取得
Get-AzApplicationGateway -Name $APGW -ResourceGroupName $RG

#テンプレートをエクスポートする
Export-AzResourceGroup `
-ResourceGroupName $RG `
-Resource “/subscriptions/$SubscriptionId/resourceGroups/$RG/providers/Microsoft.Network/applicationGateways/$APGW”`
-Path $TemplatePath

 

なお、上記サンプルのように、Get-AzApplicationGatewayだけでそのまま情報を取得した場合、子に入っているSKUの情報等が取得出来ません。適時必要に応じて表示するようにして下さい。注意願います。

Azure Application Gatewayで特定のパスに来たアクセスを特定のVirtual Machineに振り分ける

 

管理画面へのアクセス等、特定のパスへアクセスを特定のバックエンド(Virtual MachineやWeb Apps)へ振り分けたいという事があるかと思います。今回は、Application Gatewayの設定で試してみました。

設定が必要な内容は、以下の2点になります。

1)バックエンドプールを作成する。
2)パス ベースの規則を追加する。

今回は、2台構成(VM1、2)で、以下のようにadminというパスに来たアクセスはVM1に、それ以外のアクセスは、2台(VM1、2)で受信するような構成を想定します。

http://www.xxxx.com/admin/

※Application Gatewayは作成済みである前提になります。

1 .バックエンドプールを作成する

特定のパスに来たアクセスを受信するバックエンドプールを作成します。
Application Gateway→バックエンドプールで、+追加を選択すると下記画面が表示されます。
ここで特定のパスへ来たアクセスを受信する仮想マシン(今回の場合はVM1)を選択します。

選択が終わったら、名前を入力し保存します。
同様に、すべてのアクセスを受信するバックエンドプールを同様に作成します。(今回のはVM1、2を選択します。)

下記のように2つのバックエンドプールが作成されます。以下の画面は2台構成のパターンで特定のパスへのアクセスを振り分けるサーバを1台にしているので、対象サーバ数が2と1となっています。(ルールはすでに設定済みなので、下記数字になっています。ルール設定前ではゼロになります。)

.パス ベースの規則を追加する

ルールを選択すると、Basicとパスベースが表示されますので、パスベースを選択します。
下記画面が表示されますので、名前、リスナーや、規定のHTTP設定を選択します。
既定のバックエンドプールは、すべてのアクセスを受信するバックエンドプールを選択します。

ルールは上から順番に処理されます。特定のパスへの処理を上に設定します。これを間違えると、ルールが有効に機能しません。

上記の通り、設定し保存すると、特定のパスへのアクセスを特定の仮想サーバへのみアクセスさせる事が可能になります。
バックエンドプールに参加させるサーバを変えることで、/aaa/へ来たアクセスはVM1のみ、/bbb/へ来たアクセスはVM2のみににアクセスさせる等のような事も簡単にできます。

※マイクロソフトサポート様に色々ご教授頂き、何とか設定できるようになりました。いつも本当に有難うございます。

Azure Application Gatewayのエラーページを更新するPower Shell

 

Application Gatewayでシステムメンテナンス等でPoolメンバーの仮想マシンを全部停止した場合は、デフォルトの502エラーページが表示されます。
システムメンテナンスを案内する場合には、Listenerに502エラーや403エラーページを設定することで、Application Gatewayの機能でカスタムエラーページの表示が可能になります。
エラーページは、Blobストレージのパス等固定のURLを指定する事で設定できます。

今回は、システムメンテナンス等で定時にファイル更新するケースがあったので、Power Shellでカスタムエラーページの設定を更新できるようにしてみました。

前回の記事にも記載した通り、Application  Gatewayのキャッシュに保存されるため、更新にはファイル名の変更が必要になります。

Azure Application Gatewayの起動、停止をPower Shellでやってみた

1 .BlobストレージにファイルをアップロードするPower Shell

まず、事前にエラーページのHTMLファイルをBlobストレージにしておきます。以下のページを参考にPower Shellを作成しています。

https://docs.microsoft.com/en-us/powershell/module/az.storage/set-azstorageblobcontent?view=azps-3.3.0

※Content Typeを指定しないと、ファイルとしてアップロードはできますが、エラーページとして表示出来ないので注意が必要です。

# Blobストレージにファイルをuploadする
# 参考URL
# https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-quickstart-blobs-powershell#upload-blobs-to-the-container

# パラメータ
$resourceGroupName = “ストレージアカウントのRG名”
$StorageAccountName = “ストレージアカウント名”
$containerName = “コンテナ名”
$LocalFilePath = “アップロードするファイルパス”

# 処理部分
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $StorageAccountName
$ctx = $storageAccount.Context

Set-AzStorageBlobContent -File $LocalFilePath `
-Container $containerName `
-Properties @{“ContentType” = “text/html”} `
-Context $ctx

.Azure Application Gatewayのエラーページを更新するPower Shell

以下のページを参考に更新するPower Shellを作成しています。

https://docs.microsoft.com/ja-jp/powershell/module/az.network/set-azapplicationgatewayhttplistenercustomerror?view=azps-3.3.0&viewFallbackFrom=azps-2.4.0

# APGW Custom error Page Update
# 参考URL
# https://docs.microsoft.com/ja-jp/powershell/module/az.network/set-azapplicationgatewayhttplistenercustomerror?view=azps-3.3.0&viewFallbackFrom=azps-2.4.0

#パラメータ
$resourceGroupName = “Application GatewayのRG名”
$APGWName =“Application Gateway名”
$ListenerName = “リスナー名”
$StatusCode = “更新対象のエラーコード(ex;HttpStatus403)”
$customErrorUrl = “ErrorページのURL(ex;https://Blobストレージ名.blob.core.windows.net/コンテナ名/ファイル名)”

#処理部分
$AppGw = Get-AzApplicationGateway -Name $APGWName -ResourceGroupName $resourceGroupName
$httplistner = Get-AzApplicationGatewayHttpListener -Name $ListenerName -ApplicationGateway $Appgw
$updatelistener = Set-AzApplicationGatewayHttpListenerCustomError -HttpListener $httplistner -StatusCode $StatusCode -CustomErrorPageUrl $customErrorUrl
Set-AzApplicationGateway -ApplicationGateway $AppGw

※マイクロソフトサポート様に指摘/修正頂き完成しています。本当にありがとうございます。

.留意点

エラーページを設定している、URLのパス名やファイル名が更新された場合は、Application Gatewayを再起動しなくても反映されます。
同じファイル名でメンテナンス画面をアップするような方法ですと、Application Gatewayの再起動が必要となり停止時間が発生します。
その為、メンテナンス画面の更新は、今回のように事前にBlobストレージにファイルをアップしたうえで、パス名を切り替えるのが一番良さそうです。

Azure Application Gatewayの起動、停止をPower Shellでやってみた

 

Azure Application Gatewayの起動停止を試してみました。Azure Portal上で出来なかった為、Power Shellで実施してみました。

Application Gatewayで403エラーページを更新した際に反映されないという事象がありました。Application Gatewayを停止、起動したら改善するんじゃない?という事で試してみた所うまく行きました。

。。。ですがが、実際にはエラーページの更新は自分のやり方が間違ってました。

Application Gateway側にカスタムエラーページのキャッシュを持っており、これはカスタムエラーページのファイル名(もしくはパス)を変更して保存しない限り更新されないそうです。(公開情報にも記載がありました。)

※なお、Application Gatewayを停止しても、課金は停止しないそうです。

1 .Azure Application Gatewayの停止、起動を行う

マイクロソフトサポート様から教えて頂いたコマンドになります。(有難うございました。)

※本コマンドでの停止、起動には5分ほど掛かります。

#Application Gateway Restart PowerShell

# APGW Parameter

$ResourceGroupName = “Application Gatewayが所属するRG名”
$APGWName = “Application Gateway名”
 
$ag = Get-AzApplicationGateway -Name $APGWName -ResourceGroupName $ResourceGroupName

# APGW Stop

Stop-AzApplicationGateway -ApplicationGateway $ag

# APGW Start

Start-AzApplicationGateway -ApplicationGateway $ag

 

.Azure Application Gateway再起動の重要な注意点

注意点として、V1の場合グローバルIPが動的であるため、Application Gateway再起動により、グローバルIPが変わります。3回ほど実施してみましたが、100%変わりました。
その為DNS登録時は、グローバルIPのFQDNをCNAMEで登録するようにしておいてください。(これが推奨なので通常はそういう設定されているかと思いますが、自分はAレコードで登録していた為、少し焦りました。)

Azure Application GatewayのAccessLogをLog Analyitcsで確認する

Application Gatewayの診断設定で、Access LogをLog Analyticsに転送することにより、Application Gatewayのアクセス内容を確認することが可能です。

1.主にAccessLogで確認できる内容

一般的なLogで取得されるような値は取得可能です。実際に以下の値を取得することができます。

項目名 実際に取得される値  
TimeGenerated 2019-07-14T10:36:57Z  
SourceSystem Azure  
clientIP_s 66.249.XX.XX  
httpMethod_s GET  
requestUri_s /  
userAgent_s Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/75.0.3770.100+Safari/537.36  
httpStatus_d 200  
host_s www.tama-negi.com  

2.設定方法

診断ログは、Application Gateway の設定画面にて有効化します。自分が使用するLog Analytics ワークスペースへの出力、出力対象ログを指定するだけです。

アクセスログの取得を行う場合は、ApplicationGatewayAccessLogにチェックを入れます。

3.アクセスログ出力方法

以下のクエリを実行すると、アクセスログの取得が可能です。デフォルトでは24時間になります。

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”

4.アクセスログをアクセス元IP単位で集計する。

以下のような感じでアクセス元のIPを集計することも可能です。

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”
| summarize total_hits = count() by clientIP_s

 

Azure Application Gateway利用時のApache Access logについて

 

Application Gateway利用時にはバックエンドプール側サーバのログのアクセス元IPが、Application GatewayのローカルIPになります。実IPはX-Forwarded-Forに含まれます。今回はApacheのaccess.logで実IPが表示されるようにしてみました。

1.Application Gateway利用時のログについて

Application Gateway利用時には下記のように、アクセス元IPが、Application GatewayのIPになります。この点は、Azure Load Balancer利用時と挙動が異なります。その為、X-Forwarded-Forの値を使ってアクセス元IPの戻しが必要になります。今回はaccess.logのsyslog化も併せて実施します。

172.21.4.4 – – [16/May/2019:09:54:00 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
172.21.4.5 – – [16/May/2019:09:54:02 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
172.21.4.4 – – [16/May/2019:09:54:13 +0900] “GET /favicon.ico HTTP/1.1” 200 – “http://www.tama-negi.com/” “Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36”
172.21.4.4 – – [16/May/2019:09:54:30 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
172.21.4.5 – – [16/May/2019:09:54:32 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“

2.Apacheの設定変更

Apacheの設定は、httpd.confのLog Formatの変更及び、CustomLog、ErrorLogのsyslog化を行います。Application Gatewayの場合、X-Forwarded-Forにアクセス元のIPが出力されるため、明示的に項目として追加します。

[root@test-vm ~]#cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.`date “+%Y%m%d”`
[root@test-vm ~]#vi  /etc/httpd/conf/httpd.conf

#変更前

ErrorLog “logs/error_log”
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
CustomLog “logs/access_log”

#変更後

  LogFormat “%{X-Forwarded-For}i \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
CustomLog “|/usr/bin/logger -p local6.info -t httpd_access” combined

ErrorLog “|/usr/bin/logger -p local6.info -t httpd_error”

※access log、error log両方local6に出力する設定です。
※Logに出力される日時は、syslog側で付与するので、LogFormatから削除しています。

3.rsyslogファイル作成

rsyslog側の設定を行います。ApacheのLogをlocal6に出力指定したので、local6のファイル出力先を指定します。併せて、messagesの除外にします。

#新規にファイルを作成し、下記を追加する。

[root@test-vm ~]#vi /etc/rsyslog.d/httpd.conf

local6.* /var/log/httpd/access.log

#このままだと、messagesにも表示されてしまうので、rsyslog.confも編集する。

[root@test-vm ~]#cp -p /etc/rsyslog.conf /etc/rsyslog.conf.`date “+%Y%m%d”`

[root@test-vm ~]#vi /etc/rsyslog.conf

#変更前
*.info;mail.none;authpriv.none;cron.none; /var/log/messages

#変更後
*.info;mail.none;authpriv.none;cron.none;local6.none var/log/messages

 

4.Application Gatewayの正常性プローブアクセスをログから除外する

このままだと、Application Gatewayの正常性プローブのアクセスがApacheのアクセスログに表示されてしまいます。ですので、rsyslogのignoreで除外設定を行います。

#新規にファイルを作成し、下記を追加する。

[root@test-vm ~]#vi /etc/rsyslog.d/httpd-logstop.conf

msg, contains, “GET / HTTP/1.1” stop

#※除外の文字列は今回のLogFormatに合わせてます。

 

5.logrotate.dの設定を行う

rsyslog化の設定とともに、Apacheのaccess.logのログローテの設定を行います。設定後、rsyslogおよびhttpdの再起動を行います。

[root@test-vm ~]#cp -p /etc/logrotate.d/httpd /etc/logrotate.d/httpd.`date”+%Y%m%d”`
[root@test-vm ~]#vi  /etc/httpd/conf/httpd.conf

#設定ファイルの中身を下記記載に置き換えます。

/var/log/httpd/access.log {
 daily
 rotate 32
 nocompress
 ifempty
 missingok
 create
 sharedscripts
 postrotate
  /sbin/service httpd graceful > /dev/null 2>/dev/null || true
 endscript
}

#今回は32日保管で、ローテ後圧縮にしています。

[root@test-vm ~]#systemctl restart httpd

[root@test-vm ~]#systemctl restart rsyslog

 

 

6.出力されるログを確認する

設定が完了すると、/var/log/httpd/access.logに、アクセス元のIPが表示されます。

May 27 15:49:39 akbwg-web-01 httpd_access: XXX.XXX.XXX.XXX:XXX “GET /favicon.ico HTTP/1.1” 200 – “http://www.tama-negi.com/2019/05/27/application-gw-01/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36”

 

Azure Application GWの構築について

Azure Portal上でApplication Gatewayの基本的な初期構築する手順を紹介します。注意点としては、Application GatewayのSubnetに対して、NSGの許可設定が必要となります。Apache等で出力されるログについても設定が必要になりますが、これは次回以降に記載します。

1.Application Gatewayの作成

簡単に作成は可能なのですが、ポイントとしては、Application Gateway専用サブネットが必要になるのと、Public IPが動的(V1の場合)にする必要があります。

今回は外部公開するサイト(HTTP)を想定したテスト用設定にしています。

設定項目 設定値 備考
名前 test-ap-gw 適時命名してください。
レベル Standard  
インスタンス数 2  
SKUサイズ S  
サブスクリプション 配置するサブスクリプションを選択します。  
リソースグループ 配置するリソースグループを選択します。  
場所 東日本 適時環境に合わせて選択します。

 

設定項目 設定値 備考
仮想ネットワーク 適時選択します  
サブネット 適時選択します  
IPアドレスの種類 パブリック  
パブリックIPアドレス test-ap-gw-ip 今回は新規作成にしてます。
プロトコル HTTP  
ポート 80  
HTTP2 利用しない  

上記設定を入れて問題なければ、確認と作成画面で、作成をクリックし作成します。

2.Application Gatewayの設定(概要説明)

Application Gateway自体デフォルトで設定が入っていますがこれは利用しないようにしましょう。Application Gatewayを複数作成する場合や各設定を複数作成し継続利用するとなると、システム管理上面倒になります。今回はすべて新規作成して利用します。Application Gateway利用までには下記項目について設定する必要があります。

・バックエンドプール

・HTTP設定

・フロントエンド IP 構成

・リスナー

・ルール

・正常性プローブ

※デフォルト設定は、ルールとの関連解除後でないと削除できないので、設定完了後、すべて削除します。(フロントエンドIPの命名はGUIでは修正できないようです。)

3.Application Gatewayの設定(バックエンドプール)

バックエンドプールの設定を行います。今回は仮想マシン(IaaS)の例で進めます。

負荷分散先となるWEBサーバのホスト名、I/F名を指定します。

4.Application Gatewayの設定(HTTP)

HTTP設定の追加を行います。今回は仮想マシン利用(HTTP)なので、設定値は変更せずに、そのままの設定で新規作成を行います

5.Application Gatewayの設定(リスナー)

リスナー設定の追加を行います。今回はHTTPなのでPort番号に80を設定し、フロントエンドポートの作成を含め新規作成を行います

6.Application Gatewayの設定(正常性プローブ)

正常性プローブは、負荷分散先の正常性を確認するものです。正常に応答が返ってくるパスを指定します。またホスト名をバックエンドHTTP設定から選択すると、仮想マシンのパスが指定されます。

7.Application Gatewayの設定(ルール)

ルール作成します。ルールは、各設定の関連を決定します

8.Application Gatewayの設定削除

ルールにデフォルトで存在するrule1を削除します

バックエンドプールにデフォルトで存在する、appGatewayBackendPoolを削除します。

HTTP設定にデフォルトで存在する、appGatewayBackendHttpSettingsを削除します。

 

9.NSGの許可設定

Application Gatewayでは、NSGでの許可設定が必要になります。今回の900-902が必要な設定になります。今回の場合はアクセス元のIPを制限を行う為、1010ですべてのアクセスを拒否し、903で接続許可するIPの設定を行っています。