Amazon GuardDuty のアラートテスト用検証環境の構築方法 - part2【環境構築・実行編】
セキュリティ対策で知らない人はいないと思う、AWS マネージド型脅威検出サービスの 「Amazon GuardDuty」 。
今回は前回の【事前準備・構成確認編】に引き続き、実際に Amazon GuardDuty のアラートテスト用環境を構築していこう！という記事になります！
再掲となりますが、作成していくのは以下の GitHub リポジトリ環境です。
では早速、前回の記事の前提条件が確認済みという認識で構築を進めていきましょう！
Step1 - CloudFormation でスタックを作成
まず初めに、リポジトリ内にあるGuardduty-tester-template.yamlのファイルから、CloudFormation スタックを作成していきます。
CloudFormation で設定するパラメータは以下の3つです。
- スタックを識別するスタック名
- スタックを実行するアベイラビリティーゾーン（AZ）
- EC2 インスタンスの起動に使用するキーペア
キーペアは前回の【事前準備・構成確認編】の事前準備で用意したものとなります。
パラメータ設定が完了したら、スタック作成を進めていき、リソースを立ち上げていきましょう！
あとは処理が無事に完了するまで待ちます！ 時間は約10～15分ほど掛かるかと思います。色々リソースを作成するのでそれなりに時間が掛かりますね。
その間は暇になるので、かわいい動物の癒し動画を見て、できるだけストレス解消に励みましょう！（孤独になりがち？なエンジニアにとってはストレス大敵）
さて、無事にリソース作成が完了したら、以下のようにステータスが「CREATE_COMPLETE」になります。
なお、リソース作成中に何かしらエラーが生じるかもしれません。CloudFormation のパラメータ設定で、AZ を設定していなかったり、CIDR が衝突してしまっていたりするので、随時「リソース」タブからエラー情報を確認していきましょう。
Step2 - 「RedTeam」の プライベート IP アドレス情報の取得
リソース作成が完了したら、「RedTeam」の プライベート IP アドレス の情報を取得しておきます。
EC2 コンソール画面から「RedTeam」で絞り、「プライベート IPv4 アドレス」の情報を取得しましょう。
Step3 - EIC（EC2 Instance Connect）の接続設定
さて、IP アドレスの取得ができたら次のステップです。
今回は接続をコンソール上で完結させたいため、EC2 接続用の EIC（EC2 Instance Connect）エンドポイントを作成していきます。
（※もしターミナルで SSH 接続が良い方はこちらを飛ばしていただいて大丈夫です！）
作成手順は以下の記事を参考に作成していきます！（※作成手順はこの記事では割愛）
ここを失敗してしまうと次のステップの踏み台（Bastion）接続ができなくなってしまうので、念入りにチェックしておきましょう！
なお、EIC エンドポイントはインターフェイス型ですが、無料で利用できます。すごく便利ですね！（2024年3月現在）
Step4 - EC2「LinuxBastion」に接続
EIC エンドポイントの作成ができたら、次は EC2「LinuxBastion」に接続し、環境内に入ります。
コンソールから EC2 を選択後、「接続」ボタンをクリックします。
画面が遷移したら、先ほど作成した EIC エンドポイントを選択した後、「接続」ボタンをクリックします。
そのあと、環境内に入れたら問題ないです！
Step5 - 「~/.ssh/」にキーペアを保存し、EC2「RedTeam」に接続
次に、作成したキーペアを「~/.ssh/」配下に保存します。
保存が完了したら、今度は以下のコマンドで EC2「RedTeam」に接続していきます。
$ sudo ssh -i ~/.ssh/keypair-name.pem ec2-user@[RedTeam のプライベート IP]
以下のように EC2「RedTeam」の環境内に入れていれば OK です！
Step6 - 「guardduty_tester.sh」ファイルの実行
EC2「RedTeam」の環境内に入れたら、最後「guardduty_tester.sh」ファイルの実行をします。
ディレクトリはそのままで、以下のコマンドを実行してみましょう。
$ ./guardduty_tester.sh
すると、ファイルが動き出すかと思います。
あとは、実行完了するまで待ちましょう！ おおよそ1分程あれば完了するかと思います。
Step7 - 「GuardDuty」でアラート確認
最後に、「GuardDuty」の検出結果でアラートを確認してみましょう！
無事にアラート発火がされたことが確認できましたね！
もしこのアラートを EventBridge 経由で Teams や Slack 通知をしていたり、SIEM on OpenSearch などでログ調査をしている環境であれば、タイムラグはあれど反映されるかと思います！
まとめ
今回は GuardDuty でのアラートテスト用環境の構築・実行手順をご紹介しました！
GitHub リポジトリでは「ssh tester」を実行するとありましたが、今回は EIC エンドポイントを使用したこともあり、使わずに実行する方法となりました。エンドポイントの便利さも再認識できましたね！
なお、前回の記事でもお伝えしましたが、NAT Gateway が継続的にコスト発生してしまいます。リソース削除はお早めにしておきましょう。
今回の記事が GuardDuty のリアリティあるアラートテストを探している方の参考になれば幸いです！
Discussion