こんばんは。今日は、Azure Application Gatewayについて前から気になっていたことを実験してみましたので、メモを残しておこうと思います。
Contents
やりたいこと
SQLインジェクションといったアプリケーションレベルの攻撃をAzure Application GatewayのWAF（Web Application Firewall）を使って検知、遮断できるようにしたい。
Azure Appliaction GatewayはAzureが提供するL7ロードバランササービスで、WAF機能も備えています。
このWAFでは、以下の通り、SQLインジェクションをはじめとしたアプリケーションへの攻撃を検知するようなルールが規定で構成されているので、初期構成のままでも検知できる想定です。今回この動作を確認してみました。
Azure Application Gateway 上の Azure Web Application Firewall (WAF) は、一般的な脆弱性やその悪用から Web アプリケーションを一元的に保護します。 Web アプリケーションが、一般的な既知の脆弱性を悪用した悪意のある攻撃の標的になるケースが増えています。 よくある攻撃の例として、SQL インジェクションやクロスサイト スクリプティングが挙げられます。
Application Gateway 上の WAF は、Open Web Application Security Project (OWASP) のコア ルール セット (CRS) に基づいています。
次に示す WAF の機能はすべて WAF ポリシー内に存在します。
実験メモ
実験の全体構成
今回はこんな単純な構成を作って実験してみます。
Application Gatewayの背後に、App Serviceを配置しており、そこにSQL Databaseから情報を取得して表示するアプリをデプロイしています。
Azure Application Gatewayのポリシー構成内容
はじめにApplication Gateway側の既定のWAFポリシー設定を確認しておきます。
確かにOWASP 3.2に基づくポリシーが全部で185個、デフォルトで構成されていますね。
そして「SQL」で検索すると・・・46個もひっかかった！？
その中に「SQL Injection Atack」もありましたね。SQL Injection Attackの中でもさらに複数のルールがありますが、詳細は以下から確認できそうです。
CRS 規則グループと規則 – Azure Web Application Firewall | Microsoft Learn
Webアプリに対してSQLインジェクション攻撃！
Application Gateway WAFルールの確認ができたところで、いよいよApplication Gateway背後にあるWebアプリにSQLインジェクション攻撃をしかけてみます。
まず、Webアプリが接続するデータベースには、TestTableというテーブルがあり、col2列に’DATA0000001’などといったIDを想定した情報がはいった100万行のレコードが存在しています。
そしてWebアプリは、col2列に対応するIDを指定して、ヒットした件数を返すというだけ適当UIをもち、
バックエンドのプログラムでは、UIから入力されたIDに一致するレコード件数を計算するというこれまた超絶シンプルなコード。上の例では、”DATA00000002″のような指定の仕方をすれば、当然ながら1件だけヒットしていることがわかります。
SQLインジェクション攻撃をしかけるときは、例えば画面からこんな感じで条件を指定します。
すると、後半条件が常にTRUEで評価されるので、すべてのレコードが取得されてしまうことに・・こわいこわい。
攻撃の検知
上記攻撃から少し待ってから、Appication Gatewayの診断ログを除いてみます。
すると・・・おお！SQLインジェクション検知のエラーがいっぱいでてる！
ちゃんとどのRuleにマッチしたのかも追跡することができます。
AzureDiagnostics
| where OperationName == "ApplicationGatewayFirewall"
| take 100
ひっかかったルールをサマリしてみるとこんな感じ。SQLインジェクション絡みでは6個のルールにひっかかってますね。（実験中に2回攻撃を試していたので、それぞれカウントが2になっています）
AzureDiagnostics
| where OperationName == "ApplicationGatewayFirewall"
| where Message contains "SQL"
| summarize count() by ruleGroup_s, ruleId_s, Message
全部の条件は見れてないですが、例えば、2つめのTautologyのルールは、今回試したような常にTRUEを返すようなインジェクション攻撃を行った場合に検知するルールのようですね。なるほど、確かにちゃんと検知されている・・・
【論文読み】SQL Injectionと機械学習を用いた検知、防御手法 (fusic.co.jp)
攻撃の遮断
さて、先ほどは、攻撃を検知するにとどまっていました。
こういった攻撃は未然に防ぎたいものですから、次に攻撃の遮断を試してみます。
攻撃の遮断をしようとしたときは、Application GatewayのWAFポリシーの動作を一段深く理解する必要があります。
まずは、「モード」。WAFには、攻撃をブロックできる「防止モード」と、検出だけしてブロックはしない「検出モード」の２種類の動作モードがあって、既定は「検出モード」で動作しています。
Application Gateway の WAF は、次の 2 つのモードで実行するように構成できます。
- 検出モード:すべての脅威アラートを監視してログに記録します。 [診断] セクションで Application Gateway の診断ログの記録をオンにしてください。 また、必ず WAF のログを選択してオンにしてください。 Web アプリケーション ファイアウォールは、検出モードで動作しているときに受信要求をブロックしません。
- 防止モード:規則で検出された侵入や攻撃をブロックします。 攻撃者に “403 不正アクセス” の例外が送信され、接続が終了します。 防止モードでは、このような攻撃を WAF ログに記録します。
まずは、これを防止モードに変更します。変更は概要ブレードから。モードの切り替えは手元環境だと1分ほどで完了しました。
次に、もう一つ理解しておく必要があるのが、WAFのアクション。これは防止モードで動作しているときに、各ルールに引っかかった場合にどのようなアクションを定義する機能のようです。
WAF のお客様は、要求が規則の条件に一致したときに実行されるアクションを選択できます。 サポートされているアクションの一覧を次に示します。
- 許可: 要求は WAF を通過し、バックエンドに転送されます。 それより優先順位の低い規則によって、この要求をブロックすることはできません。 許可アクションはボット マネージャー ルールセットにのみ適用され、コア ルール セットには適用されません。
- ブロック: 要求はブロックされ、WAF はバックエンドに要求を転送せず、クライアントに応答を送信します。
- ログ: 要求は WAF ログに記録され、WAF によって優先順位の低い規則の評価が続行されます。
- 異常スコア: これは CRS ルール セットの既定のアクションで、このアクションを含む規則が一致すると、合計異常スコアがインクリメントされます。 異常スコアリングはボット マネージャー ルールセットには適用されません。
デフォルトは「異常スコア」。これは、いきなりブロックすることはないけど、スコアを加算していき、一定以上を超えた場合にブロックしはじめる、というもの。詳細ロジックは以下。
ためしに、攻撃を繰り返してみると・・一定回数を超えたところで403が返るようになりました・・・！
ちなみにこのエラーページ、デフォルトだとApplication Gatewayサービスが提供するものですが、これはカスタマイズすることもできるようです。（Application Gatewayのリスナ―設定から）
では、攻撃を遮断した後にログをみてみます。すると、action列がblockedのものが出現しました。
これは、以下に解説がありました。防止モードでブロックされたときは「blocked」に、検出モードでblockedに該当する状況が発生したときに「detected」になるようですね。
WAF ルールがトラフィックと一致したときにログに記録されるメッセージには、アクション値 “Matched” が含められます。一致したすべてのルールの合計異常スコアが 5 以上で、WAF ポリシーが防止モードで実行されている場合、要求があるとアクション値 “Blocked” を持つ必須の異常ルールがトリガーされて、要求が停止されます。 ただし、WAF ポリシーが検出モードで実行中の場合、要求があるとアクション値 “Detected” がトリガーされ、要求はログに記録されてバックエンドに渡されます。
あと、今回は、デフォルトの「異常スコア」アクションで攻撃を遮断しましたが、ルールにマッチしたら即座に遮断するようにも変更可能です。
おわりに
以上、Azure Application GatewayのWAF機能で、SQLインジェクション攻撃を検知・遮断を試してみたメモでした。実際に手を動かしてみてApplication Gatewayの理解がまた深まりました。
所感：
・SQLインジェクションなどを検知するルールセットが標準で備えられているのは便利（最近のWAFはみんなそうなのかもしれないですが）
・デフォルトの状態ではブロックを行わない「検出モード」かつ、ルールアクションも「異常スコア」に基づくブロック。今回のようなSQLインジェクションは、一度も攻撃の成功を許可したくないものだとは思うので、モードの変更やルールごとに即座に遮断するようにアクションを変更したりといった精査は必要そう
・ただその動作変更もGUIから簡単に行えて楽。
少しでも参考になりましたら幸いです。（参考になったら、下のいいねボタンを押していただけましたら励みになります！）
おしまい
コメントを残す