モジュール 4: レビューとディスカッション
最後のモジュールでは、ワークショップについて簡単に説明します(また、何が起こったのかを正確に議論します)。また、いくつかの質問に答え、ワークショップ環境をクリーンアップする方法も説明します (AWS アカウントが今後請求されないようにします)。
アジェンダ
- レビューとディスカッション – 10 分
- 質問 – 10 分
- クリーンアップ – 5 分
アーキテクチャの概要
ワークショップ全体の設定の図:
何が起こっていたのか
ワークショップのモジュール 1 で、GuardDuty、Macie および簡単な通知と修復パイプラインを含むインフラストラクチャの初期設定をしました。一部の手順では手動の設定が必要でしたが、いくつかの構成要素を設定する CloudFormation テンプレートも実行しました。モジュール 2 では、2 つ目の CloudFormation テンプレートを使って攻撃をシミュレートしました。2 つの EC2 インスタンスが作成し、1 つのインスタンス (Malicious Host) には EIP がアタッチされており、GuardDuty カスタム脅威リストに追加されています。Malicious Host は他のインスタンスと同じ VPC に存在しますが、シナリオの都合上 (さらに、侵入テストリクエストを送信しなくてもすむように)、インターネット上にあるかのように動作し、攻撃用のコンピュータを役割をしてしました。もう 1 つのインスタンス (Compromised Instance) はウェブサーバーであり、Malicious Host によって乗っ取られました。モジュール 3 では、攻撃を調査し、破損を修復し、将来の攻撃に備えていくつかの自動修復を設定しました。
攻撃時に何が起きたか
-
モジュール 2 の CloudFormation テンプレートによって 2 つのインスタンスが作成されました。それらのインスタンスは同じ VPC 内の別のサブネットにあります。Malicious Host は攻撃者を表し、インターネットに存在するものとしています。Malicious Host の Elastic IP は、GuardDuty のカスタム脅威リストにあります。もう 1 つのインスタンスは Compromised Instance という名前で、AWS にリフトアンドシフトされたウェブサーバーを表しています。
-
会社のポリシーでは、SSHは鍵ベースの認証だけを有効にする必要がありましたが、ある時点で SSH のパスワード認証が Compromised Instance で有効になりました。
この誤った設定は、GuardDuty の検出結果からトリガーされた Inspector スキャンによって特定されます。
-
Malicious Host が、Compromised Instance に対してブルートフォース SSH パスワード攻撃を実行しました。ブルートフォース攻撃は成功するように設計されています。
GuardDuty の検出結果: UnauthorizedAccess:EC2/SSHBruteForce
-
SSH ブルートフォース攻撃が成功し、攻撃者が Compromised Instance にログインできました。
ログインの成功は CloudWatch ログ (/threat-detection-wksp/var/log/secure) によって確認できます。
-
モジュール 2 の CloudFormation テンプレートによって作成された EC2 インスタンスは、データバケットのデフォルトの暗号化が無効にしました。さらに CloudFormation テンプレートによってデータバケットが外部公開されました。これは、モジュール 3 の調査の Macie の部分によって使用されます。攻撃者がバケットを公開し、バケットのデフォルトの暗号化設定を解除したようです。
Macie アラート: S3 バケット IAM ポリシーはグローバル読み取り権限を付与します。
-
Compromised Instance には、Malicious Host を継続的に ping する cron ジョブがあり、カスタム脅威リストに基づいて GuardDuty 検出結果を生成します。
GuardDuty の検出結果: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
-
API 関連の検出結果を生成した API 呼び出しは、Malicious Host からのものです。この呼び出しでは、Malicious Host で実行されている EC2 の IAM ロールからの一時認証情報が使用されています。Malicious Host にアタッチされた EIP がカスタム脅威リストにあるため、GuardDuty の検出結果が生成されます。
GuardDuty の検出結果: Recon:IAMUser/MaliciousIPCaller.Custom
GuardDuty の検出結果: UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom
-
GuardDuty の検出結果によっていくつかの CloudWatch イベントルールが呼び出され、これらのルールによって様々なサービスがトリガーされます。
- CloudWatch イベントルール: 一般的な GuardDuty 検出結果によって、SNS によるメールの送信がトリガーされる CloudWatch イベントルールが呼び出されます。
- CloudWatch イベントルール: 一般的な Macie アラートによって、SNS によるメールの送信がトリガーされる CloudWatch イベントルールが呼び出されます。
- CloudWatch イベントルール: SSH ブルートフォース攻撃の検出結果によって、NACL を介して攻撃者の IP アドレスをブロックする Lambda 関数、および EC2 インスタンスで Inspector スキャンを実行する Lambda 関数をトリガーする CloudWatch イベントルールが呼び出されます。
- CloudWatch イベントルール: Unauthorized Access Custom MaliciousIP の検出結果によって、NACL を介して攻撃者の IP アドレスをブロックする Lambda 関数をトリガーする CloudWatch イベントルールが呼び出されます。
クリーンアップ
アカウントへの請求を防ぐために、作成したインフラストラクチャをクリーンアップすることをお勧めします。ワークショップついてもう少し調べるためにそのままにしておく場合は、終了時に忘れずにクリーンアップしてください。AWS アカウントで作成したものを実行中のまま忘れてしまうと、料金が発生します。
一部のリソースは CloudFormation スタックを削除する前に手動で削除する必要があるため、以下のステップを順番通りに実行してください。
-
ワークショップ用に作成された Inspector オブジェクトを削除します。
- Amazon Inspector コンソールに移動します。
- 左のナビゲーションペインの Assessment targets (評価ターゲット) をクリックします。
- threat-detection-wksp で開始するものをすべて削除します。
-
侵害された EC2 インスタンスの IAM ロールおよび Inspector の サービスリンクドロールを削除します (このロールをまだ作成していなかった場合)。
- AWS IAM コンソールに移動します。
- Roles (ロール) をクリックします。
- threat-detection-wksp-compromised-ec2 という名前のロールを探します。
- このロールの横にあるチェックボックスをクリックし、Delete(削除) をクリックします。
- AWSServiceRoleForAmazonInspector という名前のロールに対して、このステップを繰り返します。
-
モジュール 1 の CloudFormation テンプレートによって作成された 3 つの S3 バケット (threat-detection-wksp で開始し、-data、-threatlist、および -logs で終了するバケット) をすべて削除します。
- Amazon S3 コンソールに移動します。
- 適切なバケットをクリックします。
- Delete Bucket (バケットの削除) をクリックします。
- バケットの名前をコピーアンドペーストします (これは、そのバケットを本当に削除してよいかどうかの追加の確認です)。
- 3 つのバケットすべてに対して前述のステップを繰り返します。
-
- モジュール 1 および 2 の CloudFormation スタック (ThreatDetectionWksp-Env-Setup および ThreatDetectionWksp-Attacks) を削除します。
- AWS CloudFormation コンソールに移動します。
- 適切なスタックを選択します。
- Action (アクション) を選択します。
- Delete Stack (スタックの削除) をクリックします。
- それぞれのスタックに対して前述のステップを繰り返します。
最初のスタックが削除されるのを待たずに 2 番目のスタックを削除できます。
-
GuardDuty カスタム脅威リストを削除し、GuardDuty を無効にします (ワークショップの前に GuardDuty をまだ有効にしていなかった場合)。
- Amazon GuardDuty コンソールに移動します。
- 左のナビゲーションの Lists (リスト) をクリックします。
- Custom-Threat-List で開始する脅威リストの横にある X をクリックします。
- 左のナビゲーションにあるナビゲーションペインの Settings (設定) をクリックします。
- Disable (無効化) の横にあるチェックボックスをクリックします。
- Save settings (設定の保存) をクリックしてから、ポップアップボックスの Disable (無効化) をクリックします。
-
AWS Security Hub を無効にします。
- AWS Security Hub コンソールに移動します。
- 左のナビゲーションの Settings (設定) をクリックします。
- 上のナビゲーションの General (一般) をクリックします。
- Disable AWS Security Hub (AWS Security Hub の無効化) をクリックします。
-
作成した手動の CloudWatch イベントルールと、生成された CloudWatch ログを削除します。
- AWS CloudWatch コンソールに移動します。
- 左のナビゲーションペインの Rules (ルール) をクリックします。
- threat-detection-wksp-guardduty-finding-maliciousip の横にあるラジオボタンをクリックします。
- Action (アクション) を選択し、Delete (削除) をクリックします。
- 左のナビゲーションペインの Logs (ログ) をクリックします。
- /aws/lambda/threat-detection-wksp-inspector-role-creation の横にあるラジオボタンをクリックします。
- Action (アクション) を選択し、Delete log group (ロググループの削除) をクリックしてから、ポップアップボックスの Yes, Delete (はい、削除します) をクリックします。
- 以下に対して繰り返します。
- /aws/lambda/threat-detection-wksp-remediation-inspector
- /aws/lambda/threat-detection-wksp-remediation-nacl
- /threat-detection-wksp/var/log/secure
-
SNS トピックに登録したときに作成された SNS サブスクリプションを削除します。
- AWS SNS コンソールに移動します。
- 左のナビゲーションの Subscriptions (サブスクリプション) をクリックします。
- 自分のメールアドレスがエンドポイントとして表示されているサブスクリプションで、Subscription ARN (サブスクリプション ARN) に threat-detection-wksp が含まれているサブスクリプションについて、その横にあるチェックボックスを選択します。
- Action (アクション) を選択し、Delete subscriptions (サブスクリプションの削除) をクリックします。
-
Macie を無効にします (ワークショップの前に Macie を有効にしていなかった場合)。
- Amazon Macie コンソールに移動します。
- 右上の角で、Region (リージョン) の左にある下向き矢印を選択し、Macie General Settings (Macie 一般設定) を選択します。
- 2 つのボックスを選択し、Disable Amazon Macie (Amazon Macie の無効化) をクリックします。
完了です!
このワークショップを完了しました。おめでとうございます! ここはワークショップの永続的なサイトですので、好きなときにいつでも再度アクセスしてください。