サイト内の現在位置

AWS環境での疑似インシデントレスポンス

NECセキュリティブログ

2020年12月18日

NECサイバーセキュリティ戦略本部セキュリティ技術センターの山田です。近年、AWSやAzureと言ったクラウドサービスを用いたシステム開発、運用が広がっています。クラウドサービスを利用することによって、リソース量を柔軟に変更できる、マネージドサービス利用によって運用負担が減るなど様々なメリットを受けることができます。一方、クラウドサービス利用によるインシデントも発生しています。今回は、過去事例を参考に作成した疑似インシデントを用いて、AWS利用時の注意点をご紹介します。

ケース1

あるEC2インスタンスのメンテナンス用の入り口に対し、インターネット上から大量のログイン試行(リモートデスクトップ接続)があったことが確認できました。不正なログイン試行が行われたEC2インスタンスと、その原因となった設定を突き止めてください。

このケースではまず、不正なログイン試行が行われたEC2インスタンスを特定するためにCloud Watch LogsにてVPCフローログを確認します。VPC(Virtual Private Cloud)は、AWSで利用可能な論理的に分離されたネットワークセクションであり、VPCフローログ機能を利用することで、VPC内のネットワークインターフェースを行き来するトラフィック情報をキャプチャすることが可能です。 new window [1]

今回はリモートデスクトップ接続によるログイン試行が発生したことが判明しているので、下記のようにフィルターを設定し宛先ポート”3389”となっているログを表示します。

[version, account, eni, source, destination, srcport, dstport="3389", protocol, packets, bytes, windowstart, windowend, action, flowlogstatus]

絞り込み結果を確認すると、ある外部のIPから10.0.0.199の3389ポートへの通信が繰り返し行われています。ここから10.0.0.199のIPを持つEC2インスタンスが今回ログイン試行を行われたと判断できます。

次に、このような不特定多数のログイン試行を防止するためにEC2の設定確認を行います。外部からの接続を防止したいため、当該EC2のネットワークセキュリティグループを確認すると、3389ポートへの通信がソースIP 0.0.0.0/0 で許可されていました。

今回は、3389ポートへの許可ソースIPをXX.XX.XX.XX/32と変更することで、RDP接続をメンテナンス用端末に絞り、第三者からの接続をブロックするよう設定します。

設定変更後再度ログを確認すると、EC2インスタンスへの3389ポートへの通信がREJECTされており、ログイン試行を防げていることが分かります。

今回のケースでは、外部からの通信をネットワークセキュリティグループにて適切に制御していないために不正なログイン試行をされてしまいました。運用時の利便性を優先し、通信許可ポートや接続元IPを広く許可しておくことは、第三者による不正アクセスも容易にしてしまい、重大インシデントに繋がりやすくなります。
セキュリティグループではインバウンド/アウトバウンド先を必要最低限に絞り込む。それが難しい場合は公開鍵認証の強制、デフォルトユーザの無効化、複雑なパスワードを設定するなどの堅牢化が必要です。

ケース2

あるS3バケット上に保管していたデータが削除されていることが発覚しました。ログを確認しましたが、データが存在していた時点からデータ削除が確認できた時点の間は、当該アカウントIDでログインしているユーザはいませんでした。データが削除された原因について突き止めてください

このケースでは、当該アカウントIDでのデータ削除ではないということから、外部ユーザからS3バケット上のファイルが削除されたことがわかります。EC2へのアクセスをネットワークACL、ネットワークセキュリティグループで制御できるように、S3も外部への公開が可能なのでS3の設定を確認します。
S3の外部への公開は、主にバケットポリシーとACLにて設定されます。 new window [2] [3]
このケースでは、バケットポリシーはCloud Trailの証跡作成関連のみ許可されていましたが、ACLに外部アカウントに対しオブジェクトの書き込み権限が付与されていました。
これにより、外部ユーザにファイルを削除されてしまったのです。

S3バケットの外部アカウントとの共有は、開発環境から本番環境への移行や、外部組織とのリソースの共有を容易にしてくれます。しかし、権限の過剰な付与、不要になった共有設定の残存、誤った共有先の指定など、インシデントに繋がる穴にもなりやすい設定ですので注意が必要です。
また、今回は説明を省略しましたが、S3バケット上のファイル追加、削除などのログはCloud Trailのデフォルト設定では取得されないことにも注意が必要です。 new window [4]何かあった時にログがなく原因究明ができないということがないように、ログの取得範囲を定め、設定をすることも大切です。

まとめ

今回は、AWS上でのインシデント事例を用いてAWS利用時の注意点をご紹介しました。クラウドでは重要な設定変更や、様々なリソースの共有をWebコンソール上の簡単な操作で行うことができます。今回ご紹介した事例以外にも、リソースの共有設定のミスや、クレデンシャル情報の漏洩など様々なインシデントが発生しており、クラウドサービスを最大限活用するためにもセキュリティ面に気を付ける必要があります。みなさんも、今一度クラウドサービスを適切に利用できているか見直してみてはいかがでしょうか。