概要
この連載コラム「エンジニアの羅針盤 – 技術と実践の探求」では、変化の激しいIT業界において、エンジニアが日々の業務で直面する様々な課題や、より効率的かつ高品質な開発を実現するための知見を幅広く共有します。アジャイル開発やDevOpsといった開発手法から、データ基盤、セキュリティ、テスト、生産性向上まで、現場で培われた実践的なノウハウ、最新技術の活用事例、そしてキャリアパスまで、多岐にわたるテーマを深掘りしていきます。読者の皆様が自身の技術力を高め、より良い開発を実現するための一助となれば幸いです。
はじめに
2024年1月17日（水）に開催されたAWS主催のワークショップイベント「AWS SECURITY INCIDENT GAME DAY」に参加しました。
本コラムでは、参加者の視点から、この実践的なイベントの様子を詳しくご紹介します。
ワークショップの概要
このワークショップは、Webセキュリティに関する実践的なイベントであり、セキュリティインシデントが発生した際の対応を体験することに主眼が置かれていました。具体的には、以下の内容に取り組みました。
AWS上に構築されたサービスに対して、実際にいくつかのセキュリティ攻撃が発生したシナリオを想定。
ログを詳細に解析することで、攻撃の原因や被害範囲を特定。
ハッカーの手口を想定したシナリオに沿って用意されたクイズを、チームメンバーと協力して解決。
今回のワークショップの目的は、「AWS環境におけるアクセスログなどを分析し、ハッカーの攻撃方法や影響範囲を特定する」ことでした。
環境・サービス
ワークショップで使用したAWSの環境とサービスについてご紹介します。
環境
今回利用したAWSの環境はこちらです。
AWS 構成
簡単に説明すると、クラウド上のサーバー（EC2）にサービスが稼働していて、後ろにデータベース（DynamoDB）とストレージ（S3）が置いてあるAWSでサービスを作るとよくある感じの構成です。アクセスログを取得するため、AWS WAFというサーバーへのアクセスを監視するサービスをEC2に設定してあります。
ログ
今回は、以下のサービスを利用してアクセスログを取得します。
・CloudTrail
AWSの各種ユーザー、ロール、サービスによって実行されたアクションをログとして収集することができる。
・GuardDuty
攻撃と思われる通信や操作を機械学習によって検出することができる。
・Security Hub
GuardDuty等のAWSセキュリティサービスを一元管理することができる。
・VPC Flow Log
AWS VPC ネットワークインターフェースのトラフィックをキャプチャする。
さらに、サーバー（Apache）の機能で取得しているログも分析に利用します。
ツール
今回ログを分析するために使ったツール「OpenSearch Dashboard」について簡単に紹介します。
OpenSearch Dashboard
OpenSearch は、リアルタイムのアプリケーションモニタリング、ログ分析、ウェブサイト検索などの幅広いユースケースにご利用いただける分散型、コミュニティ主導型、Apache 2.0 ライセンス、100% オープンソースの検索および分析スイートです。OpenSearch は、統合された視覚化ツールである OpenSearch ダッシュボードを使用して、大量のデータへの高速アクセスと応答を提供するための高度にスケーラブルなシステムを提供します。
上は公式のOpenSearchの説明ですが、簡単に言うとAWSの各サービスごとのログをまとめて様々なパラメータで検索したり分析できるツールです。
インシデント
それでは、実際のインシデントを見て影響範囲を特定していきます。今回想定されているシナリオは、サーバーへの総当たり攻撃（他人のパスワードを悪用するために、大量のパターンのパスワードを試行する攻撃）です。以下のような流れでログを分析します。
1.GuardDutyで検出された「SSHBruteForce」に関するログを分析
2.送信元IPおよび送信先のポートを特定
3.インスタンスへのアクセスログに対して、先ほど特定したIPアドレスからのログを分析
4.通信に失敗しているログを検索
5.通信に成功しているログを検索
GuardDutyで検出された「SSHBruteForce」に関するログを分析
流れの一番最初ではありますが、今回利用するGuardDutyは、総当たり攻撃っぽいぞ？と言うものを自分で判断してお知らせしてくれます。よって、自分で大量のアクセスログを見てどのログが攻撃なのかというのを判断しなくても、ある程度当たりをつけてくれるというわけです。
GuardDutyのログで、Typeが「UnAuthorzedAccess:EC2/SSHBluteForce」となっているものがGuardDutyが総当たり攻撃っぽいと判断したログです。今回はこれについて分析していきます。
送信元IPおよび送信先のポートを特定
先ほどのログを確認して、どこから攻撃されたか、どこへ攻撃されたか、を判断していきます。
アクセスログの「source.ip」を見ると、アクセス元のIPアドレスがわかります。また、「destination.port」を見ることで、アクセスされたポート番号がわかります。今回はsource.ipが「1.13.160.64」、destination.ipが「22」です。
インスタンスへのアクセスログに対して、先ほど特定したIPアドレスからのログを分析
GuardDutyはサーバーへのアクセスが成功したかどうかを判断できないので、実際にパスワードが漏洩してしまったかどうかを分析するためには、サーバー自体に記録されているアクセスログを見る必要があります。
上の手順でアクセス元のIPとアクセス先ポートを把握できたので、それについてのアクセスログを検索します。
通信に失敗しているログを検索
総当たり攻撃は、適当なパスワードを大量に試行するいわゆる「数打ちゃ当たる」戦法です。つまり、この大量のアクセスの中でパスワードを使って認証が成功しまうと、そのパスワードを使えるぞ！となって悪用されてしまうわけです。
とりあえず通信に失敗しているログを検索してみます。上の結果では、795件のログが検索できました。つまり、攻撃者は795回の適当なパスワードを試行してきたと言うことがわかります。
通信に成功しているログを検索
最後に、通信に成功したログを検索します。検索結果としては0件だったので、上の795件のアクセスは全て失敗、つまり「パスワードは漏洩していない」と言うことがわかりました。ひとまず安心ですね。
インシデントまとめ
と言うことで、以上で分析したことをまとめるとこうなります。
攻撃方法：総当たり攻撃
攻撃元：IPアドレス 1.13.160.64
影響範囲：特になし（攻撃失敗）
当日のワークショップでは他にも様々な攻撃があり、上のように分析を行って攻撃方法や影響範囲を特定するようなシナリオを想定したクイズが出題されました。
さいごに
今回は「AWS SECURITY INCIDENT GAME DAY」で体験したセキュリティインシデント対応の一連の流れと、その解説をさせていただきました。
ワークショップ内の具体的なクイズ問題の内容に踏み込むことはできませんが、イベントの雰囲気や実践的な学びの一端を感じていただけたなら幸いです。
このような実践的なワークショップを通じて、セキュリティインシデントへの対応力を高めることの重要性を改めて認識しました。
今後のセキュリティ対策の一助となれば幸いです。
コメント
投稿にはログインしてください