DigitalOcean에서 Terraform을 사용한 Cowrie 및 Grafana Honeypot

시스템 개요

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 설치 가이드를 참조하십시오.```bash terraform init # Initialize Terraform and download providers terraform apply

5. 테스트 시 - 교체하여 재배포:```bash
terraform apply -replace="digitalocean_droplet.honeypot"

정리 - 작업이 끝나면 인프라를 파괴하세요:```bash terraform destroy

### 수동 배포 (레거시)

1. 위의 하드웨어 요구 사항을 충족하는 DigitalOcean 드롭렛을 생성하고 SSH 키를 추가합니다.

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에 상태를 기록합니다. 이 파일에는 민감한 출력 값(Droplet IP, Grafana 비밀번호, SSH 키 지문)이 포함되어 있으며 절대 커밋해서는 안 됩니다. .gitignore는 *.tfstate 및 *.tfstate.*를 포함하고 있습니다.

로컬 상태의 위험:

머신이 손실되거나 파일이 삭제되면 유실됨
팀 구성원 간 공유 불가
잠금 기능 없음 — 두 개의 동시 apply 실행이 파일을 손상시킬 수 있음

개인 실습 환경을 넘어서는 경우 원격 백엔드로 전환하십시오. terraform/backend.tf에는 (S3 호환) DigitalOcean Spaces 설정이 주석 처리되어 있습니다.

원격 백엔드를 활성화하려면:

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 단계에서 세 가지 작업을 실행합니다.

참고: terraform:fmt 및 terraform:validate는 실패 시 파이프라인을 차단합니다. checkov:scan은 일부 결과가 의도적인 절충안이므로 allow_failure: true로 설정되어 있습니다. 작업 자체를 비활성화하기보다는 인라인 # checkov:skip=CKXXX 주석을 사용하여 특정 수용 가능한 결과를 억제하세요.

알려진 수용된 위험

CKV_DIO_4("방화벽 인그레스가 완전히 열려 있지 않은지 확인")는 전체 digitalocean_firewall 리소스에 대해 한 번 발생합니다. 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

## Observations

Data captured over 5 days of live deployment (2026-05-05 to 2026-05-09):

| Metric                    | Value  |
|---------------------------|--------|
| Total connections         | 41,700 |
| Login attempts            | 15,400 |
| Successful logins         | 868    |
| Commands executed         | 836    |
| Files downloaded          | 6      |
| Unique source countries   | 106    |

### Top attacking countries

| Country         | Connections |
|-----------------|-------------|
| Germany         | 9,768       |
| Netherlands     | 9,110       |
| United States   | 7,706       |
| United Kingdom  | 3,858       |
| Singapore       | 1,770       |
| Belgium         | 1,422       |

### Credential patterns

The most common username attempted was `root` with 3,866 attempts, followed by
`admin` (728) and `user` (494), reflecting automated scanners targeting
default credentials and known service accounts. The most common password was
`123456` (1,480 attempts) followed by `123` and `12345`, consistent with
dictionary-based brute-force tooling.

### Attacker behavior inside the fake shell

868 login attempts succeeded against the fake credential set. Of those sessions,
836 commands were executed. The most common command was `uname -s -v -n -r -m`
(360 executions) — a standard system fingerprinting command run by automated
post-exploitation scripts to identify the target OS and architecture before
deploying a payload. Other observed commands included `export HISTFILE=/dev/null`
to disable shell history logging, and `export HISTSAVE=/dev/null`, indicating
attackers actively attempting to cover their tracks even inside what they believed
was a compromised system.

### Key takeaway

The volume of automated scanning traffic — 41,700 connections in 5 days from 106
countries — confirms that any publicly accessible SSH service faces constant
brute-force attempts within hours of exposure. The behavioral pattern of
immediately running `uname` followed by history-suppression commands is consistent
with automated post-exploitation frameworks operating with minimal human
involvement.

## Usage

### Using Grafana Dashboard

> Note: Dashboard Credentials are set in terraform.tfvars or .env (for manual deployment)

Dashboard can be accessed at:```
http://<your-droplet-ip>:3000

admin / <GRAFANA_ADMIN_PASSWORD>로 로그인하세요.

Cowrie 허니팟 수락 자격 증명

cowrie/etc/userdb.txt - 허니팟에 대해 수락된 자격 증명이 포함되어 있습니다.

이 파일을 편집하여 허니팟 자격 증명을 조정하세요
수락된 로그인은 공격자를 모든 명령어가 기록되는 가짜 셸로 떨어뜨립니다
거부된 항목은 실패한 시도로 기록됩니다

프로젝트 문서

이 섹션에서는 이 프로젝트 개발 중 내린 결정과 발생한 문제를 자세히 설명합니다. 프로젝트 개발 과정과 교훈을 반영합니다. 프로젝트 사용 방법만 알고 싶다면 보안 고려 사항으로 건너뛰세요.

아키텍처 설계 및 트레이드오프

왜 클라우드 호스팅인가?

허니팟은 24시간 내내 데이터를 캡처하고 분석하기 위해 고가용성으로 설계되었습니다. 로컬 머신에서 가상 머신이나 컨테이너를 사용하여 배포할 수 있지만, 해당 머신을 항상 온라인 상태로 유지하고 액세스 가능하게 하는 것은 실용적이지 않습니다. 클라우드 호스팅은 허니팟을 호스팅하고 데이터를 지속적으로 캡처하는 데 더 실용적이고 안정적인 솔루션을 제공합니다.
또한 클라우드 호스팅을 사용하면 특정 리소스와 서비스를 선택할 수 있으므로 배포 및 확장이 가능한 코드베이스를 만들고 유지 관리하기가 더 쉽습니다. 프로젝트가 작동하고 프로비저닝된 환경이 프로젝트에서 예상하는 것과 일치하기만 하면 누구든지 추가 단계 없이 자신의 허니팟을 배포할 수 있습니다.

왜 DigitalOcean인가?

AWS, GCP, Azure와 같은 다른 제공업체도 있지만 DigitalOcean은 이 프로젝트에 더 저렴한 옵션을 제공합니다. 허니팟은 항상 온라인 상태를 유지하고 드롭릿 안팎으로 데이터를 지속적으로 전송해야 하기 때문에 DigitalOcean의 가격 모델은 비용을 예측 가능하게 유지하는 데 도움이 되었습니다. 이는 신규 사용자 또는 장기 약정에 대한 무료 크레딧이나 할인과 같은 다른 제공업체의 프로모션을 고려하지 않습니다.

왜 Terraform인가?

대안인 manual-deployment.sh는 Terraform에 경험이 없거나 사용을 선호하지 않는 사용자를 위한 것입니다. 해당 경로는 드롭릿을 프로비저닝하고, 연결하고, 리포지토리를 복제하고, 스크립트를 실행해야 합니다. Terraform을 사용하면 더 빠르게 반복할 수 있습니다. 코드베이스를 편집하고 로컬 머신에서 각 수동 단계를 반복하지 않고 재배포할 수 있습니다. 또한 인프라를 해체하고 새로 시작하기 쉽습니다. 프로젝트가 단일 허니팟에서 허니넷으로 성장하는 경우 Terraform은 수동 프로비저닝이나 레거시 스크립트 단독보다 더 깔끔하게 확장됩니다.

왜 Cowrie인가?

Cowrie는 잘 알려져 있고 적극적으로 유지 관리되는 중간 상호 작용 허니팟입니다. 더 가벼운 트랩보다 더 많은 리소스를 사용할 수 있지만, 그 기능과 나머지 스택과의 적합성 덕분에 자연스러운 선택이 되었습니다. 특정 사용 사례에 따라 다른 허니팟으로 교체할 수 있지만, 많은 허니팟이 유지 관리되지 않거나 더 많은 리소스가 필요합니다.

왜 Loki인가?

주요 제약 조건은 하드웨어였습니다. 1GB RAM 드롭릿에서 여러 다른 서비스를 실행하면서 로그 집계 및 검색을 수행해야 했습니다. Elasticsearch는 너무 무거웠습니다. Graylog는 여전히 내부적으로 Elasticsearch에 의존하며 제한 내에서 제대로 실행되지 않았습니다. 다른 옵션도 비슷하게 리소스를 많이 소모했습니다. Grafana Loki는 스택과 일치했으며 매우 무거운 쿼리를 제외하고는 예산 내에서 유지되었습니다. 일부 쿼리 기능은 희생되었습니다. 대시보드가 너무 많은 데이터를 가져오면 Loki가 느려지고 UI가 응답하지 않게 되며 허니팟이 데이터를 누락하거나 지연시킬 수 있습니다.

왜 Grafana인가?

원래는 커스텀 대시보드를 고려했지만 Grafana는 완전하고 사용자 정의가 가능하며 문서화가 잘 되어 있어 로그 수집 및 전송에 집중할 수 있도록 설정 속도를 높였습니다. 최소한의 커스텀 UI만큼 가벼운 것은 아니지만, 작은 드롭릿 업그레이드 후에는 하드웨어 제한 내에서 편안하게 실행됩니다. 사전 구축된 대시보드가 있는 다른 도구는 이 사용 사례에 명확한 이점 없이 더 많은 리소스를 사용했을 것입니다.

왜 Promtail인가?

Promtail은 Loki 로그 전송기로 확립되었습니다(Grafana Alloy는 새로운 후속 제품). Promtail은 RAM 사용량이 가볍고 파이프라인 단계(JSON 파싱, GeoIP, 레이블)를 지원하여 이 프로젝트에 적합합니다. Fluentd 또는 Logstash와 같은 대안은 1GB 드롭릿에 비해 너무 무거웠습니다.

왜 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의 base64 인코딩 사본(Grafana 비밀번호 및 env.tftpl의 ADMIN_SSH_PORT)을 가져옵니다
클라우드 방화벽(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를 레거시 백엔드로 설정
스왑: 누락된 경우 2GB 파일(/swapfile, fstab, swappiness)

Docker Compose 내부:

Loki가 시작되고 상태 확인을 통과해야 함(컨테이너 내 포트 3100의 /ready; 호스트에서는 127.0.0.1:3100만)
Promtail과 Grafana는 Loki가 정상 상태가 될 때까지 기다린 후(docker-compose.yml에서 depends_on) 시작합니다
Cowrie는 독립적으로 시작할 수 있습니다: 호스트 포트 22와 23을 컨테이너로 게시하고 Promtail이 읽을 data/cowrie-logs 아래에 JSON 로그를 씁니다

수동 설정 (레거시)

사용자가 VM을 생성하고, SSH로 접속한 후, 클론된 리포지토리에서 스크립트를 실행합니다.

manual-deployment.sh는 다음을 수행합니다:

.env 로드 및 검증
시스템 업데이트: apt update 및 apt upgrade
패키지 설치: 도구 및 ufw 및 iptables
스왑 구성: 누락된 경우 2GB 파일
Docker 설치: 엔진 + 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 증가했지만 리소스가 두 배로 늘어났습니다. 기본 드롭릿 대비 NVMe SSD 스토리지와 더 많은 RAM에 액세스할 수 있어 더 안정적이고 성능이 뛰어난 대시보드를 사용할 수 있었습니다. 이렇게 하면 더 적은 패널과 덜 반응적인 경험을 가진 커스텀 대시보드를 만드는 데 시간을 소비하지 않아도 되었습니다.

교훈:

프로모션, 할인, 가격 등급을 활용하여 예산 내에서 가능한 한 많은 리소스를 확보하는 것. 가장 기본적인 드롭릿과 약간의 비용 증가 차이로 리소스가 두 배로 늘어나 더 완전한 제품을 만들 수 있어 시간을 절약할 수 있었습니다. 또한 허니팟을 더 일찍 가동하면 데이터를 더 일찍 캡처하고 분석할 수 있었습니다.

시간 초과 문제

드롭릿에 관리 액세스를 위해 SSH를 시도할 때 연결 시간이 초과되었습니다. 별도로 docker compose up은 포트 22가 이미 사용 중이어서 Cowrie가 바인딩할 수 없어 실패했습니다.