Azure Application GatewayでWAF対策をしてみる WAF対策編

投稿者: | 2019年6月23日

前回の記事でApplicaiton Gatewayの作成についての基本的な情報を記載しました。今回はWAF機能をオンにしてペネトレーションテストをするところまで記載して行きたいと思います。

※本記事は2019年6月23日時点の情報となります。

WAFの設定

F V2を選択してApplicaiton Gatewayを作成すればWAF機能はすでに稼働した状態になっています。WAFの機能が不要な場合はStandard V2に変更してください。
WAFの機能を一時的にOFFにしたい場合はファイヤーウォールの状態を無効にします。モードは検出か防止の2種類があります。「検出」は不正なアクセスを検出するがスルーします。「防止」を選べば不正なアクセスが来た場合にそのリクエストをブロックします。
除外設定では検出・防止にひっかかるリクエストを部分的に許可することができます。
グローバルパラメータの設定ではファイルのアップロードを除くリクエストの全体的な要求サイズを制限します。8k~128kの中で選択でき、初期値として最大サイズが設定されています。
ファイルのアップロードの上限ではファイルアップロード可能なサイズを設定できます。1MB~100MBで選択できますがLarge SKUサイズを選択すれば1MB~500MBまで選択可能です。これ以上のファイルアップロードを行いたい場合はマルチパートアップロードの考慮が必要になります。

WAFの構成の詳細は下記を参照にしてください。

この記事では、Azure portal を使用して構成する Application Gateway での Web アプリケーション ファイアウォール要求サイズ制限と除外リストについて説明します。

WAFのルールではルールセットを設定します。現状ではOWASP3.0とOWASP2.9が選択できます。OWASPって言葉が急に出てきましたが、OWASPとはOpen Web Applicaiton Security ProjectというOSSコミュニティのNPO団体のことです。この団体が策定したセキュリティルールに準拠しますというのがルールセットになります。基本的に最新バージョンを選べば問題ないと思います、またルールの詳細構成で検出・防止を行う項目の変更を項目ごとに行うことも可能です。

OWASPについては下記を参照してください。



基本的な設定はすでにされているため特に弄る必要があるところは少ないと思います。リクエスト情報の容量制約にだけ気をつけておけばハマることは少ないと思いますが、防止機能をオンにしている場合は通信の構成によってリクエストをブロックされることがあるので注意が必要です。
クロスサイトスクリプティングやSQLインジェクションのみを対応したいということであればルールの詳細構成でその項目だけをオンにする必要があります。セキュリティに対する項目設定はきちんと設計をしましょう。

ペネトレーションテスト

ペネトレーションテストとはネットワークに接続しているシステムに対してセキュリティの脆弱性をテストする手法のことです。ここでは詳細については記載しませんので下記を参照してください。



ここでは前述にもあったOWASPが提供しているOWASP ZAPというOSSを利用してペネトレーションテストを実施する方法について記載します。

Azureでペネトレーションテストを行うにあたってはマイクロソフトが提唱しているルールに準拠して行うようにしてください。詳細は下記のマイクロソフトクラウドペネトレーションテストのエンゲージメントルールを参照してください。

Unified rules for customers wishing to perform penetration tests against their Microsoft Cloud components

OWASP ZAP

OWASP ZAPとはOWASPが提供している脆弱性診断ツールです。高機能で無料で利用できるという優れモノなので利用しない手はないです。

前提としてJAVAで作られているためJREのインストールが必要になります。下記からダウンロードして先にインストールしておいてください。

このページから、Java Runtime Environment (JRE、Java Runtime) - Java Plug-in (Plugin)、Java Virtual Machine (JVM、VM、Java VM)ともいいます - をダウンロードす...


OWASP ZAPを下記から環境に合わせてダウンロードします。私の場合はWindowsを利用しているのでWindows(x64)を選択しました。

The OWASP ZAP core project. Contribute to zaproxy/zaproxy development by creating an account on GitHub.


インストールに関してはとりあえずデフォルトの値で作成してしまって大丈夫です。インストールしたら起動してみましょう。うまく起動しない場合はJREのインストールが正常に完了していないかチェックしてください。

起動すると上記のような画面が出てきます。クイックスタートの攻撃対象URLにApplicaiton GatewayのFQDNを登録してさくっとテストすることができます。但し、起動直後はテストモードが標準モードになっているため脆弱性テストを行っても攻撃となるテストは行いません。
左上にあるモードを攻撃モードに切り替えると脆弱性テストを行えます。攻撃モードでテストする時は自分以外のサイトに影響を与えないように気を付けてください。
使用者のモラルに依存するツールですので用法容量を守って利用してください。
また、テストを行う際には通信料や本番サイトへの影響等も考慮して利用するようにしてください。基本的にはリリース前に実行するテストなので本番稼働後に行うことはないと思いますが念のため注意してください。

テストを実施すると左側にテスト結果のアラートが表示されます。アラートには攻撃結果として確認すべき項目についてのアラートが表示されます。この時はモードを検知で行ったので検知はされていますがリクエストをブロックしていないのでレスポンスステータスコードが200系で返ってくるリクエストが多かったです。モードを「防止」に変更して実施するとブロックされるリクエストが多いためステータスコードが400系で返ってくるリクエストが多くなります。検知と防止で1回づつ実行して結果を比較してみるとより深く分析できるようになります。
それではAzure側を見てみましょう。ApplicationGatewayの概要で表示されるメトリックスにアクセス情報が表示されていると思います。

上記の図はWAFを検知モードと防止モードで順次実施した結果のメトリックスになります。 ここでどういったリクエストがあったのかを確認することができるのですがWAFの検知の情報は表示されないので次回にその点は記載します。
上記の図でグラフが高いものが検知モードで行った結果になります。検知モードは不正リクエストを検知してもスルーするため合計の要求数が高くなっています。反対に防止モードで実施した場合は不正リクエストをブロックしているので合計要求数が少なくなっています。
一番右側の図が顕著に表れていて、検知モードで実施した場合は400系のリクエストが少なく、200系のリクエストが多くなっています。反対に防止モードで実施した場合は400系のリクエストが多くなっていて200系のリクエストが少なくなっています。このグラフから防止モードは不正リクエストをブロックしているのがわかります。

Applicaiton Gatewayでは比較的簡単にWAFを設定して利用できますが、運用に乗せた時に不正リクエストをWAFが検知または防止した事を検知する仕組みも必要になります。次回はApplicaiton Gatewayのリクエスト情報やWAFの検知をLog Analiticsを利用して可視化する方法について記載します。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください