専用アカウントでの GuardDuty の検出結果のテスト
このドキュメントを使用して、AWS アカウントにデプロイされるテストリソースに対して GuardDuty の検出結果を生成するテスタースクリプトを実行します。これらのステップは、特定の GuardDuty の検出結果タイプについてと、検出結果の詳細がアカウント内の実際のリソースをどのように検索するかを理解して学習したい場合に実行できます。このエクスペリエンスは、サンプルの検出結果の生成とは異なります。GuardDuty の検出結果をテストするエクスペリエンスの詳細については、「考慮事項」を参照してください。
内容
考慮事項
先に進む前に、次の点を考慮してください。
-
GuardDuty は、専用の非本番環境 AWS アカウントにテスターをデプロイすることをお勧めします。このアプローチにより、テスターによって生成された GuardDuty の検出結果を正しく識別できます。また、GuardDuty テスターは、他のアカウントで許可されている内容を超える IAM アクセス許可を必要とする可能性のあるさまざまなリソースをデプロイします。専用アカウントを使用すると、明確なアカウント境界でアクセス許可を適切にスコープできます。
-
テスタースクリプトは、さまざまな AWS リソースの組み合わせで 100 を超える GuardDuty の検出結果を生成します。現在、これにはすべての GuardDuty 検出結果タイプは含まれません。このテスタースクリプトで生成できる検出結果タイプのリストについては、「テスタースクリプトが生成できる GuardDuty の検出結果」を参照してください。
-
GuardDuty テスターが想定どおりに機能するには、テスターリソースがデプロイされているアカウントで GuardDuty を有効にする必要があります。実行するテストに応じて、テスターは適切な GuardDuty 保護プランが有効になっているかどうかを評価します。有効になっていない保護プランでは、GuardDuty は、GuardDuty が検出結果を生成するテストを実行するのに十分な期間だけ必要な保護プランを有効にするアクセス許可をリクエストします。その後、テストが完了すると、GuardDuty は保護プランを無効にします。
- 初めての GuardDuty の有効化
-
GuardDuty が特定のリージョンで初めて専用アカウントで有効化されると、アカウントは自動的に 30 日間の無料トライアルに登録されます。
GuardDuty には、オプションの保護プランが提供されています。GuardDuty を有効にすると、特定の保護プランも有効になり、GuardDuty の 30 日間の無料トライアルに含められます。詳細については、「GuardDuty の 30 日間無料トライアルの使用」を参照してください。
- テスタースクリプトを実行する前に GuardDuty がアカウントで既に有効になっている場合
-
GuardDuty が既に有効になっている場合、テスタースクリプトはパラメータに基づいて、特定の保護プランの設定ステータスや、検出結果の生成に必要なその他のアカウントレベルの設定をチェックします。
このテスタースクリプトを実行すると、リージョンの専用アカウントで特定の保護プランが初めて有効になる場合があります。これにより、その保護プランの 30 日間の無料トライアルが開始します。各保護プランに関連する無料トライアルの詳細については、「GuardDuty の 30 日間無料トライアルの使用」を参照してください。
テスタースクリプトが生成できる GuardDuty の検出結果
現在、テスタースクリプトは、Amazon EC2、Amazon EKS、Amazon S3、IAM、EKS 監査ログに関連する次の検出結果タイプを生成します。
ステップ 1 - 前提条件
テスト環境を準備するには、次の項目が必要です。
-
Git – 使用するオペレーティングシステムに基づく git コマンドラインツールをインストールします。これは、
amazon-guardduty-tester
リポジトリのクローンを作成するために必要です。 -
AWS Command Line Interface – コマンドラインシェルでコマンドを使用して AWS のサービスとやり取りするためのオープンソースツールです。詳細については、「AWS Command Line Interface ユーザーガイド」の「Get started with AWS CLI」を参照してください。
-
AWS Systems Manager –AWS CLI を使用してマネージドノードとの Session Manager セッションを開始するには、ローカルマシンに Session Manager プラグインをインストールする必要があります。詳細については、「AWS Systems Manager ユーザーガイド」の「AWS CLI 用の Session Manager プラグインをインストールする」を参照してください。
-
Node Package Manager (NPM) — NPM をインストールして、すべての依存関係をインストールします。
-
Docker – Docker がインストールされている必要があります。インストール手順については、Docker のウェブサイト
を参照してください。 Docker がインストールされていることを確認するには、次のコマンドを実行し、次のような出力があることを確認します。
$ docker --version Docker version 19.03.1
-
AWS Marketplace で Kali Linux
イメージをサブスクライブします。
ステップ 2 - AWS リソースをデプロイする
このセクションでは、主要な概念のリストと、特定の AWS リソースを専用アカウントにデプロイする手順について説明します。
概念
次のリストに、リソースのデプロイに役立つコマンドに関連する主要な概念を示します。
-
AWS Cloud Development Kit (AWS CDK) – CDK は、コードでクラウドインフラストラクチャを定義し、AWS CloudFormation を通じてプロビジョニングするための、オープンソースのソフトウェア開発フレームワークです。CDK は、いくつかのプログラミング言語をサポートして、コンストラクトと呼ばれる再利用可能なクラウドコンポーネントを定義します。これらをまとめてスタックとアプリケーションに構成できます。その後、CDK アプリケーションを AWS CloudFormation にデプロイして、リソースをプロビジョニングまたは更新できます。詳細については、「AWS Cloud Development Kit (AWS CDK) 開発者ガイド」の「What is the AWS CDK?」を参照してください。
-
ブートストラップ — AWS CDK で使用するために AWS 環境を準備するプロセスです。CDK スタックを AWS 環境にデプロイする前に、まず環境をブートストラップする必要があります。AWS CDK が使用する環境内の特定の AWS リソースをプロビジョニングするこのプロセスは、次のセクション「AWS リソースをデプロイする手順」で実行する手順の一部です。
ブートストラップの仕組みの詳細については、「AWS Cloud Development Kit (AWS CDK) 開発者ガイド」の「Bootstrapping」を参照してください。
AWS リソースをデプロイする手順
リソースのデプロイを開始するには、次の手順を実行します。
-
専用アカウントのリージョン変数が
bin/cdk-gd-tester.ts
ファイルで手動で設定されていない限り、AWS CLI デフォルトのアカウントとリージョンを設定します。詳細については、「AWS Cloud Development Kit (AWS CDK) 開発者ガイド」の「Environments」を参照してください。 -
以下のコマンドを実行して、リソースをデプロイします。
git clone https://github.com/awslabs/amazon-guardduty-tester && cd amazon-guardduty-tester npm install cdk bootstrap cdk deploy
最後のコマンド (
cdk deploy
) は、ユーザーに代わって AWS CloudFormation スタックを作成します。このスタックの名前は GuardDutyTesterStack です。このスクリプトの一部として、GuardDuty はアカウントに GuardDuty の検出結果を生成する新しいリソースを作成します。次のタグキーと値のペアも、Amazon EC2 インスタンスに追加されます。
CreatedBy
:GuardDuty Test Script
また、Amazon EC2 インスタンスには、EKS ノードと ECS クラスターをホストする EC2 インスタンスも含まれます。
インスタンスのタイプ
GuardDuty は、Amazon EKS ノードグループを除くすべてのリソースに対して
t3.micro
を作成します。EKS には少なくとも 2 つのコアが必要なため、EKS ノードにはt3.medium
インスタンスタイプがあります。インスタンスタイプの詳細については、「Amazon EC2 Instances Types Guide」の「Available sizes」を参照してください。
ステップ 3 - テスタースクリプトを実行する
これは 2 ステップのプロセスであり、まずテストドライバーでセッションを開始し、次にスクリプトを実行して特定のリソースの組み合わせで GuardDuty の検出結果を生成する必要があります。
-
リソースをデプロイしたら、リージョンコードを現在のターミナルセッションの変数に保存します。次のコマンドを使用し、
us-east-1
はリソースをデプロイしたリージョンコードに置き換えます。$ REGION=
us-east-1
-
テスタースクリプトは AWS Systems Manager (SSM) を通じてのみ使用できます。テスターホストインスタンスでインタラクティブシェルを起動するには、ホストの InstanceId をクエリします。
-
次のコマンドを使用してテスタースクリプトのセッションを開始します。
aws ssm start-session --region $REGION --document-name AWS-StartInteractiveCommand --parameters command="cd /home/ssm-user/py_tester && bash -l" --target $(aws ec2 describe-instances --region $REGION --filters "Name=tag:Name,Values=Driver-GuardDutyTester" --query "Reservations[].Instances[?State.Name=='running'].InstanceId" --output text)
テスタースクリプトは、入力に基づいて検出結果を生成する Bash スクリプトを動的に構築する Python ベースのプログラムです。1 つ以上の AWS リソースタイプ、GuardDuty 保護プラン、脅威の目的 (戦術)、基礎データソース、またはテスタースクリプトが生成できる GuardDuty の検出結果に基づいて検出結果を生成する柔軟性があります。
次のコマンド例をリファレンスとして使用し、1 つ以上のコマンドを実行して、調査する検出結果を生成します。
python3 guardduty_tester.py python3 guardduty_tester.py --
all
python3 guardduty_tester.py --s3
python3 guardduty_tester.py --tacticsdiscovery
python3 guardduty_tester.py --ec2
--eks
--tacticsbackdoor
policy
execution
python3 guardduty_tester.py --eks
--runtime
only python3 guardduty_tester.py --ec2
--runtime
only --tacticsimpact
python3 guardduty_tester.py --log-sourcedns
vpc-flowlogs
python3 guardduty_tester.py --finding 'CryptoCurrency:EC2/BitcoinTool.B!DNS
'
有効なパラメータの詳細については、次のヘルプコマンドを実行して確認できます。
python3 guardduty_tester.py --help
アカウントで生成された検出結果を表示する任意の方法を選択します。
ステップ 4 - AWS テストリソースをクリーンアップする
「ステップ 3 - テスタースクリプトを実行する」で行われたアカウントレベルの設定やその他の設定ステータスの更新は、テスタースクリプトの終了時に元の状態に戻ります。
テスタースクリプトを実行したら、AWS テストリソースをクリーンアップすることを選択できます。これを選択するには、次のいずれかの方法を使用します。
-
次のコマンドを実行します。
cdk destroy
-
GuardDutyTesterStack という名前の AWS CloudFormation スタックを削除します。手順の詳細については、「AWS CloudFormation コンソールでのスタックの削除」を参照してください。
よくある問題に対するトラブルシューティング
GuardDuty はよくある問題を特定し、トラブルシューティングのステップを推奨しています。
-
Cloud assembly schema version mismatch
– AWS CDK CLI を、必要なクラウドアセンブリバージョンと互換性のあるバージョン、または利用可能な最新バージョンに更新します。詳細については、「AWS CDK CLI 互換性」を参照してください。 -
Docker permission denied
– 専用アカウントでコマンドを実行できるように、専用アカウントユーザーを docker-users に追加します。手順の詳細については、「Docker access denied」を参照してください。 -
Your requested instance type is not supported in your requested Availability Zone
– 一部のアベイラビリティーゾーンは特定のインスタンスタイプをサポートしていません。希望のインスタンスタイプをサポートするアベイラビリティーゾーンを特定し、AWS リソースのデプロイを再試行するには、次の手順を実行します。-
任意の方法を選択して、インスタンスタイプをサポートするアベイラビリティーゾーンを確認します。
-
AWS リソースのデプロイを再試行し、希望のインスタンスタイプをサポートするアベイラビリティーゾーンを指定します。
AWS リソースのデプロイを再試行するには
-
bin/cdk-gd-tester.ts
ファイルでデフォルトリージョンを設定します。 -
アベイラビリティーゾーンを指定するには、
amazon-guardduty-tester/lib/common/network/vpc.ts
ファイルを開きます。 -
このファイルでは、
maxAzs: 2,
をavailabilityZones: ['
に置き換え、ここでインスタンスタイプのアベイラビリティーゾーンを指定する必要があります。us-east-1a
', 'us-east-1c
'], -
「AWS リソースをデプロイする手順」の残りの手順を続行します。
-
-