Terraformを使用したDigitalOcean上のCowrie＆Grafanaハニーポット

目次
システム概要
技術
プロジェクトディレクトリ構造
ハードウェア要件
インストールとセットアップ
Terraform状態管理
CI/CDパイプライン
システムアーキテクチャ
観測結果
使用方法
プロジェクトドキュメント
セキュリティ上の考慮事項
貢献者
ライセンス

システム概要

Terraformを使用してDigitalOceanのドロップレット上にデプロイされたSSH/Telnetハニーポットスタック。攻撃はCowrieによってキャプチャされ、Lokiに保存され、Grafanaで攻撃元のライブワールドマップと共に可視化されます。

技術

プロジェクトディレクトリ構造```

honeypot/ ├── cowrie/ │ └── etc/ │ ├── cowrie.cfg # Cowrie honeypot configuration │ └── userdb.txt # Accepted and rejected fake credentials ├── geoip/ │ └── .gitkeep # Placeholder - MMDB files are gitignored ├── grafana/ │ ├── provisioning/ │ │ ├── dashboards/ │ │ │ ├── dashboards.yml # Provisioning: dashboard provider │ │ │ └── honeypot-dashboard.json # Pre-built Attack Monitor dashboard │ │ └── datasources/ │ │ └── loki.yml # Auto-provisioned Loki datasource │ └── grafana.ini # Grafana server settings ├── loki/ │ └── config.yml # Loki single-binary config and retention ├── promtail/ │ └── config.yml # Promtail scrape and GeoIP pipeline ├── scripts/ │ ├── geoip-update.sh # Download or refresh GeoIP database │ └── setup-firewall.sh # Host UFW rules for honeypot ports ├── terraform/ │ ├── templates/ │ │ ├── cloud-init.yaml.tftpl # Droplet first-boot script (Terraform-templated) │ │ └── env.tftpl # .env lines embedded via Terraform │ ├── backend.tf # Terraform backend config │ ├── main.tf # Droplet, SSH key, firewall, cloud-init │ ├── outputs.tf # IPs and helpful post-apply values │ ├── terraform.tfvars.example # Example variable values (copy to terraform.tfvars) │ ├── variables.tf # Terraform input variables │ └── versions.tf # Terraform and provider version constraints ├── .env.example # Example environment file for manual setup ├── .gitignore # Ignored paths and files ├── .gitlab-ci.yml # CI/CD pipeline: fmt, validate, Checkov ├── docker-compose.yml # Docker Compose file for the honeypot stack ├── LICENSE # GPLv2 license ├── manual-deployment.sh # Legacy VM bootstrap without Terraform └── README.md # Project documentation

## ハードウェア要件

> 注意: これらの要件は2026年5月時点のDigitalOcean Basic Dropletプランに基づくもので、プロジェクトを実行するための最小要件です。

- プロバイダー: DigitalOcean
- プラン: Basic Droplet - 1 Intel vCPU
- RAM: 1 GB (+2 GB スワップ)
- ストレージ: 35 GB NVMe SSD
- OS: Ubuntu 24.04 LTS

## インストールとセットアップ

> 注意: インストール後は、新しい端末を開いて `ADMIN_SSH_PORT` (デフォルト: 2022) でまだSSH接続できることを確認してから、元のセッションを閉じることをお勧めします。

### Terraform によるデプロイ (推奨)

1. 読み取り/書き込み権限を持つDigitalOcean APIトークンを作成します:

- DigitalOceanにログインし、Account > API > Tokens > Generate New Token に移動します。
- トークンに名前を付け（例: "Cowrie Honeypot"）、"Full Access"権限を選択します。
- "Generate Token"をクリックし、トークンの値を安全な場所にコピーします（後で確認できなくなります）。

2. ローカルマシンでSSH鍵ペアを作成し、公開鍵のパスをコピーします。

3. `terraform`ディレクトリに移動し、変数ファイルをコピーして編集します:

> 注意: 適用前に `terraform.tfvars` で少なくとも `do_token`、`ssh_public_key_path`、`grafana_admin_password` を設定する必要があります。```bash
cd terraform
cp terraform.tfvars.example terraform.tfvars

設定を適用してデプロイを開始します:

注: Terraform がローカルマシンにインストールされている必要があります。手順については、Terraform Installation Guide を参照してください。```bash terraform init # Initialize Terraform and download providers terraform apply

5. テスト中の場合 - 置き換えで再デプロイ:```bash
terraform apply -replace="digitalocean_droplet.honeypot"

クリーンアップ - 完了したらインフラを破棄してください：```bash terraform destroy

### 手動デプロイメント（レガシー）

1. 上記のハードウェア要件とあなたのSSHキーを備えたDigitalOceanドロップレットを作成します。

2. ドロップレットにSSH接続するか、DigitalOceanウェブコンソールを使用して、以下のコマンドを実行します。```bash
ssh root@<your-droplet-ip> # If using DigitalOcean web console, skip this command
git clone https://gitlab.com/Oseguera12/cowrie-honeypot-digitalocean.git /opt/honeypot
cd /opt/honeypot
cp .env.example .env
nano .env
bash manual-deployment.sh

Terraformの状態管理

注: デフォルトでは、Terraformは状態をローカルマシンの terraform/terraform.tfstate に書き込みます。このファイルには機密性の高い出力値（ドロップレットIP、Grafanaパスワード、SSHキーフィンガープリント）が含まれており、絶対にコミットしてはいけません。.gitignore は *.tfstate と *.tfstate.* をカバーしています。

ローカル状態のリスク:

マシンを紛失したりファイルが削除された場合に失われる
チームメンバー間で共有できない
ロックがない — 2つの apply 実行が同時に行われるとファイルが破損する可能性がある

個人の実験環境を超える場合は、リモートバックエンドに切り替えてください。terraform/backend.tf には、DigitalOcean Spacesの設定（S3互換）がコメントアウトされています。

リモートバックエンドを有効にするには:

DigitalOceanアカウントでSpacesバケットを作成する
API > Spaces Keys でSpacesアクセスキーを生成する
キーを環境変数としてエクスポートしてください（terraform.tfvars には記述しないでください）: ```bash export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY=
terraform/backend.tf 内の backend "s3" ブロックのコメントを解除し、バケット名とリージョンエンドポイントを入力します。
terraform init -migrate-state を実行して、既存のローカルステートを Spaces に移行します。

CI/CD パイプライン

.gitlab-ci.yml は、プッシュのたびに単一の validate ステージで 3 つのジョブを実行します。

注: terraform:fmt と terraform:validate は失敗するとパイプラインをブロックします。checkov:scan は allow_failure: true に設定されています。これは一部の検出結果が意図的なトレードオフであるためです。ジョブ全体を無効にするのではなく、許容できる特定の検出結果については、インラインの # checkov:skip=CKXXX コメントで抑制してください。

既知の許容されたリスク

CKV_DIO_4（「ファイアウォールの受信が完全に開いていないことを確認」）は、digitalocean_firewall リソース全体に対して 1 回発生します。これは terraform/main.tf のリソースブロック内に配置された単一の # checkov:skip=CKV_DIO_4: コメントで抑制されています。以下の表は、各開放ポートが意図的である理由を示しています。

システムアーキテクチャ```mermaid

flowchart TB internet((Internet))

subgraph tf["Terraform"] fw[DigitalOcean Cloud Firewall] droplet[Ubuntu 24.04 droplet] fw --> droplet end

subgraph compose["Docker Compose on droplet"] cowrie["Cowrie honeypot — SSH on port 22, Telnet on port 23"] promtail[Promtail with GeoIP labels] loki[Loki log store] grafana["Grafana — host :3000"] cowrie -->|JSON logs from ./data/cowrie-logs| promtail --> loki --> grafana end

## 観測結果

ライブデプロイメントの5日間 (2026-05-05 から 2026-05-09) に取得されたデータ：

| メトリクス           | 値      |
|----------------------|---------|
| 総接続数             | 41,700  |
| ログイン試行         | 15,400  |
| 成功したログイン     | 868     |
| 実行されたコマンド     | 836     |
| ダウンロードされたファイル | 6       |
| 発信元国数（ユニーク） | 106     |

### 進攻元の国トップ

| 国名               | 接続数  |
|--------------------|---------|
| ドイツ             | 9,768   |
| オランダ           | 9,110   |
| アメリカ合衆国     | 7,706   |
| イギリス           | 3,858   |
| シンガポール       | 1,770   |
| ベルギー           | 1,422   |

### 認証情報のパターン

最も多く試行されたユーザー名は `root` で 3,866 回、次いで `admin` (728 回)、`user` (494 回) であり、デフォルト認証情報や既知のサービスアカウントを標的とする自動スキャナの存在が確認された。最も多いパスワードは `123456` (1,480 回) で、`123`、`12345` がそれに続き、辞書ベースのブルートフォースツールに典型的なパターンを示している。

### 偽シェル内での攻撃者の行動

偽の認証情報セットに対して 868 件のログイン試行が成功した。これらのセッションのうち、836 件のコマンドが実行された。最も多いコマンドは `uname -s -v -n -r -m` (360 回実行) であり、これはペイロード展開前に標的のOSとアーキテクチャを識別するために自動化された侵害後スクリプトにより実行される標準的なシステムフィンガープリンティングコマンドである。その他に観測されたコマンドには、シェル履歴ログを無効にする `export HISTFILE=/dev/null` や `export HISTSAVE=/dev/null` が含まれており、攻撃者が自分たちが侵害したと信じているシステム内でも積極的に痕跡を隠そうとしていることが示された。

### 重要な洞察

自動化されたスキャントラフィックの量 — 5日間で106カ国から41,700件の接続 — は、公開されているSSHサービスが暴露から数時間以内に常にブルートフォース攻撃にさらされることを確認している。すぐに `uname` を実行し、続いて履歴抑制コマンドを実行する行動パターンは、人間の関与を最小限に抑えて動作する自動化された侵害後フレームワークと一致している。

## 使用方法

### Grafanaダッシュボードの利用

> 注：ダッシュボード認証情報は terraform.tfvars または .env（手動デプロイの場合）に設定されています。

ダッシュボードには以下のアドレスでアクセスできます。```
http://<your-droplet-ip>:3000

admin / <GRAFANA_ADMIN_PASSWORD> でログインします。

Cowrieハニーポットの許可された認証情報

cowrie/etc/userdb.txt - ハニーポットで許可される認証情報が含まれています。

このファイルを編集して、ハニーポットの認証情報を調整してください。
許可されたログインにより、攻撃者はすべてのコマンドが記録される偽装シェルにドロップされます。
拒否されたエントリは、失敗した試行として記録されます。

プロジェクトドキュメント

このセクションでは、本プロジェクトの開発中に下された判断と直面した問題について詳しく説明します。これは、プロジェクトの開発プロセスと学んだ教訓を振り返る役割を果たします。プロジェクトの使用方法だけを知りたい場合は、セキュリティに関する考慮事項にスキップしてください。

アーキテクチャ設計とトレードオフ

なぜクラウドホスティングなのか？

ハニーポットは、データを24時間体制で収集・分析するために高い可用性を持つように設計されています。ローカルマシンに仮想マシンやコンテナを使ってハニーポットを展開することも可能ですが、そのマシンを24時間オンラインでアクセス可能に保つことは現実的ではありません。クラウドホスティングは、ハニーポットをホストし継続的にデータを取得するための、より実用的で信頼性の高いソリューションを提供します。
さらに、クラウドホスティングでは特定のリソースやサービスを選択できるため、展開・拡張可能なコードベースの作成と維持が容易になります。自分のハニーポットを展開したい人は、プロジェクトが機能し、プロビジョニングされた環境がプロジェクトの期待と一致していれば、追加の手順なしで展開できます。

なぜDigitalOceanなのか？

AWS、GCP、Azureなどの他のプロバイダもありますが、DigitalOceanはこのプロジェクトにとってより手頃なオプションを提供します。ハニーポットはオンラインを維持し、データをドロップレットとの間で常時送受信する必要があるため、DigitalOceanの価格モデルはコストを予測可能に保つのに役立ちます。これは、無料クレジットや新規ユーザー向け割引、長期契約割引などの他プロバイダのプロモーションを考慮していません。

なぜTerraformなのか？

代替の manual-deployment.sh は、Terraformに詳しくない、または使用したくないユーザー向けです。この方法では、ドロップレットをプロビジョニングし、接続し、リポジトリをクローンし、スクリプトを実行する必要があります。Terraformを使用すると、コードベースを編集して再デプロイする際に、ローカルマシンから各手動ステップを繰り返すことなく、より迅速な反復が可能になります。また、インフラを解体して最初からやり直すのも簡単です。プロジェクトが単一のハニーポットからハニーネットへと成長する場合、Terraformは手動プロビジョニングや従来のスクリプトだけよりもクリーンにスケールします。

なぜCowrieなのか？

Cowrieは、よく知られ、積極的にメンテナンスされている中程度のインタラクション型ハニーポットです。より軽量なトラップよりも多くのリソースを使用する可能性がありますが、その機能とスタックの他の部分との適合性から、自然な選択となりました。特定のユースケースに応じて他のハニーポットと交換することも可能ですが、多くはメンテナンスされていないか、さらに多くのリソースを必要とします。

なぜLokiなのか？

主な制約はハードウェアでした。1 GB RAMのドロップレットで他のいくつかのサービスを実行しながら、ログの集約と検索を行うという制約です。Elasticsearchは重すぎました。Graylogも内部でElasticsearchに依存しており、制限内で適切に動作しませんでした。他のオプションも同様にリソースを大量に消費しました。Grafana Lokiはスタックに適合し、非常に重いクエリを除いて予算内に収まりました。いくつかのクエリ機能は犠牲になりました。ダッシュボードが大量のデータを取得すると、Lokiは遅くなり、UIは応答しなくなり、ハニーポットがデータを見逃したり遅延させたりする可能性があります。

なぜGrafanaなのか？

最初はカスタムダッシュボードを検討しましたが、Grafanaは完成度が高く、カスタマイズ可能で、ドキュメントが充実しているため、ログの収集と転送に集中できるようセットアップが迅速に進みました。最小限のカスタムUIほど軽量ではありませんが、小さなドロップレットのアップグレード後はハードウェア制限内で快適に動作します。プリビルトダッシュボードを持つ他のツールは、このユースケースでは明確な利点なしにより多くのリソースを使用することになります。

なぜPromtailなのか？

Promtailは確立されたLokiログシッパーです（Grafana Alloyは後継の新しいものです）。PromtailはRAMが軽く、このプロジェクトに適合するパイプラインステージ（JSON解析、GeoIP、ラベル）をサポートしています。FluentdやLogstashなどの代替手段は、1 GBドロップレットには重すぎました。

なぜGeoIPなのか？

攻撃マップには、送信元IPから都市と国のコンテキストが必要です。このプロジェクトでは、scripts/geoip-update.sh を介してDB-IP City Liteを使用しています。アカウントやAPIキーは不要で、リポジトリをクローンする誰でも簡単にデプロイできます。Promtailの組み込みGeoIPステージはローカルのMMDBファイルを読み取り、Grafana Geomapパネルのラベルを追加します。

システム実行のウォークスルー

Terraformまたは手動デプロイスクリプトを使用してハニーポットをセットアップする際に発生する処理のステップバイステップの概要。

Terraform（推奨）

あなたのマシン上で:

terraform/terraform.tfvars を設定: APIトークン、SSH公開鍵パス、Grafanaパスワード、リポジトリURL/ブランチ、オプションの manage_do_firewall
terraform init を実行: ローカルにDigitalOceanプロバイダをインストール
terraform apply を実行: Terraformが計画を構築し、リソースを作成または更新

DigitalOcean内:

SSH公開鍵がアカウントにアップロードされる
Terraform変数からドロップレットが作成される:
- イメージ（Ubuntu）、サイズ、リージョンは droplet_image、droplet_size、region などから取得
- ステップ4のSSH鍵がアタッチされる
- user_data はレンダリングされたcloud-initに設定される: 初回起動時にVMは管理SSHポート、git repo_url / repo_branch、生成された .env（Grafanaパスワードと env.tftpl からの ADMIN_SSH_PORT）のbase64エンコードコピーを取得する
クラウドファイアウォール（manage_do_firewall がtrueの場合のみ）:
- TerraformがDigitalOceanファイアウォールを作成し、このドロップレットに関連付ける
- 受信TCP: 管理SSHポート、22、23、3000（terraform/main.tf を参照）
- 送信: 広範なTCP/UDPとICMP（ドロップレットがパッケージを更新し、イメージをプルし、GeoIPデータをダウンロードできるようにする）

ドロップレット上では、cloud-initが自動的に実行される:

Cloud-config: package_update / package_upgrade、次にリストされたパッケージ（curl、git、ufw など）をインストール。ブートの初期に、write_files によって /root/honeypot.env が作成される（Terraformでレンダリングされた env.tftpl をbase64エンコードしたもの: Grafanaパスワード、ADMIN_SSH_PORT など）
runcmd ブートストラップスクリプト（terraform/templates/cloud-init.yaml.tftpl 内の順序）: iptables / ip6tables をレガシーバックエンドに設定
スワップ: 存在しない場合は2 GBファイルを作成（/swapfile、fstab、swappiness）

Docker Compose内:

Lokiが起動し、ヘルスチェックに合格する必要あり（コンテナ内ではポート3100で /ready；ホスト上では 127.0.0.1:3100 のみ）
PromtailとGrafanaはLokiが正常になるのを待ち（docker-compose.yml の depends_on）、その後起動する
Cowrieは独立して起動可能：ホストポート22と23をコンテナに公開し、JSONログを data/cowrie-logs に書き込み、Promtailがそれを読み取る

手動セットアップ（レガシー）

ユーザーがVMを作成し、SSHで接続し、クローンしたリポジトリからスクリプトを実行します。

manual-deployment.sh は以下を行います:

.env をロードし検証
システム更新: apt update & apt upgrade
パッケージのインストール: ツールに加えて ufw と iptables
スワップの設定: 存在しない場合は2 GBファイルを作成
Dockerのインストール: Engine + Composeプラグイン、サービスの有効化
SSHの設定: sshd を ADMIN_SSH_PORT で起動し、ssh.socket を無効化
ファイアウォールの設定: scripts/setup-firewall.sh
GeoIPの設定: scripts/geoip-update.sh と月次cron
スタックの起動: docker compose pull / up -d、その後スクリプトはLokiとGrafanaのヘルスチェックを待ち、サマリーを表示

遭遇した問題

ハードウェアの制限

限られたハードウェアリソースにより、パフォーマンスが低下し、タイムアウトが発生することがありました。これは、ダッシュボードがユーザー設定の間隔でデータベースに迅速にクエリを実行することに依存しており、時には複数のデバイスが同時にダッシュボードにアクセスする場合に影響を与えました。

検討された解決策:

より多くのリソースを得るために垂直スケーリング
ダッシュボードのパネル数を減らしてデータベースへの負荷を軽減するカスタムダッシュボード
同時にダッシュボードにアクセスできるデバイス数の制限
メインデータベースへの負担を軽減するため、ダッシュボードが読み取る別のデータベースにログを集約

解決方法:

パフォーマンスが向上した少し大きめのドロップレットにスケーリング

トレードオフ:

コストは月額約1～2ドル増加しましたが、利用可能なリソースは2倍になりました。BasicドロップレットよりもNVMe SSDストレージとより多くのRAMにアクセスできるようになり、より安定したパフォーマンスの高いダッシュボードが実現しました。これにより、パネル数が少なくレスポンスも劣るカスタムダッシュボードを作成する時間を節約できました。

学んだ教訓:

プロモーション、割引、価格帯を活用して、予算内で可能な限り多くのリソースを確保すること。最も基本的なドロップレットとわずかなコスト増加の差で利用可能なリソースが2倍になり、より完全な製品を迅速に提供できたため、時間を節約できました。さらに、ハニーポットを早く稼働させることで、データの収集と分析を早く開始できました。

タイムアウト問題

管理アクセス用にドロップレットにSSH接続しようとすると、接続がタイムアウトすることがありました。また、docker compose up は、ポート22が既に使用中でCowrieがバインドできなかったために失敗しました。