AWS Network Firewallでマネージドルールグループのアラートのみを通知する

こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。

今回は、AWS Network Firewallの話題です。これまでにもAWS Network Firewallの記事を書いておりますので、ご興味ありましたらそちらもご覧ください。

AWS Network FirewallのIDS・IPS機能について

AWS Network FirewallはIDS・IPS機能とファイアウォール機能を備えていますが、簡易に導入する場合、IDS・IPS機能はAWSマネージドグループをそのまま適用するということもあるのではないでしょうか。

AWS Network Firewallには、AWSが予め用意したAWSマネージドグループというものが複数あり、これを組み合わせることで利用者側は難しい設定をせずにIDS・IPSとして機能させることができるのです。

ドメインおよび IP ルールグループの一覧

脅威署名ルールグループの一覧

AWSマネージドグループは、AWSがルールを自動的にアップデートしてくれるので、新しい脅威が発見されるたびに自分たちでルールを更新する必要もありません。

AWSマネージドグループの問題点

このように便利なAWSマネージドグループですが、少々困ることがあります。

運用上、通常のパケットフィルタリングで通信をブロックしたときのアラートは運用担当に通知してほしくないけれど、IDS・IPSでブロックした場合は通知したい、というケースはあり得そうです。ところが、ログから、これはAWSマネージドグループのルールに合致したログであるという判断ができません。

以下にCloudWatchに出力されたIDS・IPSのアラートログを2つ掲載します。

managed_rule_alert_1_with_highlight managed_rule_alert_2_with_highlight

判断に使えそうなフィールドとしては、event.alert.signatureとevent.alert.signature_idがありそうですが、signatureの方は共通する文字列がありません。一方、signature_idの方は28から始まる7桁の数字という共通点がありそうですが、AWSサポートに問い合わせたところ、この範囲のidが使われるという確実な情報はないようでした。

独自作成したルールグループのログ出力を制御する

そこで、「独自作成したルールグループから出力されたログ以外」を通知する設定を考えてみます。

標準ステートフルルール形式[1]で記述したルールに合致したログは以下のようになります。

[1] AWS Network Firewallにおけるルール記述方法のひとつ。パケットフィルタリングのルールを比較的簡単に記述できる。他にSuricata互換ルール文字列という形式もある。

custom_rule_alert_2_with_highlight

event.alert.signatureがない(厳密には、空文字 “”になっている)ことが分かります。

また、標準ステートフルルール形式のルールにはオプションで任意のsignature文字列(設定時はmsgキーワードで指定)を付与できるので、文字列の先頭に決まった文字列をつけるのもよいでしょう。次の例は先頭に”PACKET_FILTER_ALERT:”をつけるようにしてみました。

custom_rule_alert_3_with_highlight

さらに、独自作成ルールグループのルールではないのですが、TCP 3ウェイハンドシェイクを暗黙的に許可したときなど、どのルールにも合致しなかったパケットがアラートログに出力される場合があります。一例がこちらです。

custom_rule_alert_1_with_highlight

signatureが”aws:”という文字列で始まっていることが分かります。

独自作成したルールグループのログ以外を通知するフィルターを作成する

それではフィルターを作成してみます。CloudWatch Logsからメールなどの通知につなげる方法として代表的なものにメトリクスフィルターを使う方法とサブスクリプションフィルターを使う方法がありますが、本稿ではサブスクリプションフィルターを設定してみます。

なお、メトリクスフィルターとサブスクリプションフィルターのフィルターパターン構文は一緒なので、以下で説明するパターンはメトリクスフィルターでも使用することができます。

作成するフィルターは、signatureが”PACKET_FILTER_ALERT:“、”aws:“ではじまるもの以外を通知するフィルター[2]とします。

[2] “”も除外条件に含めようとしたのですが、サブスクリプションフィルターでは正規表現を2パターンまでしか指定できず、また正規表現”()”をサポートしていないということで、私の知識の範囲では三つすべてを除外する設定が書けませんでした。ルールには必ず特定の文字列から始まるsignatureを入力する(msgキーワードを指定する)という運用にすれば、””を除外条件に含められなくても実用上は問題ないかと思います。

サブスクリプションフィルターの作成

サブスクリプションフィルターの作成時に、既存のログからフィルタパターンのテストをすることができますので、一通り必要なログを出力してから作成を実施することをお勧めします。

CloudWatchのロググループから対象のロググループを選択し、「アクション」→「サブスクリプションフィルター」→「Lambdaサブスクリプションフィルターを作成」をクリック

create_subscription_filter

「Lambda サブスクリプションフィルターを作成」画面で入力をしていきます。

ログの送り先となるLambda関数を指定する必要がありますが、本稿は特定の文字列を除外するフィルターのテストまでを扱いますので、指定を省略します。実際には、Lambda関数の作成~SNS通知の部分を作る必要がありますので、インターネット上の各種ブログ記事等をご参照の上、設定してください。

ログの形式にJSONを指定します。

サブスクリプションフィルターのパターンに以下を指定します。

{ $.event.alert.signature != %^PACKET_FILTER_ALERT:.*% && $.event.alert.signature != %^aws:.*% }

filter_pattern

サブスクリプションフィルターのテスト

「パターンをテスト」の「テストするログデータを選択」のところで、テストしたいログのあるログストリームを選択し、「パターンをテスト」をクリックします。

表示されたテスト結果を見ると、意図通り、signatureが”PACKET_FILTER_ALERT:”または”aws:”で始まるログを除外できていることが確認できました。

test_filter_pattern

まとめ

CloudWatch Logsのサブスクリプションフィルターを使ってAWS Network FirewallのAWSマネージドルールのログのみを通知する方法を解説してみました。

本稿では、AWSマネージドルールで使用されるsignature_idは分からないという前提に立ちましたが、公式ドキュメントに公開されていないだけで実際には使用されるIDの範囲が決まっているのではないかと思われますので、AWSのサポートを受けつつsignature_idでフィルターをかける方式を検討するのもありかもしれません。

著者について

SCSKにて、AWSの技術支援を提供するAWSテクニカルエスコートサービスの業務に従事しています。
自称ネットワークエンジニア。
CloudFormationは触っていても面白みが感じられないけれどCDKは好き。

2024 Japan AWS Top Engineers (Networking)
2024 Japan AWS All Certifications Engineers

その他所持資格:
IPA 情報処理安全確保支援士

好きなすみっコはとかげ。

貝塚広行をフォローする

クラウドに強いによるエンジニアブログです。

SCSKクラウドサービス(AWS)は、企業価値の向上につながるAWS 導入を全面支援するオールインワンサービスです。AWS最上位パートナーとして、多種多様な業界のシステム構築実績を持つSCSKが、お客様のDX推進を強力にサポートします。

AWSクラウドクラウドセキュリティソリューションネットワーク運用・監視
シェアする
タイトルとURLをコピーしました