AWS GuardDutyのVPCにおける検知範囲
AWS GuardDutyの検出対象
前職でLTのネタにしようとしてたんですが、その前に転職してしまったので供養。
GuardDuty
GuardDutyはAWSにおける脅威検出サービスで、有効にするだけで複雑な設定なしにAWSアカウントに対する異常なアクティビティを検出・通知を行うマネージドサービスです。
検出する範囲は広く、具体例としてはEC2インスタンスがC&Cサーバー宛ての通信が発生した場合や、S3バケットが不審なIPからアクセスされた際にアラートとして通知が行われます。
データソース
GuardDutyには特定サービスに特化した拡張機能があり、S3 Protectionや最近追加されたRDS Protectionなどがありますが、それらを除くけば主に以下をデータソースとして異常なアクティビティを検出しています。
- CloudTrail
- VPCフローログ
- DNSログ
例えば、EC2におけるC&Cサーバー宛ての通信はBackdoor:EC2/C&CActivity.BとBackdoor:EC2/C&CActivity.B!DNSで検出されますが、それぞれのデータソースはVPCフローログとDNSログであることに注意してください。
つまり、エージェントタイプのウイルス対策ソフトのようにAWSがEC2の中を確認してくれるわけではなく、EC2インスタンスが発生させるVPC上の通信から異常なアクティビティを検出しているということです。
検出対象の確認
VPCフローログやDNSログをデータソースにするのであれば、VPCを利用する全てのサービスがGuardDutyの検出対象になるのではないかと考えられますが、実際には違います。
今回はAWSにおけるEC2を代表としたコンピューティングサービスにおけるGuardDutyの検出能力を確認します。
確認方法
Backdoor:EC2/C&CActivity.B!DNSとして検出される、テスト用のドメインであるguarddutyc2activityb.comに対してスクリプト等でDNSクエリを発生させ
、GuardDutyで検出できるかを確認します。
作成したCDKは以下
※Local ZonesでのEC2のみ手動で作成したためIaC化なし
結果
First seenとCreated atはGuardDuty上で表示される最初に検出された時間とGuardDutyでアラートが作成された時間。
| 確認方法 | 検出 | First seen | Created at | |
|---|---|---|---|---|
| EC2 | インスタンス起動時に実行されるUser Dataにてdigを実行 |
Yes | 21:00:34 | 21:44:24 |
| ECS(EC2) | コンテナ内からdigを実行 | Yes | 22:02:25 | 22:58:50 |
| ECS(Fargate) | コンテナ内からdigを実行 | No | - | - |
| EKS(EC2) | コンテナ内からdigを実行 | Yes | 00:08:54 | 00:57:43 |
| EKS(Fargate) | コンテナ内からdigを実行 | No | - | - |
| Batch(EC2) | コンテナ内からdigを実行(commandを指定して実行) | Yes | 20:13:53 | 20:49:49 |
| Batch(Fargate) | コンテナ内からdigを実行(commandを指定して実行) | No | - | - |
| App Runner | コンテナ内からdigを実行 | No | - | - |
| Elastic Beanstkalk | コンテナ内からdigを実行 | Yes | 01:34:25 | 02:44:50 |
| Lambda | DNS問い合わせが発生させるプログラムを実行 | No | - | - |
| Lambda(VPC) | DNS問い合わせが発生させるプログラムを実行 | No | - | - |
| Lightsail | インスタンス起動時に実行されるUser Dataにてdigを実行 |
No | - | - |
| （おまけ）EC2 Local Zones | インスタンス起動時に実行されるUser Dataにてdigを実行 |
Yes | 23:29:19 | 00:41:09 |
まとめ
特に面白い結果が出るわけでもなく、EC2およびEC2を裏で利用しているサービスだけがBackdoor:EC2/C&CActivity.B!DNSを検出できる結果となりました。
試してはないですが、恐らく他のCloudTrailやVPCフローログをデータソースとした場合にもEC2でのみ検出できる場合があるかもしれません。
また、併せてGuardDutyの検出時間をメモしてみましたが、AWS上でログが確認されてからGuardDutyでアラートが発生するまで30分～1時間程度は経過しています。
異なるデータソースや検出対象のリソースが異なる場合には検出時間が変わってくるなどもありそうなので時間ができたたら試してみます。
感想
GuardDutyは細かい設定もなく使えるサービスですので、何ができないのかを知らずに有効にしている人も多いのではないかと個人的には思っています。
サービスによってはGuardDutyの検出対象にならなくても特に困ることがない場合もあるかと思いますが、Fargate（責任共有モデル的に対象にはならないのかな？）などは検出対象になってくれると嬉しい。
VPC上に異常な通信が発生したらどのENIなのか教えてくれるだけでもいいんですけどね。
Discussion