こんにちは、臼田です。
みなさん、GuardDuty使ってますか？(挨拶
今回はついに待望のEC2のRuntime Monitoringがプレビューとして登場したので実際に試してみました。
Amazon GuardDuty now supports runtime monitoring for Amazon EC2 (Preview)
概要
Amazon GuardDutyは脅威検出のサービスです。これまでRuntime(実行環境)のモニタリングとしてEKS( on EC2)をサポートしていました。これによりEKS上でマルウェアの感染や攻撃者の侵入が疑われる不審な挙動などが観測された場合に、GuardDutyがこれを検出していました。
今回のre:Invent 2023では、待望のECS on FargateでのRuntime Monitoringがやってきました！その詳細は下記をご確認ください。
で、それに合わせて純粋なEC2でも同様のことができるようになりました。
既存では、EC2に関する不審な挙動は、EC2の内部ではなく、EC2と別のエンティティが通信したVPCフローログを元に検出していました。そのため、実際に誰がどのような操作をしてその通信が発生したか、どういった経路から侵入されているのかなどが不明でした。
今回のアップデートにより、実行されているプロセスと実行ユーザーやそのプロセスツリーまで詳細に確認することができるようになり、より詳細な調査をマネージドにできるようになりました。
従来のEC2タイプの検出との違い
従来のEC2の検出に比べて、EC2のRuntime Monitoringはより拡張された検出が可能です。それぞれの違いをまとめてみました。
性質
従来のEC2の検出はGuardDutyのデフォルトの機能です。EC2のRuntime Monitoringはオプションとなっていて、必要に応じて追加で利用します。
従来のEC2の検出はGuardDutyを利用しつつ無効化することはできませんが、EC2のRuntime Monitoringはオプションのため個別に無効化可能です。
検出タイプ
従来のEC2の検出はとEC2のRuntime Monitoringには検出できるFinding typesに違いがあります。重複を除くと以下のようになります。
従来のEC2
- Backdoor:EC2/DenialOfService.Dns
- Backdoor:EC2/DenialOfService.Tcp
- Backdoor:EC2/DenialOfService.Udp
- Backdoor:EC2/DenialOfService.UdpOnTcpPorts
- Backdoor:EC2/DenialOfService.UnusualProtocol
- Backdoor:EC2/Spambot
- Behavior:EC2/NetworkPortUnusual
- Behavior:EC2/TrafficVolumeUnusual
- DefenseEvasion:EC2/UnusualDNSResolver
- DefenseEvasion:EC2/UnusualDoHActivity
- DefenseEvasion:EC2/UnusualDoTActivity
- Impact:EC2/PortSweep
- Impact:EC2/WinRMBruteForce
- Recon:EC2/PortProbeEMRUnprotectedPort
- Recon:EC2/PortProbeUnprotectedPort
- Recon:EC2/Portscan
- Trojan:EC2/DNSDataExfiltration
- UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
- UnauthorizedAccess:EC2/RDPBruteForce
- UnauthorizedAccess:EC2/SSHBruteForce
EC2のRuntime Monitoring
- Execution:Runtime/NewBinaryExecuted
- PrivilegeEscalation:Runtime/DockerSocketAccessed
- PrivilegeEscalation:Runtime/RuncContainerEscape
- PrivilegeEscalation:Runtime/CGroupsReleaseAgentModified
- DefenseEvasion:Runtime/ProcessInjection.Proc
- DefenseEvasion:Runtime/ProcessInjection.Ptrace
- DefenseEvasion:Runtime/ProcessInjection.VirtualMemoryWrite
- Execution:Runtime/ReverseShell
- DefenseEvasion:Runtime/FilelessExecution
- Impact:Runtime/CryptoMinerExecuted
- Execution:Runtime/NewLibraryLoaded
- PrivilegeEscalation:Runtime/UserfaultfdUsage
これは調査しているログがネットワークなのか実行環境なのかによってくる違いです。ざっくり説明すると、従来のEC2の検出はDoSやブルートフォースなどを検出でき、EC2のRuntime Monitoringではプロセスの詳細な実行などを検出します。
一部同じ項目も検出できますが、それぞれ違う項目も検出します。
料金
料金も違います。
従来のEC2はVPCフローログの分析料金として計上され、東京リージョンでは最初の500 GB/月で1 GB あたり1.18 ドルです。
EC2のRuntime MonitoringはvCPUの単位で計算され、最初の 500 vCPU/月 (監視対象の EKS インスタンスの場合)でvCPU あたり2.00 ドルです。
加えて、EC2のRuntime Monitoringの場合には、従来のEC2の検出と重複する部分があることから、GuardDuty エージェントがデプロイされアクティブになっているインスタンスからのVPCフローログの分析に対して料金はかかりません。そのため、これを有効化するとよりその料金の差が顕著に出るため、料金比較を行う場合には注意してください。
単純比較できる値ではありませんが、私のこれまでの経験的にはVPCフローログの分析料金は比較的安いので、オプションを有効化することで費用は上がると考えるべきでしょう。
それぞれ30日の無料期間があります。
詳細は料金ページをご確認ください。
考え方
以上を踏まえて、EC2のRuntime Monitoringとの付き合い方ですが、まず大前提として、これまでEC2の保護として一番強力なものは、サードパーティのマルウェア対策を導入することであったことから、これも選択肢に入れて検討する必要があります。
例えばトレンドマイクロのCloud One Workload Securityは、ランタイムの問題を検出だけでなく瞬時に自動でブロックして、被害の発生自体を防いでくれます。GuardDutyでは30分未満の検出までですので、これは大きな違いです。
対象のEC2のプライオリティに応じて以下のように検討するといいでしょう。
- ミッションクリティカルなワークロードや重要な情報を扱うEC2
- サードパーティのマルウェア対策
- それ以外の比較的リスクが低いEC2
- 従来のEC2の検出 or EC2のRuntime Monitoring
プライオリティではこの2つに差はありません。
どちらにするかを決めるには、インシデント発生時に原因を明確にしたいかどうか(そこに追加のコストを支払っていいか)になります。
もう少し追加で説明します。従来のEC2の検出はなにか不審なことが起きていることはわかりました。例えばマルウェアに感染してC2サーバーと通信したことは検出できました。しかし、これはネットワークから得られた洞察であり、そのEC2の内部で何が起きていたかはわかりません。そのために、これまではMalware Protection機能を利用して、マルウェアのファイルがEBS上に存在するかを確認していました。しかしこれでも、ファイルを特定するまでで、そのファイルが実際に悪さをしていたのか、そのファイルが誰にどのように実行されたかは辿れません。
結果、調査した結果根本的な原因は特定できないで終わります。それを許容できるのか、追加のコストを支払って詳細まで調査するのか、といった観点で採用するか決めると良さそうです。
実際にEC2のRuntime Monitoringを使ってプロセスの詳細まで確認するのはこの記事の最後の方を参考にしてください。
やってみた
ではEC2のRuntime Monitoringを使っていきましょう。
GuardDutyで新しくRuntime Monitoringのメニューが切り出されているので開きます。
従来はEKS側にあったRuntimeの設定が、集約されECSとEC2のものもここで管理されています。有効化します。
ちなみに、EKS側はさっぱりした画面に戻っていて、Runtimeは移動したよってアナウンスがありました。
現状ではEKSやECSと違い、プレビューのためエージェントを手動でEC2にインストールしたりセットアップが必要とのことでした。この手順はこちらのユーザーガイドにあります。これをやっていきます。
ステップは以下のとおりです。
- VPCエンドポイント作成
- エージェントインストール
- 動作確認
まずはVPCエンドポイントを作成します。GuardDutyのData通信用に利用し、無料で利用できます。
VPCエンドポイントに必要なセキュリティグループを用意します。このVPCエンドポイントではTCP: 443の通信を受け付けるため、これを許可する設定を行います。
続いてVPCエンドポイントの作成です。guarddutyで検索するとcom.amazonaws.[リージョン名].guardduty-dataが出てくるのでこれを選択します。
VPCやサブネットを適当に選び、先ほど作成したセキュリティグループをアタッチします。
VPCエンドポイントのポリシーは参考になるコードがガイドにあるのでこれをコピーして、アカウントIDだけ差し替えます。Organizationsと連携した記述の例もありました。
ここまででVPCエンドポイントの準備ができました。次にEC2にエージェントを入れます。SSM経由で導入が可能なので、これをやっていきます。
SSMドキュメントにアクセスし、AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPluginのドキュメントを開きます。
コマンドを実行します。
パラメータとして以下を入力します。
- Action:
Install - Installation Type:
Uninstall and reinstall - Name:
AmazonGuardDuty-RuntimeMonitoringSsmPlugin
ターゲットに適切なインスタンスを選択します。
これで実行を開始します。今回は14秒で完了しました。
出力はこんな感じです。さっぱりしてますね。
Initiating AmazonGuardDuty-RuntimeMonitoringSsmPlugin 1.0.0 install
Plugin aws:runShellScript ResultStatus Success
install output: Running sh install.sh
Preparing... ########################################
Updating / installing...
amazon-guardduty-agent-1.0-0 ########################################
Successfully installed AmazonGuardDuty-RuntimeMonitoringSsmPlugin 1.0.0エージェントの状態を確認します。セッションマネージャーで接続してsudo systemctl status amazon-guardduty-agentを実行すると以下のようになり、activeで問題なく動作していることが確認できました。
GuardDutyの画面でもステータスを確認できました。
それでは検出させてみましょう。ユーザーガイドにあるテスト用のドメインにクエリを投げます。
しばらくしてこれを検出しました。従来からあるBackdoor:EC2/C&CActivity.B!DNSとランタイムによるBackdoor:Runtime/C&CActivity.B!DNSの両方が検出されました。片方になるわけではないんですね。ランタイムの方では、以下のようにプロセスの詳細情報や実行ユーザーなどが確認できます。
更にLineageを確認すると親プロセスまで辿って一通りの情報が確認できます。よいですね。
まとめ
EC2のRuntime Monitoringがプレビューで出てきました。これまで確認することの出来なかったプロセスレベルの詳細な情報を取得できます。
おそらくGAになれば、エージェントの導入などもより楽になるでしょうから、楽しみですね！
12
