[アップデート]GuardDutyでCloudTrailベースのFindingsの送信元IPv4をCIDRでフィルターと抑制ルールが指定できるようになりました

GuardDutyのFindingsをフィルター/抑制するときにCloudTrailタイプの送信元IPv4アドレスもCIDR指定できるようになりました。地味にいいやつ。
2020.09.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、GuardDutyで脅威検知してますか?(挨拶

今回は地味ですがいいアップデートが少し前にGuardDuty Announcementsから届きました。見ていきましょう。

ちなみにGuardDuty Announcementsについては下記を参照してください。

概要

概要としては検索フィルターと抑制ルールで、CloudTrailベースのFindingsの場合にある送信元IPv4をCIDRで指定できるというものです。

届いた内容はこちら。

GuardDuty finding filters and suppression rules now support entering a CIDR range when using the API caller IPv4 address field in AWS CloudTrail based findings. You can now create more fine grained suppression rules using this field. For example, for the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration finding it is recommended that you create a suppression rule when Amazon VPC networking is configured to route internet traffic such that it egresses from an on-premises gateway rather than from a VPC Internet Gateway (IGW). Previously this suppression rule relied on the ASN ID, ASN Name or an IP address and now you can use the API caller IPv4 address field to enter a CIDR range.

どう活用できるかというと、例えばUnauthorizedAccess:IAMUser/InstanceCredentialExfiltrationというFindingsは、通常想定されている送信元IPと別の場所からAWSのAPIが呼び出されたときにでるものですが、EC2の通信をすべてオンプレミス側のゲートウェイを通すような環境では、APIの送信元が本来想定されるEC2の出口(IGW)ではなくオンプレミスのゲートウェイから出ているため想定される送信元IPと異なるためこのFindingsが出ます。

ただ、正常系であるためこれを抑制ルールに設定したいのですが、今まではCIDRで登録できませんでした。

参考になるユーザーガイドはこちら

動作を見てみる

それではGuardDutyの画面で見てみましょう。

まずFindingsの一覧画面から「フィルタの追加」を選択して「API発信者のIPv4アドレス」を選択します。これがCloudTrailで記録される送信元IPアドレスです。

IPを入力する欄が出てくるので今回は/24を指定して適用してみます。

適用できたら本番の抑制ルールです。「結果の抑制」を選択して適当な名前を入れて保存します。

設定できました。「保存済みのルール」に保存されています。フィルター部分がレンジで入っていることが確認できます。

まとめ

地味ですが、CloudTrailタイプのログでもIPv4フィルターと抑制ができるようになりました。

これにより除外するIPの管理がだいぶやりやすくなったと思います。ぜひ使ってみてください。