G-gen の三浦です。当記事では Cloud NGFW（旧称 Cloud Firewall）の IPS 機能について検証した結果をご紹介します。
概要
Cloud NGFW とは
Cloud Next Generation Firewall は、Google Cloud（旧称 GCP）の Virtual Private Cloud（以下、VPC）で利用可能な、フルマネージドのファイアウォールサービスです。
サービス名は、公式ドキュメント等でも Cloud NGFW と省略されているため、当記事でも以後、Cloud NGFW と表記します。なお、Cloud NGFW はかつて Cloud Firewall という名称でしたが、2024年4月に改称され、Cloud NGFW になりました。
Cloud NGFW には無償の Essentials と有償の Standard、Enterprise の3つのティアが存在し、当記事で紹介する IPS 機能は Enterprise ティアでのみ利用可能です。
- 参考 : Cloud NGFW の概要
Cloud NGFW の詳細や各ティアの詳細については弊社ブログで解説しておりますのでそちらをご参照ください。
IPS とは
IPS（Intrusion Prevention System）とは、ネットワークトラフィックを監視し、ネットワーク内で悪意のある攻撃を検知した際にブロックをする侵入防止システムです。
IPS という用語は Google Cloud に特有のものではなく、ネットワークセキュリティツールの一般的な名称です。
Cloud NGFW の IPS 機能は Intrusion prevention service とも表記され、日本語ドキュメントでは「侵入防止サービス」と表記されることがあります。IPS、Intrusion Prevention System、Intrusion prevention service、侵入防止サービスといった用語は、Cloud NGFW の背景では、同じものを指すと考えて構いません。
- 参考 : 侵入防止サービスの概要
なお、類似の用語で IDS（Intrusion Detection System）があります。こちらは IPS と同様に悪意のある攻撃の検知が可能ですが、ブロックはせず、検知のみです。
Google Cloud では Cloud IDS というサービスを提供しています。詳細は当社の記事で解説しています。
検証の概要
前提
Cloud NGFW の IPS 機能を利用するためには、プロジェクトが組織（Organization）に所属している必要があります。
組織（Organization）の詳細は当社の記事で解説しているのでご参照ください。
構成図
今回は、以下の構成図の環境で検証を行いました。
検証の流れ
検証の流れは、以下のとおりです。まず前半に、IPS の設定を「検知のみ」にし、ログ記録が行われることを確認します。後半では、実際に攻撃をブロックしたり、偽陽性トラフィックを明示的に許可する検証を行います。
- 検知の検証
- IPS をセットアップ。拒否はせずに検知のみの設定とする
- クライアントから Web サーバーへ以下2パターンのアクセスを実施。Web サーバーからの応答があることを確認
- パターン1 : テストファイル（EICAR）へアクセス
- パターン2 : /etc/passwd ディレクトリへアクセス
- ログを確認し、両パターンの通信が IPS で検知されていることを確認
- ブロックの検証
- 検知したアクセスパターンを以下のように仮定する
- パターン1は誤検知（偽陽性）と仮定し、明示的に許可する
- パターン2は攻撃トラフィックでと仮定し、拒否する
- 重大度「中」以上の脅威（パターン2を含む）を検知した場合は「拒否」、パターン1のシグネチャを「許可」するように設定変更
- 再度 Web サーバーへのアクセスを試行。パターン2のみが「拒否」されることを確認
- 検知したアクセスパターンを以下のように仮定する
EICAR ファイル
Compute Engine VM 上で Web サーバーを起動し、EICAR ファイル（マルウェアの検出テスト用ファイル）を配置します。curl コマンドでその EICAR ファイルへのリクエストを実施することで、IPS の動作を確認します。
EICAR は無害なテキストファイルですが、各社のアンチウイルスソフト等でウイルスとして検知されるようになっています。Cloud NGFW の IPS 機能でも検知されるため、今回の検証に利用しました。
検証環境の構築
セキュリティプロファイルの作成
本手順は、組織レベルで実施します。Google Cloud Web コンソールへログインし、対象の組織へ遷移します。
ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイルへ移動し、「プロファイルを作成」を押下します。
任意の名前を入力し「続行」を押下します。
各重大度のアクションを「アラート」に設定し、「作成」を押下します。本設定により、ブロックはせずに検知のみの設定となります。
選択可能なアクションについては、以下のドキュメントをご参照ください。
セキュリティプロファイルグループの作成
本手順も、前項と同様に組織レベルで実施します。
ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイル > セキュリティ プロファイルグループ へ移動し、「プロファイル グループ作成」を押下します。
任意の名前を入力し、脅威防止プロファイルの箇所に前手順で作成した「セキュリティ プロファイル」を選択した上で「作成」を押下します。
ファイアウォールエンドポイントの作成
本手順も、前項と同様に組織レベルで実施します。
ネットワーク セキュリティ > Cloud NGFW > ファイアウォール エンドポイント へ移動し、「作成」を押下します。
以下項目を設定し、「続行」を押下します。
- リージョンとゾーン：Webサーバ と同じ値を選択
- 名前：任意の値を入力
- 課金プロジェクト：対象のプロジェクトを選択
「エンドポイントの関連付けを追加」から IPS を導入するプロジェクトと VPC 名を選択し、「作成」を押下します。
作成には、20〜30分程度かかります。
ファイアウォール ポリシーの作成
本手順も、前項と同様に組織レベルで実施します。
ネットワーク セキュリティ > Cloud NGFW > ファイアウォール ポリシー へ移動し、「ファイアウォール ポリシー作成」を押下します。
任意のポリシー名を入力し、「続行」を押下します。
「ルールを追加」から、ファイアウォールルールを作成します。
- 優先度：一意の数値
- 一致したときのアクション：L7 の検査に進む（前手順で作成したセキュリティ プロファイルグループを選択）
- 送信元：IPv4、IP 範囲：0.0.0.0/0
「追加」を押下し、ファイアウォール ポリシーを適用する組織名を選択し、「追加」を押下します。
「作成」をクリックします。
攻撃検知の検証
パターン1（EICAR ファイル）
テスト用の端末から curl コマンドを実行して、EICAR ファイルの取得を試行します。重大度のアクションが「アラート」のため、検知はされますが、実際の拒否は行われないのが想定される結果です。
$ curl -v http://$TESTIP/eicar.com 〜省略〜 < X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* * Connection #0 to host ***.***.***.*** left intact $
対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下4点を確認します。
- アラートの重大度が「MEDIUM」となっていること。
- 脅威の名前が「Eicar File Detected」となっていること。
- 脅威 ID（後続の手順で使用するため、メモしておきます。）
- アクションが「ALERT」となっていること。
パターン2（/etc/passwd ディレクトリ）
同様に curl コマンドを実行して、/etc/passwd ディレクトリへのアクセスを試行します。重大度のアクションが「アラート」のため、検知はされますが、実際の拒否は行われないのが想定される結果です。
$ curl -v http://$TESTIP/etc/passwd 〜省略〜 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL was not found on this server.</p> <hr> <address>Apache/2.4.59 (Debian) Server at XX.XX.XX.XX Port 80</address> </body></html> * Connection #0 to host XX.XX.XX.XX left intact $
対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下3点を確認します。
- アラートの重大度が「HIGH」となっていること。
- 脅威の名前が「HTTP /etc/passwd Access Attempt」となっていること。
- アクションが「ALERT」となっていること。
ブロックの検証
IPS の設定変更
本手順は組織レベルで実施します。
ネットワーク セキュリティ > 共通コンポーネント > セキュリティ プロファイルへ移動し、前手順で作成したプロファイルを選択します。
「編集」から重大度「重大」「高」「中」のアクションを「拒否」へ変更し、「ID で署名を追加」を押下します。初回アクセス検証で確認した通り、パターン1（MEDIUM = 「中」）、パターン2（HIGH = 「高」）のため、この時点では両通信共に「拒否」されます。
本検証では重大度「低」「情報」に関しては、影響が小さいと判断し「アラート」のままとしていますが、実業務でどのような設定とするかは、以下ドキュメントをご参照の上で判断してください。
- 参考 : 脅威の重大度
初回アクセス検証「パターン1」で確認した脅威 ID を入力し、アクションを「許可」に設定し、「署名の追加」を押下します。
「保存」を押下します。
なお署名とは一般的にシグネチャとも表現されます。シグネチャは、脆弱性、スパイウェア、ウイルス、特定の DNS クエリなどを検知するためのルールのことです。
以下ドキュメントの通り、署名に対するアクションは重大度のアクションよりも優先されるため、上記の設定を追加することでパターン1が「許可」されます。偽陽性となった特定のシグネチャを無視する際に、本機能を利用できます。
脅威 ID の一覧は、Palo Alto Networks 社のサイト「Threat Vault」へログインすることで確認可能です。同サイトでは、特定の CVE 番号に関連する脅威 ID の検索等も可能です。同サイトを利用するには、別途 Palo Alto Networks のアカウント作成が必要となります。これは、Cloud NGFW の IPS 機能が、バックエンドで Palo Alto 社の技術を利用していることに起因します。
- 参考：脅威シグネチャの概要
- 参考：Threat Vault
パターン1（EICAR ファイル）
テスト用の端末から curl コマンドを実行して、EICAR ファイルの取得を試行します。重大度「中（MEDIUM）」のアクションを「拒否」に変更していますが、脅威 ID を「許可」に設定しているため、ブロックされず、ログも記録されないのが想定結果です。
$ curl -v http://$TESTIP/eicar.com 〜省略〜 < X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* * Connection #0 to host ***.***.***.*** left intact $
対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、検証時のログが存在しないことを確認します。
パターン2（/etc/passwd ディレクトリ）
同様に curl コマンドを実行して、/etc/passwd ディレクトリへのアクセスを試行します。重大度「HIGH（高）」のアクションを「拒否」に変更しているため、拒否されるのが想定結果です。
もし Web サーバーから 404エラー等の応答があった場合、設定の反映に時間がかかっている可能性があるため、5〜10分程度、時間を空けて再実行してください。
$ curl -v http://$TESTIP/etc/passwd 〜省略〜 > * Recv failure: Connection reset by peer * Closing connection 0 curl: (56) Recv failure: Connection reset by peer $
対象の「プロジェクト」から ネットワーク セキュリティ > Cloud NGFW > 脅威 へ移動し、以下3点を確認します。
- アラートの重大度が「HIGH」となっていること。
- 脅威の名前が「HTTP /etc/passwd Access Attempt」となっていること。
- アクションが「DROP」となっていること。
