はじめに
AWS SAA（Solutions Architect Associate）の勉強を進める中で、資格勉強だけではなく、実際にAWSを使って何か作ってみたいと思うようになりました。
そこで今回は、AWSの無料利用枠を活用し、インターネット上に公開するハニーポット環境を構築してみました。
拙い部分もあるかと思いますがせっかくの試みなので記事として残すことにしました。
今回利用した主なソフトウェアは以下のとおりです。
- クラウド：AWS
- ハニーポット：WOWHoneypot
- SIEM：Splunk
本記事では設計編として、構成や設計方針について紹介します。
実際の構築手順やSplunkとの連携、ログ分析については、以下の4部構成で紹介する予定です。
- 設計編（本記事）
- 構築編①：AWS環境の構築
- 構築編②：WOWHoneypot・Splunkの構築と連携
- ログ分析編：取得した攻撃ログの紹介
筆者について
タイトルには「AWS初心者」と書いていますが、IT業界での実務経験は約5年あります。
これまで主にネットワーク、インフラ、セキュリティ分野の業務に携わっており、現在はSOCエンジニアとしてインシデント対応を行っています。
一方で、AWSについてはほとんど触ったことがなく、本格的な環境構築は今回が初めてです。
今回使用した技術に関連する領域においての知識レベルは以下のような状況でした。
| 分野 | レベル |
|---|---|
| AWS | SAA学習中（実務経験なし） |
| Azure | 検証環境を少し触った程度 |
| Splunk | 業務で利用経験あり |
| プログラミング | PHP・Pythonを少し書ける程度 |
| セキュリティ | SOCエンジニアとして実務経験あり |
AWS初心者ならではの躓きポイントも含めて紹介できればと思います。
システム構成
今回構築した環境は以下の構成です。
- Application Load Balancer（ALB）
- EC2（WOWHoneypot）
- EC2（Splunk）
- Session Manager
- VPC Endpoint
攻撃者からの通信はALBで受け付け、WOWHoneypotへ転送します。
WOWHoneypotで取得したログはSplunkへ転送し、ダッシュボード上で可視化できる構成としました。
使用したAWSリソース
今回使用した主なAWSリソースは以下のとおりです。
ネットワーク
| リソース | 構成 |
|---|---|
| リージョン | ap-northeast-1（東京） |
| VPC | 1 |
| Public Subnet | 1 |
| Private Subnet | 1 |
| ALB | Application Load Balancer |
| VPC Endpoint | ssm / ssmmessages / ec2messages |
EC2
| サーバ | AMI | インスタンスタイプ | EBS |
|---|---|---|---|
| WOWHoneypot | Ubuntu Server 24.04 LTS | t3.micro | 8GB |
| Splunk | Ubuntu Server 24.04 LTS | t3.small | 30GB |
今回はどちらのEC2も「Ubuntu Server 24.04 LTS」を採用しました。LTS（Long Term Support）版のためサポート期間が長く、情報量も豊富で、検証環境でも安心して利用できると考えたためです。
WOWHoneypotは t3.micro で十分動作しましたが、Splunkはメモリやストレージを多く消費するため、t3.small・EBS 30GBの構成としています。
検証目的であればどちらも十分動作しました。
設計時に意識したポイント
EC2はPrivate Subnetへ配置
WOWHoneypotとSplunkはどちらもPrivate Subnetへ配置しました。
インターネットから直接EC2へアクセスできない構成とし、外部公開が必要なApplication Load Balancer(ALB)のみをPublic Subnetへ配置しています。
これにより、攻撃者がEC2へ直接アクセスする経路をなくし、通信経路をALB経由のみに限定しています。
SSHではなくSession Managerを利用
EC2への管理アクセスにはSSHではなく、AWS Systems ManagerのSession Managerを利用しました。
Session Managerを利用することで、
- SSHポート（22番）の公開が不要
- SSH鍵の管理が不要
- セキュリティグループでSSHを許可する必要がない
というメリットがあります。
AWSを学習する中でも「まずはこちらを利用するのがおすすめ」と紹介されることが多く、今回はこの方式を採用しました。
NAT Gatewayは構築時のみ利用
Private Subnet内のEC2へWOWHoneypotやSplunkをインストールするため、一時的にNAT Gatewayを作成しました。
今回の環境は数日間だけ公開する学習・検証用のハニーポットです。そのため、長期間運用するシステムとは異なり、運用性よりも「コスト削減」と「侵害時の安全な封じ込め（Outbound通信の遮断）」を優先しています。
必要なパッケージのインストールやアップデートが完了した後は、
- NAT Gatewayの削除
- Private Route TableからNAT Gatewayへのデフォルトルート（0.0.0.0/0）の削除
- 構築時のみ利用していたセキュリティグループルールの削除
を実施しています。
これにより、公開後のEC2はインターネットへ自由に通信できない構成となっています。
管理に必要な通信は維持できるよう、Systems Manager関連のVPC Endpoint（ssm、ssmmessages、ec2messages）を構成し、Session Managerによる接続のみを許可しています。
この構成により、NAT Gatewayの利用料金を抑えられ、万が一EC2が侵害された場合でも、攻撃者が外部のC2サーバなどへ自由にOutbound通信を行うことを防ぎやすいというメリットがあります。
本番環境であれば可用性や保守性も考慮し、NAT Gatewayを常設する設計も十分考えられますが、今回は数日間だけ利用する使い捨ての検証環境であるため、「コスト削減」と「安全な封じ込め」を最優先に、この構成を採用しました。
設計上の割り切り
ALB配下であることは見破られる可能性がある
今回は、インターネットからの入口としてApplication Load Balancer（ALB）を採用しました。
そのため、高度な調査を行う攻撃者であれば、
- HTTPレスポンスヘッダー
- ALB特有のHTTPエラーレスポンス
- SSL/TLS証明書の挙動
- DNS(Route 53)
などの情報から「AWSのALB配下にあるサーバ」であることを推測できる可能性があります。
その結果、ハニーポットであることを疑われる可能性もありますが、今回の目的はインターネット上を巡回している一般的な自動スキャンやボットからのアクセスを観測することです。
本格的なアンチハニーポット対策を目的とした環境ではなく、AWS上でハニーポットを構築し、Splunkと連携してログを可視化することを学ぶことが目的だったため、この点は設計上の割り切りとしました。
「侵害されること」を前提に設計する
ハニーポットは攻撃を受けることを前提としたシステムです。
そのため、「侵害されないこと」を目指すのではなく、「侵害された場合でも影響範囲を最小限に抑えること」を意識しました。
公開期間は数日程度に限定し、必要なログを取得した後は環境を停止・削除する予定です。
また、公開前には以下を実施しました。
- NAT Gatewayの削除
- Private Route Tableから外向きルートの削除
- 不要なセキュリティグループルールの削除
- Session Manager用VPC Endpointのみを残す構成
仮にWOWHoneypotに未知の脆弱性やRCE(Remote Code Execution)の脆弱性が存在していた場合でも、攻撃者が外部へ自由に通信できないよう配慮しました。
これだけで侵害後のリスクを完全になくせるわけではありませんが、学習用途のハニーポットであっても、「侵害されること」を前提に影響範囲を限定するという考え方は重要だと考えています。
構築の流れ
今回の構築は、以下の順番で進めるとスムーズでした。
- VPCの作成
- Subnetの作成
- Internet Gatewayの作成
- Route Tableの設定
- VPC Endpointの作成
- Security Groupの作成
- EC2用IAM Roleの作成
- EC2の作成
- Session Managerで接続確認
- NAT Gatewayの作成
- EC2へ必要なソフトウェアをインストール
- NAT Gatewayを削除
- Splunkの動作確認
- ALBの作成
- ログ転送設定
- インターネットへ公開
- Splunkダッシュボードの作成
次回は、実際にAWS上へ環境を構築する手順を紹介します。