この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、JAWS-UG楽しんでますか？(挨拶
今回は年に1回のJAWS最大のお祭りであるJAWS DAYS 2022に登壇したのでその資料を共有しつつ、いろんな思いを語っていきます。
動画
資料
解説
思いつき
以前行われたJAWS PANKRATION 2021にて、下記内容の登壇を行いました。
この時はグローバル向けのイベントで、翻訳しながらツンデレなAmazon GuardDutyについて語るという難易度の高いことをやったため、内容は割と薄めでした。
JAWS DAYSでもたまにはもっとオタク向けの尖ったセッションをやりたいなーと思い、最新のGuardDuty攻略情報をまとめることにしました。
怒られないか心配なレベルの内容に仕上げてしまったので、よほど反響が良くない限り次回はやりません。
以下の内容はほとんどネタなので、マジレスしないでくださいね☆ミ
恋愛シミュレーションゲームの攻略対象としてのGuardDuty
GuardDutyは俺の嫁です。GuardDuty is my wife.
ちなみにAWS Security HubやAmazon Detectiveも俺の嫁です。
GuardDutyはかわいいですよね。リクエストを送るたび検知してくれたり、してくれなかったりするところがまたツンデレでいいですよね？
つまりそういうことです。
あとは動画を見てくれ
あ、私は彼女と表現していますが、もちろん彼と読み替えていただいてもいいです。脳内補完してください。
セッションレベル400
今回JAWS DAYSのCfPにはセッションレベル400(最高)で申請しました。
なぜか私のセッション以外400がなかったですが、タイムテーブルを眺めていると良いセッションがいっぱいあります。ぜひ良いセッションは自身を持って400で申請してほしいなーと、個人的には思いました。
コワクナイヨ！
真面目な話を見たい方
過去にはちゃんと真面目な話をしているので、そちらを見てください。
JAWS DAYS以外では下記も合わせてどうぞ。
1. 過去の攻略情報
前述したこちらのブログを見てくれ。
今回はこちらの続きとして、かわいくてツンデレなGuardDutyについて語っています。
AWSは攻略対象のルート(機能)がどんどん追加される、まるでクラウド恋愛シミュレーションゲームであり、永遠とシナリオが配布されるんですね。
攻略し続けるのは根気がいりますが、みんなで頑張って攻略しましょう。
2. 新ルート1: 迫真の裏技封じ
2022年1月にUnauthorizedAccess:IAMUser/InstanceCredentialExfiltrationのFinding Typesが強化されました。詳細は下記ブログ。
かいつまんで説明します。
まずはこのアップデート以前の説明から。従来から、アプリケーションに内在するSSRFなどの脆弱性により、EC2インスタンスのクレデンシャルが漏洩してしまい、これを悪用して該当AWS環境にアクセスする手法がありました。InstanceCredentialExfiltrationはこの動きを検知します。本来AWSの中から(EC2から)使用されるクレデンシャルがAWS外のIPから利用されていることで検知をしていました。
一方で、この検知には裏技があり、攻撃者が用意したAWSの環境から利用されると、AWSのIPであるため、検知を逃れるという手法でした。下記図ではAWSとGCPからアクセスしていますが、従来この場面ではGCP側は検知できて、AWS側は検知できませんでした。
実はこの仕様に以前苦しめられたことがあり、下記イベントではGCPから攻撃するというシナリオに変更しました。(GCPは何も悪くない)
今回のアップデートで従来からある検知をUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWSと末尾に.OutsideAWSが追加され、別のAWSアカウントで利用された場合にUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWSと末尾に.InsideAWSがついたFindings Typeが新しく追加されました。
GuardDutyはきっとこんな感じのセリフになるでしょう。
GuardDuty「裏技で逃れようとしたってそうは行きませんよ…」
これで裏技を使うような不埒な輩も一網打尽ですね。AWS運営の本気が現れています。
InstanceCredentialExfiltration.InsideAWSでは新しいパラメータとしてremoteAccountDetailsが追加されています。
利用されたAWSアカウントIDが確認できるので、このアカウントに見覚えがあるかが確認ポイントです。
誤検知のパターンとしては、マルチアカウント環境でTransit GatewayやVPC Peeringなどでネットワークが繋がっていて、別AWSアカウントからVPC Endpoint経由でAPIを実行している場合などに、通常とは異なるアカウントからAPIが実行されるため発生します。このように関連するAWSアカウントの場合はパラメータのAffiliatedがtrueになるので、これも判断する一助になります。
もし知らないAWSアカウントであれば、ぜひ通報してください。オンラインゲームで不正なユーザーを発見したら通報するのが適切ですよね。
AWSアカウントに紐付いている事象なのでAWSサポート等により問い合わせいただくといいですが、Report Amazon AWS abuse(不正利用の報告窓口)もありますので合わせてご検討ください。
InstanceCredentialExfiltration.InsideAWSルート攻略方法
彼女に振り向いてもらう(検知させる)方法は、下記のかんたん2ステップです。
- EC2からクレデンシャルを取得
- 別AWS環境でクレデンシャルを利用
まずはEC2にアクセスしてクレデンシャルを取得します。事前にEC2にIAM Roleをアタッチしておきましょう。クレデンシャルは色んな方法で取得できますが、下記ワンライナーを作りましたのでぜひご活用ください。
つづいてこれを別のAWS環境から利用します。CloudShellでexoprtして使うのが一番手っ取り早いと思います。
aws s3 lsなどしておくとよく検知してくれますので、合わせてコールしておきましょう。この際に権限があるかは関係ありません。
3. 新ルート2:嫁の新しい側面を垣間見る
時は2022年7月、新機能としてMalware Protectionが実装されました。待望の機能です。
ただ、名前とは違って実動作は検知です。マルウェアを止めることは現状できません。
実は、このリリースが出そうだ、というのはGuardDutyの様子を眺めていて気づいてました。2021年11月には、レスポンスにその鱗片が見えていたのです。
日頃から気になるあの子のことはよく観察しておく必要がありますね。攻略の基本です。
この機能はトリガーが別のGuardDuty検知なので、まずこれらをトリガーする必要があります。このあたりは新しい挙動ですね。
以下のような感じで動作します。
トリガーされるとスナップショットを取得して、そこから作成したEBSに対してスキャンされるので、実環境に影響がないです。すてき。
マルウェアが検知されるとGuardDuty上では以下のように詳細情報が確認できます。マルウェアの種類やファイルパス、ファイル名などが確認できます。こちらの例では、Cryptominingとコインマイニングのマルウェアであることや/home/ec2-user配下に存在していたことがわかりますね。
ちなみに画像下側はtar.gzの中身から検知している例で、きちんとアーカイブまで見てくれるのも加点ポイントです。
検知した内容の詳細フォーマットはこちらのユーザーガイドにあります。彼女のことをよく知りたければ、細部まで確認しておきましょう。
マルウェアスキャンの何が嬉しいのか？
Malware Protection機能はマルウェアを検知しても止めることはできません。「検知までなのに何が嬉しいの？」と思う方もいると思うので説明します。
まず、これまでのGuardDutyのイベント検知時の挙動はこうでした。
GuardDuty「このEC2怪しいよ！調べて！」
健気にAWSのログを全部集めてチェックしながら、不審な挙動を逃さず教えてくれるという素晴らしい動き、天使ですね。すき。
でもこの検知の後の運用はこうです。
あくまでVPC Flow LogsやDNS Logsをベースにした検知であるため、EC2内部が実際にどのような状況であるか調査する必要があります。過検知ではないのか？という確認ですね。
そもそも各EC2インスタンスにはマルウェア保護の機能を入れておくのが最適解であり、責任共有モデルとしても一番正しい運用です。その場合、過検知か確認するフェーズはありません。マルウェア保護機能ですでに詳細がわかっているからです。そして本当に危険であれば、挙動がブロックされマルウェアが隔離されているでしょう。
余談ですが、TrendMicroのWorkload Securityちゃんもすごく良いのでおすすめです。マルウェア保護だけでなくIPSやアプリケーション保護などEC2インスタンス上で多層防御できる神対応です。しかも従量課金で利用できてコスパ最強。詳しくは下記をご確認ください。
しかし実際にはコストとリスクを勘案して(あるいは軽視して)マルウェア保護機能が導入されていないから、EC2タイプの検知が発生します。
そのため検知されたEC2上でマルウェアスキャンを実施する必要があるんですね。どうやって？というところですが、もともとマルウェアスキャンのソフトウェアなどが入っていないので、それを調達してくる必要があります。すぐに必要な時、有償のものを用意するのは大変です。大体は無償のツールを一旦導入して確認します。そして、検知されなかったらOKでしょうか？無償のツールで「検知されなかったからOK」とは言いづらいでしょう。
つまり大変なんですね。
というわけでようやくMalware Protectionの出番です。これからのGuardDutyでEC2の怪しい挙動を検知した場合の動きはこうです。
GuardDuty「このEC2怪しかったからスキャンしておいたぜ」
やだイケメン…///
これはほれてまうやろー！
ん？イケメン？
つまりGuardDutyは、かわいくて俺の嫁でツンデレでイケメンということだ！
「どういうことなの…」と思ったそこのあなた。
Malware Protectionルート攻略方法
こちらの攻略もかんたん2ステップです。(もしかして、一回ルート入るとデレデレタイプなのかしら？)
- 検知されるマルウェアをEC2に仕込む(フラグを立てる)
- 対象EC2が検知されるイベントトリガーを引く(ルート分岐)
ちゃんとフラグ立てておかないとルート分岐できないということですね。
マルウェアを仕込むのは何でも良いんですが、eicarを入れてもらうのが一番手っ取り早いでしょう。
私はちょっと味気ないなーと思ったので、下記を利用しています。
仕込んだらイベントトリガーを引きます。先程掲示したタイプの検知であれば何でも良いです。上記ブログでは検知まで紹介していますのでそうしてもいいですし、GuardDutyのテスト用ドメインにnslookupなりdigなりしてもらってもいいです。対象はguarddutyc2activityb.comでこちらに紹介されています。
おまけ: 攻略別回答
実はこの攻略方法の他にも、公式から自動化された攻略ルートが提供されています。
私は、クエストが自動で消化されるタイプのゲームは好きじゃないので、ぜひ手動でやっていただくことをおすすめしますが。やはり手動で動かしながら細部の挙動を確認していくことが彼女の理解に繋がりますから、あえてそれを自動化してすすめることもルートに対する侵害というかせっかくシナリオがあるのにそれをすっ飛ばして台無しにするのも良くないと思いますのでちゃんとゆっくりじっくり自分の手で味わっていくべきだと思うんです、ええ。
そもそも自動で勝手にできてしまってはなんのために攻略しているんだよって話ですよね？こっちはその過程を楽しみにしているわけであって結果だけ求めるのであればそもそもそういった提供をしなければいいだけの話なのであえて手動と自動の両方を用意しておく意味がわからないですよね。
と私はあまり好みではありませんが、こちらのamazon-guardduty-testerというリポジトリで公開されていますので気が向いたらどうぞ。
私は1つ1つ手動でやるほうが良いと思うんですけどね。
Malware Protectionで検知されるFinding Types
Malware ProtectionのイベントトリガーとしていくつかのFinding Typesがありますが、イベントが引かれ実際にマルウェアが検知された場合には新たに別のFindingsが出力されます。そのFinding Typesは下記8種類です。
- Execution:EC2/MaliciousFile
- Execution:ECS/MaliciousFile
- Execution:Kubernetes/MaliciousFile
- Execution:Container/MaliciousFile
- Execution:EC2/SuspiciousFile
- Execution:ECS/SuspiciousFile
- Execution:Kubernetes/SuspiciousFile
- Execution:Container/SuspiciousFile
ざっくり2 x 4種類で、後ろがMaliciousFileになっているものはマルウェア、SuspiciousFileのものはスパイウェアやアドウェアなどを検知した場合です。
そして注目ポイントはECS / Kubernetes / Containerのところ。コンテナにも対応しているんですね。
しかしぬか喜びしてはいけません。ユーザーガイドには下記のように書かれています。
Fargateに対応していないのです。かなしみ。
「でも、新機能だし、まだ対応してないのは仕方ないよね？」
「流石にそのうち対応するでしょ」
と、そう思っていませんか？
…
……
………
甘えないでください！
AWSはフィードバックが全て。みんなで要望を送りまくるのです！
「そのうち」「誰かが」と他人任せにしてはいけません。あなたが欲しいと思うなら、それはあなたがリクエストすべきです。
AWSはフィードバックが多ければガンガン対応します。票数は正義です。
Twitterでつぶやくのも悪くありませんが薄いです。「誰か拾って(/ω・＼)ﾁﾗｯ」ということです。意味がありません。もちろん周知という意味はありますがフィードバックには繋がりません。
フィードバック先はAWSサポートやTAM(あれば)です。なによりユーザーからの声が一番届きます。ほしいと思ったそこのあなた、ぜひフィードバックをお願いします。
ところで、
フィードバックするのってなんだかゲームのアンケートハガキみたいですね。私は世代じゃないのでしらんけど
あるいは、
ソーシャルゲームの全員参加型イベントで、ゲーム全体のルート選択をしているみたいですよね？自分好みの選択を選んでヒロインを育てよう、的な。自分色に染まっていくのっていいですよね。
まあAWS全体がそういう性質ですが。
まとめ
- Amazon GuardDutyはかわいくて俺の嫁でツンデレでイケメン
- 全員でルート選択しよう
- 無限に続くこのゲームにみんな参加しよう
12
