はじめに
Azure Firewall Premium では IDPS を利用することが可能です。ネットワーク侵入検出（IDS）と防止システム (IPS) を使用することで、ネットワークを監視して悪意のあるアクティビティが無いかを監視し、活動に関する情報をログに記録し、報告し、ブロックを試みることができます
詳細は以下リンクをご確認ください
Azure Firewall IDPS とは？
Azure Firewall での IDPS の特徴をざっくりと纏めると以下のような感じとなります
- Azure Firewall では シグネチャベースでの検知方法が利用できる
- IDPS シグネチャは、アプリケーション層（L7）とネットワーク／トランスポート層（L3–4）に適用できる
- シグネチャは継続的に更新される（フルマネージド）
- 通信はインバウンドとアウトバンドが対象となる
- アクションは Disable、Alert、Drop and Alert から選択
- シグネチャ ID 毎にアクションを設定できる
- 指定した IPアドレス、サブネット、IPアドレスグループを検査対象から除外できる
なお、IDPS は暗号化されていないトラフィックに対してのみ利用することができます。暗号化されたトラフィックを対象とする場合は、併せて Azure Firewall の TLS Inspection を利用する必要があります（Azure Firewall Premium では TLS Inspection が利用可能です）
また、IDPS (モード：アラートを出して拒否) を利用した際のスループットは利用していない時より落ちるのでご注意ください
Azure Firewall TLS インスペクションとは？
「機能の比較」の表には インバウンド TLS と アウトバンド TLS の機能が存在しておりますが、Azure Firewall 単体で利用できるのは アウトバンドTLS となります（HTTPS のインバウンド通信の場合は APPGW で SSL をオフロードしてから Azure Firewall で HTTP トラフィックを検査するという構成にすることで IDPS を利用することが可能です）
アウトバンド TLS インスペクションの動作の仕組みは以下のようなイメージとなります。図にある通り Azure Firewall にて証明書をすり替えるような形となるため、クライアントでは Azure Firewall の証明書をルート証明書としてインストールしておく必要があります
詳細については公式 Docs をご確認ください
検証環境の構成図
通信のイメージ
作業の流れ
- テスト用 Web サイトの作成
- Azure Firewall の作成
- 診断設定の追加
- TLS インスペクションの有効化
- IDPS の有効化
- アプリケーションルールの作成
- UDR の作成と適用
- 動作確認
1. テスト用 Web サイトの作成
ページが表示できればよいだけなので Azure Storage の 「静的な Web サイト」を利用して作成を実施しています
詳細は以下の公式 Docs をご参照ください
1-1. 静的な Web サイトの作成
作成したストレージアカウントにて 静的な Web サイト を有効化し、表示する HTML ファイルをアップロードします
なお、私が検証で作成した index.html と 404.html の中身は以下となります
index.html
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>サンプルWebサイト</title>
<style>
body {
font-family: Arial, sans-serif;
text-align: center;
margin: 0;
padding: 0;
background-color: #f4f4f4;
}
header {
background: #333;
color: white;
padding: 20px;
font-size: 24px;
}
main {
padding: 20px;
}
footer {
background: #333;
color: white;
text-align: center;
padding: 10px;
position: fixed;
bottom: 0;
width: 100%;
}
</style>
</head>
<body>
<header>
サンプルWebサイト
</header>
<main>
<h1>ようこそ！</h1>
<p>これはIDPS動作確認用のWebサイトです</p>
<p>Azure Storage の 静的なWebサイト を利用して作成されています</p>
</main>
<footer>
© 2025 サンプルWebサイト
</footer>
</body>
</html>
404.html
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>404 - ページが見つかりません</title>
<style>
body {
font-family: Arial, sans-serif;
text-align: center;
margin: 0;
padding: 0;
background-color: #f4f4f4;
}
.container {
margin-top: 10%;
}
h1 {
font-size: 48px;
color: #333;
}
p {
font-size: 18px;
color: #666;
}
a {
display: inline-block;
margin-top: 20px;
padding: 10px 20px;
background-color: #333;
color: white;
text-decoration: none;
border-radius: 5px;
}
a:hover {
background-color: #555;
}
</style>
</head>
<body>
<div class="container">
<h1>404</h1>
<p>お探しのページは見つかりませんでした。</p>
<a href="index.html">ホームに戻る</a>
</div>
</body>
</html>
1-2. アクセス確認
Web サイトの URL を確認し、ページにアクセスできるかの確認を行います
トップページ↓↓↓
エラーページ（存在しないパスにアクセスした際に表示される）↓↓↓
2. Azure Firewall の作成
詳細は以下の公式 Docs をご参照ください
2-1. Azure Firewall の作成
3. 診断設定の追加
IDPS のログを Log Analytics WorkSpace (LAW) に転送させるために 診断設定 を追加します
詳細は以下の公式 Docs をご参照ください
3-1. 診断設定の追加
4. TLS インスペクションの有効化
HTTPS の通信に対して IDPS による検査を行うために TLS インスペクションを有効化します
Azure Firewall で利用する証明書は自動作成メカニズムを利用して作成を実施しています。詳細は以下URLをご参照ください
4-1. TLS インスペクションの有効化
4-2. 作成されたリソースの確認
補足：証明書が作成されない場合
Azure Firewall の自動作成メカニズムを利用した場合、通常は3つのリソースが作成されます。が、今回私が検証した際には証明書のみが作成されないという事象が発生しました（以前試した時は証明書も作成されたので、たまたまかもしれませんが・・・）
なので、作成された「マネージドID」、「Key Vault」を流用して「証明書」のみを手動で作成を行ったのですが、その際の手順もメモ代わりに残しておきます。もし同様の事象が発生した場合は参考にしてみてください。手順の詳細は以下Docsをご確認ください
自己署名 CA 証明書の作成
手順メモ
-
opensslが利用できる Linux 端末に
openssl.cnfとcert.shを設置する
※ 各ファイルの中身はDocsに記載の通りとなります -
cert.shに実行権限を付与する
# chmod +x cert.sh
# ls -l
total 48
-rw-------. 1 root root 16434 Jan 21 2022 anaconda-ks.cfg
-rwxr-xr-x. 1 root root 1130 Mar 14 04:39 cert.sh
-rw-r--r--. 1 root root 1120 Mar 14 04:44 openssl.cnf
-rw-------. 1 root root 16528 Jan 21 2022 original-ks.cfg
-
cert.shを実行する
# ./cert.sh
Generating a RSA private key
.....................................................................................................................
..................................++++
.....................................................................................................................
.................................................................................................................++++
writing new private key to 'rootCA.key'
-----
Generating a RSA private key
.....................................................................................................................
.......................................................++++
.............................++++
writing new private key to 'interCA.key'
-----
Signature ok
subject=C = US, ST = US, O = Self Signed, CN = Self Signed Intermediate CA
Getting CA Private Key
================
Successfully generated root and intermediate CA certificates
- rootCA.crt/rootCA.key - Root CA public certificate and private key
- interCA.crt/interCA.key - Intermediate CA public certificate and private key
- interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault
================
- 作成された証明書を確認する
# ls -l
total 80
-rw-------. 1 root root 16434 Jan 21 2022 anaconda-ks.cfg
-rwxr-xr-x. 1 root root 1130 Mar 14 04:39 cert.sh
-rw-r--r--. 1 root root 2000 Mar 14 04:44 interCA.crt
-rw-r--r--. 1 root root 1675 Mar 14 04:44 interCA.csr
-rw-------. 1 root root 3272 Mar 14 04:44 interCA.key
-rw-------. 1 root root 4189 Mar 14 04:44 interCA.pfx
-rw-r--r--. 1 root root 1120 Mar 14 04:44 openssl.cnf
-rw-------. 1 root root 16528 Jan 21 2022 original-ks.cfg
-rw-r--r--. 1 root root 1984 Mar 14 04:44 rootCA.crt
-rw-------. 1 root root 3272 Mar 14 04:44 rootCA.key
-rw-r--r--. 1 root root 41 Mar 14 04:44 rootCA.srl
-
interCA.pfxを Azure Firewall へインポートする
5. IDPS の有効化
IDPS の有効化を行います。本件検証では 「アラート（通知は出すがトラフィックは拒否しない）」にて構成を実施しています
5-1. IDPS の有効化
他のタブは特に設定を弄らずにデフォルトのまま構成していますが、他のタブでどのような設定が実施できるかについて簡単に纏めておきます
署名規則
シグネチャーの一覧を確認したり、シグネチャー毎に動作モード（Disable, Alert, Alert and Deny）を設定することができます。現時点(2025.06.13)では80568のシグネチャー規則が存在しているようです。詳細は以下の公式 Docs をご参照ください
動作モードの設定
モード
方向
なお、シグネチャーは随時更新されているようですので、シグネチャー規則単位でのチューニングはあまり行わない方が良いかと思います
プライベートIP範囲
プライベート IP アドレス範囲を基に、トラフィックが「受信」「送信」または「内部（East-West）」であるかを識別するために利用されます。デフォルトでは IANA RFC 1918 で定義された範囲のみがプライベートIPアドレスとして認識されますが、必要に応じてプライベート IP アドレス範囲を編集、追加、削除することが可能です。詳細は以下の公式 Docs をご参照ください
バイパス一覧
バイパス一覧に指定された IP アドレス、範囲、サブネットへのトラフィックをフィルターしてルールの適用を除外させることができます。誤検知が発生した通信を除外したり、そもそも検査を行いたくない通信を除外する場合などに利用することができる機能となります
6. アプリケーションルールの作成
テスト用 Web サイトへのアクセスを許可するルールを追加します
本検証環境で作成したルールは以下の通りです
| 項目 | 設定値 |
|---|---|
| 名前 | Allow_TestWebSite |
| ソースの種類 | IPアドレス |
| ソース | * |
| プロトコル | Http:80,Https:443 |
| TLS検査 | ✅ |
| Destination Type | FQDN |
| ターゲット | idpswebtest001.z11.web.core.windows.net |
7. UDR の作成と適用
本手順は 1-1. UDR を作成し、デフォルトルートを Azure Firewall に向ける を参照してください
[該当箇所]
- 1-1. UDR を作成し、デフォルトルートを Azure Firewall に向ける
8. 動作確認
クライアントにて curl を利用して テスト用 Web サイトにアクセスし動作確認を実施します
8-1. テスト用 Web へのアクセス確認
まずは、アプリケーションルールで許可したテスト用 Web サイトにアクセスできることを確認します
$ curl --insecure -I https://idpswebtest001.z11.web.core.windows.net/
HTTP/1.1 200 OK
accept-ranges: bytes
content-length: 1235
content-md5: 6O/vJSHoR9D4YYR9w8+/VA==
content-type: text/html
date: Fri, 14 Mar 2025 07:54:22 GMT
etag: "0x8DD61D6C4F54DEA"
last-modified: Thu, 13 Mar 2025 02:28:41 GMT
server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 472e0a76-301e-0052-74b6-94c26f000000
x-ms-version: 2018-03-28
ちなみに、ストレージアカウントの 静的な Web サイト では HTTP でのアクセスは許可されていないため、アクセスに失敗します（ただ、IDPS の動作確認という観点では Web サイトへのアクセスが発生すればよい（＝ 通信が Azure Firewall を通過すれば良い）ので HTTP でも IDPS の動作確認を行うことは可能です）
$ curl -I http://idpswebtest001.z11.web.core.windows.net/
HTTP/1.1 400 Bad Request
Date: Fri, 14 Mar 2025 07:56:04 GMT
Server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
X-Ms-Error-Code: AccountRequiresHttps
X-Ms-Request-Id: f57881c0-901e-0064-20b6-944f1f000000
X-Ms-Version: 2018-03-28
念のため、アクセス許可したサイト以外にはアクセスできないことも確認しておきます
$ curl --insecure https://google.com
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443
8-2. IDPS のテスト
HTTPSリクエストの User-Agent ヘッダーを "HaxerMen" に設定し、リクエストの送信を行う
$ curl --insecure -I -A "HaxerMen" https://idpswebtest001.z11.web.core.windows.net/
HTTP/1.1 200 OK
accept-ranges: bytes
content-length: 1235
content-md5: 6O/vJSHoR9D4YYR9w8+/VA==
content-type: text/html
date: Fri, 14 Mar 2025 08:01:47 GMT
etag: "0x8DD61D6C4F54DEA"
last-modified: Thu, 13 Mar 2025 02:28:41 GMT
server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 07b4173b-f01e-0000-33b7-94be87000000
x-ms-version: 2018-03-28
併せて、HTTPリクエストでも実施しておきます
$ curl -I -A "HaxerMen" http://idpswebtest001.z11.web.core.windows.net/
HTTP/1.1 400 Bad Request
Date: Fri, 14 Mar 2025 08:02:26 GMT
Server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
X-Ms-Error-Code: AccountRequiresHttps
X-Ms-Request-Id: 673e07dc-101e-008e-34b7-946831000000
X-Ms-Version: 2018-03-28
8-3. IDPS ログの確認
しばらく時間を置いてから、Log Analytics Workspace にてアラートが出力されていることを確認します（実行する KQL クエリは AZFWIdpsSignature です）
HTTPS 通信
HTTP 通信
IDPS で検知したアラートの署名 ID は 2032081 となります。また、SourceIP は 10.0.0.4 となっているのでアクセス元 VM（hub-client）の IPアドレスで記録されるようです
まとめ
今回は Azure Firewall の IDPS の利用手順について纏めました。設定自体は簡単に実施できるため、ネットワークセキュリティの強化の1つとして選択肢に含めていただければと思います。ただし、IDS (アラートを出して拒否) として利用する場合はスループットが低くなるためご注意ください
本記事の内容が Azure Firewall の利用を検討している方に少しでもお役にたてれば幸いです
Appendix
公式Docs
サポートブログ
Zennの記事（他の Azure Firewall の記事）
Discussion
見出し名も考慮するとインバウンドTLSインスペクションがプレミアムプランで利用できないと認識してしまいますが、言いたいのは、インバウンドTLS終端がAzure Firewallのみでは不可能（Application Gatewayが必要）ということでしょうか？
はい。ご認識いただいている通りです。誤解を与えそうな記載のようですので、後ほど修正しておくようにいたします。コメントいただきありがとうございます！
とんでもないです！
タメになる記事ありがとうございます！