[アップデート] AWS Network Firewall でAWSが提供するマネージドのSuricata互換のIPSルール「AWS Managed Threat Signatures」が使えるようになりました

自分でSuricata互換のIPSルールを用意するのは大変だな

こんにちは、のんピ(@non____97)です。

皆さんはAWS Network Firewallで使うSuricata互換のIPSルールを作るのは得意ですか? 私はあまり得意ではありません。

Suricata互換のIPSルールを使うことでSecurity GroupやNetwork ACLなどでブロックできない通信をブロックすることができます。詳細は以下記事で紹介しています。

しかし、Suricata互換のIPSルールを1から用意するのは中々大変です。

対応として、「公開されているSuricata互換のIPSルールを定期的に取得し、ルールグループを作成する」という方法があります。

これにより、一般的な不審な通信を簡単に検知、ブロックすることができます。

私もここで「AWS Network Firewall始まったな」と思いました。

しかし、まだAWS Network Firewallは完全に始まってはいなかったのです。

AWS Network Firewallは今回紹介するアップデート「AWS Managed Threat Signaturesの提供開始」によって完全に始まったと言えます。

こちらのルールは既にあるマネージドのドメインリストルールと同様にAWSが提供しているものになります。

早速確認してみたので事項からAWS Managed Threat Signaturesを説明します。

いきなりまとめ

• AWS Managed Threat SignaturesとはAWSが提供するマネージドのSuricata互換のIPSルール
• 2022/5/9時点でマルウェアやボットネットなど15個のシグネチャが提供されている
• AWS Managed Threat Signatures を使用するのに追加の料金は発生しない
• AWS Managed Threat Signaturesは、すべての商用 AWS リージョンと AWS GovCloud (米国) リージョンで使用可能
• AWS Managed Threat Signaturesをベースに自分でカスタマイズすることも可能
• AWS Managed Threat Signaturesに更新があった際に通知することも可能

AWS Managed Threat Signaturesとは

AWS Managed Threat SignaturesとはAWSが提供するマネージドのSuricata互換のIPSルールです。

AWS Managed Threat Signaturesを活用することで、自分でSuricata互換のルールを書いたり、保守したりすることなく最新のセキュリティ上の脅威に対して防御を固めることができます。

2022/5/9時点でマルウェアやボットネット、スキャナーなど15個のシグネチャが提供されています。

提供されているルールの詳細は以下のAWS公式ドキュメントから確認できます。

AWS Managed Threat Signaturesの料金

AWS Managed Threat Signatures を使用するのに追加の料金は発生しません。

VPCのコンソールまたはNetwork Firewall APIを使用して、利用できます。

AWS Managed Threat Signaturesを使用できるリージョン

AWS Managed Threat Signaturesは、すべての商用 AWS リージョンと AWS GovCloud (米国) リージョンで使用できます。

東京リージョン、大阪リージョンでも早速使用できるのはありがたいです。

マネージメントコンソールから確認してみた

AWS Managed Threat Signaturesの一覧確認

それではマネージメントコンソールからAWS Managed Threat Signaturesを確認してみます。

VPCのコンソールからネットワークファイアウォールのルールグループ-AWSマネージドルールグループをクリックすると、脅威署名ルールグループ(AWS Managed Threat Signatures)が表示されました。

確認できるAWS Managed Threat Signaturesの一覧を眺めると、一つのシグネチャにつきルールの順序がdefaultかstrictかで2つずつあることが分かります。

defaultとstrictはルールを評価する順序が異なります。

defaultの場合はSuricataのactionの順序と、指定したpriorityに従います。

strictの場合は優先順位の小さいものから順に評価され、各ルールグループのルールは定義された順序で処理されます。

詳細は以下AWS公式ドキュメントをご覧ください。

また、表示されているAWS Managed Threat Signaturesの数は26個で、各シグネチャに2つルールグループが存在するのであれば、(30-26)/2=2で2つ足りないことになります。

表示されているルールグループの名前を全て確認したところ、どのリージョンでも以下2つのシグネチャについてのルールグループが存在しないようでした。

• ThreatSignaturesMalwareMobile
• ThreatSignaturesMail

個人的にはメールに対するシグネチャはありがたいので、こちらのシグネチャの提供も期待して待っています。

AWS Managed Threat Signaturesのルールグループの確認

次に、実際にAWS Managed Threat Signaturesのルールグループの内容を確認してみます。

ThreatSignaturesBotnetActionOrderをクリックすると以下のような画面が表示されました。

詳細にルールグループの名前やタイプ、ステートフルルールの順序、説明、キャパシティ、最終更新日が表示されています。

そして、SNSトピックとSuricata互換のIPSルールが表示されています。どうやらルール変数の編集はここではできないようですね。

右上のルールグループをコピーが気になったので、試しにクリックしてみます。

すると、キャパシティーとSuricata互換のIPSルールが入力された状態で新規にルールグループを作成する画面が表示されました。

ルールグループのコピーを活用することで任意のシグネチャのみalertからdropに変更したり、任意のIPセット変数やポート変数を指定ししたりしてAWS Managed Threat Signaturesを自分の環境にあったルールグループにすることができそうです。

ちなみに、ルールの順序がdefaultなのかstrictなのかでSuricata互換のIPSルールが異なるかを確認したところ、ルールの順序がdefaultの場合にはclasstypeが付与されていました。

ThreatSignaturesBotnetActionOrder

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ETPRO MALWARE Backdoor.Win32.Remosh.A Checkin"; flow:to_server,established; content:"|01 50 00 00 00 00 00 00 00 00 00 01 68 57 24 13|"; depth:16; classtype:command-and-control; sid:2800816; rev:1; metadata:created_at 2010_10_13, former_category MALWARE, updated_at 2010_10_13;)
(以降省略)

ThreatSignaturesBotnetStrictOrder

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ETPRO MALWARE Backdoor.Win32.Remosh.A Checkin"; flow:to_server,established; content:"|01 50 00 00 00 00 00 00 00 00 00 01 68 57 24 13|"; depth:16; sid:2800816; rev:1; metadata:created_at 2010_10_13, former_category MALWARE, updated_at 2010_10_13;)
(以降省略)

本来であれば、classtypeを使用する場合はconfig classificationでclasstype毎の優先度を定義するところですが、Suricata互換のIPSルール内にconfig classificationの記載がないので、今回の場合classtypeの有無は優先順位に影響を与えないように読み取れます。

SNSトピックの確認

次に、表示されていたSNSトピックを確認します。

こちらの説明には以下のように記載があります。

このルールグループに関する変更の通知を Amazon SNS にサブスクライブします。ARN をコピーし、SNS コンソールでサブスクリプションを作成するときに Topic ARN として使用します。

AWS Managed Threat Signaturesに変更があった場合に、このSNSトピックを使えば通知されるということのようです。

試しに、SNSトピックのリンクarn:aws:sns:us-east-1:xxxx:AWS-Managed-Threat-Signaturesをクリックすると、SNSのサブスクリプション作成画面が表示されました。

トピックARNに先ほど表示されていたSNSトピックのARNを入力し、通知先としてメールアドレスを指定してサブスクリプションの作成をクリックします。

すると、AWS Notification - Subscription Confirmationという件名のメールが送信されるので、メール内のリンクConfirm subscriptionをクリックして、サブスクリプションの確認をします。

サブスクリプションの確認後、SNSのコンソールからサブスクリプションを確認するとステータスが確認済みとなっていました。

トピックのAWS-Managed-Threat-Signaturesをクリックしても権限不足で表示できなかったので、AWS-Managed-Threat-SignaturesはどうやらマネージドのSNSトピックのようです。

サブスクリプションを作成してしばらく放置していると、New version available for:ルールグループ名というメールが何件か飛んできました。

メール本文の内容は以下の通りです。AWS Managed Threat Signaturesのルールグループが更新された場合に素早く気付くことができそうです。

The following AWS Network Firewall managed resource has a new version: arn:aws:network-firewall:us-east-1:aws-managed:stateful-rulegroup/ThreatSignaturesBotnetWebActionOrder. To view the new version, either call DescribeRuleGroup or view the resource in the Network Firewall console.

ちなみに、SNSトピックはAWS Managed Threat Signaturesのルールグループで共通のようなので、全てのルールグループで設定する必要はありません。

1つ設定してしまえば、そのリージョンのAWS Managed Threat Signaturesのルールグループで更新があった場合は通知されます。

AWS Network Firewall 完全に始まったな

AWSが提供するマネージドのSuricata互換のIPSルール「AWS Managed Threat Signatures」を紹介しました。

AWS Network Firewall 完全に始まりましたね。

AWS Managed Threat Signaturesを利用される場合は、いきなりブロック(dropやreject)するように設定するのではなく、まずは通知(alert)するようにして、様子を見ることをお勧めします。

私が確認したところ、いずれのシグネチャもデフォルトの検知時の挙動はブロックではなく、通知でした。

ブロックするように動作を変更する場合は、AWS Managed Threat Signaturesをベースにルールグループをカスタマイズする必要があります。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!

ちなみに全てアラートです。