はじめに

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上へ環境を構築する手順を紹介します。