Хонейпот Cowrie и Grafana с использованием Terraform на DigitalOcean

Видео-демонстрация

Содержание

• Содержание
• Обзор системы
• Технологии
• Структура каталогов проекта
• Требования к оборудованию
• Установка и настройка
• Управление состоянием Terraform
• Конвейер CI/CD
• Архитектура системы
• Наблюдения
• Использование
• Документация проекта
  • Проектирование архитектуры и компромиссы
  • Пошаговое выполнение системы
  • Обнаруженные проблемы и ограничения
  • Будущие улучшения
• Соображения безопасности
• Участники
• Лицензия

Обзор системы

Стек хонейпота SSH/Telnet, развернутый на DigitalOcean droplet с помощью Terraform. Атаки фиксируются Cowrie, сохраняются в Loki и визуализируются в Grafana с живой картой мира источников атак.

Технологии

• DigitalOcean
• Terraform
• Docker
• Cowrie
• Loki
• Grafana
• Promtail
• DB-IP (скачать City Lite)

Структура каталогов проекта```

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

## Аппаратные требования

> Примечание: Эти требования основаны на тарифе Basic Droplet от DigitalOcean по состоянию на май 2026 года и являются минимальными для работы проекта.

- Провайдер: DigitalOcean
- Тариф: Basic Droplet — 1 Intel vCPU
- ОЗУ: 1 ГБ (+2 ГБ swap)
- Хранилище: 35 ГБ NVMe SSD
- ОС: Ubuntu 24.04 LTS

## Установка и настройка

>Примечание: После установки рекомендуется открыть новый терминал и проверить, что вы всё ещё можете подключиться по SSH на `ADMIN_SSH_PORT` (по умолчанию: 2022), прежде чем закрывать исходную сессию.

### Развертывание с помощью Terraform (рекомендуется)

1. Создайте API-токен DigitalOcean с правами на чтение и запись:

- Войдите в DigitalOcean и перейдите в Account > API > Tokens > Generate New Token.
- Назовите токен (например, «Cowrie Honeypot») и выберите разрешения «Full Access».
- Нажмите «Generate Token» и скопируйте значение токена в надёжное место (вы больше не сможете его увидеть).

2. Создайте пару SSH-ключей на локальной машине и скопируйте путь к открытому ключу.

3. Перейдите в каталог `terraform`, затем скопируйте и отредактируйте файл с переменными:

> Примечание: `do_token`, `ssh_public_key_path` и `grafana_admin_password` должны быть настроены как минимум в `terraform.tfvars` перед применением.```bash
cd terraform
cp terraform.tfvars.example terraform.tfvars

4. Примените конфигурацию и запустите развертывание:

Примечание: Terraform должен быть установлен на вашем локальном компьютере. Инструкции см. в Руководстве по установке Terraform.```bash terraform init # Initialize Terraform and download providers terraform apply

5. Если тестирование - переразвернуть с заменой:```bash
terraform apply -replace="digitalocean_droplet.honeypot" 

6. Очистка - Уничтожьте инфраструктуру, когда закончите:```bash terraform destroy

### Ручное развёртывание (устаревшее)

1. Создайте droplet DigitalOcean с указанными выше требованиями к оборудованию и вашим SSH-ключом.

2. Подключитесь по SSH к droplet или используйте веб-консоль 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.*.

Риски локального состояния:

• Потеряно, если компьютер потерян или файл удалён
• Не может быть разделено между членами команды
• Нет блокировки — два одновременных запуска apply могут повредить файл

Для всего, что выходит за рамки личной лаборатории, переключитесь на удаленный бэкенд. terraform/backend.tf содержит закомментированную конфигурацию DigitalOcean Spaces (совместимую с S3).

Чтобы включить удаленный бэкенд:

1. Создайте корзину Spaces в своей учетной записи DigitalOcean
2. Сгенерируйте ключ доступа Spaces в разделе API > Spaces Keys
3. Экспортируйте ключи как переменные окружения (не помещайте их в terraform.tfvars): ```bash export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY=
   root@kitploit:~

4. Раскомментируйте блок backend "s3" в terraform/backend.tf и укажите имя вашего бакета и endpoint региона.
5. Выполните 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. Он подавляется одним комментарием # checkov:skip=CKV_DIO_4:, размещённым внутри блока ресурса в terraform/main.tf. В таблице ниже документировано, почему каждый открытый порт является намеренным.

Архитектура системы```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

internet -->|22/23 honeypot| fw internet -->|Admin SSH :2022| fw internet -->|Grafana :3000| fw droplet --> compose

## Наблюдения

Данные, собранные за 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` с 3866 попытками, за ним следуют `admin` (728) и `user` (494), что отражает нацеленность автоматических сканеров на учетные данные по умолчанию и известные сервисные учетные записи. Самым распространенным паролем был `123456` (1480 попыток), затем `123` и `12345`, что соответствует инструментам для перебора по словарю.

### Поведение атакующего внутри фиктивной оболочки

868 попыток входа успешно прошли с использованием фиктивного набора учетных данных. Из этих сессий было выполнено 836 команд. Самой частой командой была `uname -s -v -n -r -m` (360 выполнений) — стандартная команда для снятия отпечатка системы, выполняемая автоматизированными скриптами пост-эксплуатации для идентификации целевой ОС и архитектуры перед развертыванием полезной нагрузки. Среди других наблюдаемых команд были `export HISTFILE=/dev/null` для отключения журналирования истории оболочки и `export HISTSAVE=/dev/null`, что указывает на активные попытки атакующих скрыть свои следы даже внутри системы, которую они считали скомпрометированной.

### Ключевой вывод

Объем автоматического сканирующего трафика — 41 700 подключений за 5 дней из 106 стран — подтверждает, что любой общедоступный SSH-сервис сталкивается с постоянными попытками перебора в течение нескольких часов после обнаружения. Поведенческая модель немедленного запуска `uname` с последующими командами подавления истории соответствует автоматизированным фреймворкам пост-эксплуатации, работающим с минимальным участием человека.

## Использование

### Использование дашборда Grafana

> Примечание: учетные данные дашборда задаются в terraform.tfvars или .env (для ручного развертывания)

Дашборд можно открыть по адресу:```
http://<your-droplet-ip>:3000

Вход с admin / <GRAFANA_ADMIN_PASSWORD>.

Принятые учетные данные honeypot Cowrie

cowrie/etc/userdb.txt - содержит принятые учетные данные для honeypot.

• Отредактируйте этот файл, чтобы настроить учетные данные honeypot
• Принятые входы переводят атакующего в поддельную оболочку, где все команды регистрируются
• Отклоненные записи регистрируются как неудачные попытки

Документация проекта

В этом разделе подробно описаны решения, принятые в ходе разработки этого проекта, и возникшие проблемы. Он служит отражением процесса разработки проекта и извлеченных уроков. Перейдите к Security Considerations, если вы хотите только узнать, как пользоваться проектом.

Архитектурные решения и компромиссы

Почему облачный хостинг?

• Honeypot спроектированы для обеспечения высокой доступности, чтобы круглосуточно собирать и анализировать данные. Хотя honeypot можно развернуть на локальной машине с помощью виртуальных машин или контейнеров, поддерживать эту машину онлайн и доступной круглосуточно непрактично. Облачный хостинг предоставляет более практичное и надежное решение для хостинга honeypot и непрерывного сбора данных.
• Кроме того, поскольку облачный хостинг позволяет выбирать определенные ресурсы и услуги, легче создать и поддерживать кодовую базу, которую можно развертывать и расширять. Любой, кто заинтересован в развертывании собственного honeypot, может сделать это без дополнительных шагов, если проект работает и выделенная среда соответствует ожиданиям проекта.

Почему DigitalOcean?

• Хотя доступны другие провайдеры, такие как AWS, GCP и Azure, DigitalOcean предлагает более доступный вариант для этого проекта. Поскольку honeypot должен оставаться онлайн и круглосуточно отправлять данные в/из droplet, модель ценообразования DigitalOcean помогла сохранить предсказуемость затрат. Это не учитывает акции других провайдеров, такие как бесплатные кредиты или скидки для новых пользователей или долгосрочных обязательств.

Почему Terraform?

• Альтернатива, manual-deployment.sh, предназначена для пользователей, не знакомых с Terraform или предпочитающих не использовать его. Этот путь требует создания droplet, подключения к нему, клонирования репозитория и запуска скрипта. Terraform позволяет быстрее итерировать: редактируйте кодовую базу и переразвертывайте без повторения каждого ручного шага с локальной машины. Это также упрощает разрушение инфраструктуры и начало с чистого листа. Если проект вырастет из одного honeypot в honeynet, Terraform масштабируется более чисто, чем ручное развертывание или только легаси-скрипт.

Почему Cowrie?

• Cowrie — это хорошо известный, активно поддерживаемый honeypot среднего уровня взаимодействия. Он может использовать больше ресурсов, чем более легкие ловушки, но его функции и соответствие остальной части стека сделали его естественным выбором. Для конкретных случаев использования можно заменить другие honeypot, хотя многие из них не поддерживаются или требуют еще больше ресурсов.

Почему Loki?

• Основным ограничением было оборудование: агрегация и поиск логов на droplet с 1 ГБ ОЗУ при нескольких других запущенных сервисах. Elasticsearch был слишком тяжелым. Graylog все еще зависит от Elasticsearch под капотом и не мог нормально работать в этих ограничениях. Другие варианты были столь же ресурсоемкими. Grafana Loki соответствовала стеку и оставалась в рамках бюджета, за исключением очень тяжелых запросов. Некоторые функции запросов были принесены в жертву: если панели управления загружают слишком много данных, Loki становится медленным, интерфейс кажется неотзывчивым, и honeypot может пропускать или задерживать данные.

Почему Grafana?

• Изначально я рассматривал собственную панель управления, но Grafana полна, настраиваема и хорошо документирована, что ускорило настройку, чтобы я мог сосредоточиться на сборе и отправке логов. Она не такая легковесная, как минимальный собственный интерфейс, но после небольшого обновления droplet она работает комфортно в рамках аппаратных ограничений. Другие инструменты с предварительно созданными панелями использовали бы больше ресурсов без явных преимуществ для данного случая.

Почему Promtail?

• Promtail — это устоявшийся отправитель логов Loki (Grafana Alloy — более новый преемник). Promtail легок на RAM и поддерживает этапы конвейера (разбор JSON, GeoIP, метки), которые подходят для этого проекта. Альтернативы, такие как Fluentd или Logstash, были слишком тяжелыми для droplet с 1 ГБ.

Почему GeoIP?

• Карты атак нуждаются в контексте города и страны из исходных IP-адресов. Проект использует DB-IP City Lite через scripts/geoip-update.sh: без учетной записи или ключа API, что упрощает развертывание для любого, кто клонирует репозиторий. Встроенный этап GeoIP в Promtail читает локальный MMDB-файл и добавляет метки для панели Geomap в Grafana.

Пошаговое описание выполнения системы

Пошаговый обзор того, что происходит при настройке honeypot с помощью Terraform или скрипта ручного развертывания.

Terraform (рекомендуется)

На вашей машине:

1. Настройте terraform/terraform.tfvars: токен API, путь к открытому ключу SSH, пароль Grafana, URL/ветку репозитория, опционально manage_do_firewall
2. Выполните terraform init: установите провайдера DigitalOcean локально
3. Выполните terraform apply: Terraform строит план, затем создает или обновляет ресурсы

В DigitalOcean:

4. Открытый ключ SSH загружается в вашу учетную запись
5. Создается droplet из ваших переменных Terraform:
   • Образ (Ubuntu), размер и регион берутся из droplet_image, droplet_size, region и т.д.
   • Ключ SSH из шага 4 прикрепляется
   • user_data устанавливается в сгенерированный cloud-init: при первой загрузке ВМ получает административный SSH-порт, repo_url / repo_branch и копию сгенерированного .env в кодировке base64 (пароль Grafana и ADMIN_SSH_PORT из env.tftpl)
6. Облачный файрвол (только когда manage_do_firewall истинно):
   • Terraform создает файрвол DigitalOcean и связывает его с этим droplet
   • Входящий TCP: ваш административный SSH-порт, 22, 23 и 3000 (см. terraform/main.tf)
   • Исходящий: широкий TCP/UDP и ICMP, чтобы droplet мог обновлять пакеты, вытягивать образы и загружать данные GeoIP

На droplet cloud-init выполняется автоматически:

7. Cloud-config: package_update / package_upgrade, затем установка перечисленных пакетов (curl, git, ufw, …). На раннем этапе загрузки write_files создает /root/honeypot.env (сгенерированный Terraform env.tftpl в base64: пароль Grafana, ADMIN_SSH_PORT и т.д.)
8. Скрипт начальной загрузки runcmd (порядок в terraform/templates/cloud-init.yaml.tftpl): установка бэкендов iptables / ip6tables в legacy
9. Swap: файл 2 ГБ, если отсутствует (/swapfile, fstab, swappiness)

Внутри Docker Compose:

18. Loki запускается и должен пройти свою проверку работоспособности (/ready на порту 3100 внутри контейнера; на хосте только 127.0.0.1:3100)
19. Promtail и Grafana ожидают, пока Loki станет работоспособным (depends_on в docker-compose.yml), затем запускаются
20. Cowrie может запускаться независимо: он публикует порты хоста 22 и 23 внутри контейнера и записывает JSON-логи в data/cowrie-logs для Promtail

Ручная настройка (легаси)

Пользователь создает ВМ, подключается по SSH и запускает скрипт из клонированного репозитория.

manual-deployment.sh делает следующее:

1. Загрузка и проверка .env
2. Обновление системы: apt update и apt upgrade
3. Установка пакетов: инструменты плюс ufw и iptables
4. Настройка swap: файл 2 ГБ, если отсутствует
5. Установка Docker: Engine + плагин Compose, включение сервисов
6. Настройка SSH: sshd на ADMIN_SSH_PORT и отключение ssh.socket
7. Настройка файрвола: scripts/setup-firewall.sh
8. Настройка GeoIP: scripts/geoip-update.sh и ежемесячный cron
9. Запуск стека: docker compose pull / up -d, затем скрипт ожидает проверку работоспособности Loki и Grafana и выводит сводку

Возникшие проблемы

Ограничения оборудования

• Ограниченные аппаратные ресурсы приводили к медленной производительности и периодическим тайм-аутам. Это повлияло на панель управления, которая зависит от возможности быстрого выполнения запросов к базе данных в установленные пользователем интервалы, иногда при одновременном доступе нескольких устройств к панели.

Рассмотренные решения:

• Вертикальное масштабирование для получения дополнительных ресурсов
• Собственная панель управления с меньшим количеством панелей для снижения нагрузки на базу данных
• Ограничение количества устройств, которые могут одновременно обращаться к панели
• Агрегация логов в отдельной базе данных для чтения панелью управления, чтобы снизить нагрузку на основную базу

Решение:

• Переход на slightly larger droplet с лучшей производительностью

Компромиссы:

• Хотя стоимость увеличилась примерно на $1-2 в месяц, доступные ресурсы удвоились. Доступ к NVMe SSD-накопителям и большему объему ОЗУ по сравнению с Basic Droplet позволил получить более стабильную и производительную панель управления. Это позволило избежать затрат времени на создание собственной панели с меньшим количеством панелей и менее отзывчивым интерфейсом.

Извлеченные уроки:

• Получение как можно большего количества ресурсов в рамках бюджета за счет использования акций, скидок и ценовых уровней. Разница между самым базовым droplet и небольшим увеличением стоимости привела к удвоению доступных ресурсов, что сэкономило время, позволив получить более полный продукт. Кроме того, более ранний запуск honeypot означал более ранний сбор и анализ данных.

Проблемы с тайм-аутами

• При попытке подключения по SSH к droplet для административного доступа соединения истекали по тайм-ауту. Кроме того, docker compose up завершался ошибкой, потому что порт 22 уже использовался и не мог быть привязан Cowrie.

Рассмотренные решения:

• sshd был неправильно настроен или прослушивал не тот порт
• Правила файрвола блокировали административный SSH-порт после его перемещения
• Другой процесс уже удерживал порт 22

Решение:

• Исправлен порядок операций: sshd перемещается на ADMIN_SSH_PORT (по умолчанию 2022) и перезапускается первым, затем ssh.socket останавливается и отключается, чтобы освободить порт 22 для привязки Docker к Cowrie. Правила UFW применяются после обоих шагов, чтобы разрешить новый административный порт.

Компромиссы:

• Никаких функциональных компромиссов. Это было исправление конфигурации и порядка.

Извлеченные уроки:

• Важно знать о любых сервисах, которым требуется освобождение определенных ресурсов в определенном порядке перед их запуском. В данном случае на Ubuntu 24.04 ssh.socket — это systemd-юнит сокета, который резервирует порт 22 для активации SSH по требованию. Он должен быть остановлен и отключен до того, как Docker сможет привязать порт хоста 22 для Cowrie. Если он все еще активен, docker compose up завершается ошибкой «address already in use».

Будущие улучшения

GeoIP-функциональность

• Городские GeoIP-данные являются приблизительными. Панели карты зависят от базы данных DB-IP и могут пропускать или неправильно маркировать некоторые IP-адреса (мобильные, VPN, устаревшие данные). Позже стек можно расширить с помощью другой базы данных или конвейера обогащения для повышения точности географии.

Grafana HTTPS

• Grafana в настоящее время работает по HTTP. Будущим улучшением будет размещение ее за обратным прокси (nginx или Caddy) с TLS-сертификатом, что также позволит ограничить порт Grafana localhost и проксировать через 443.

Функциональность прокси-сервера

• Чтобы сделать honeypot более правдоподобным, его можно проксировать через сервер в другом регионе. Это затруднит атакующим идентификацию его как honeypot на основе его IP-адреса или геолокации.

Соображения безопасности

• Grafana использует HTTP. Порт 3000 без TLS означает, что учетные данные передаются в открытом виде.
• Loki прослушивает только 127.0.0.1 (не доступен извне)
• terraform.tfvars находится в .gitignore и никогда не должен попадать в коммит
• Cowrie работает как непривилегированный пользователь внутри своего контейнера
• Если Grafana доступна за пределами тестовой среды, ее следует разместить за обратным прокси с HTTPS

Авторы

• Oseguera12

Лицензия

GNU General Public License Version 2.0 (GPLv2) Полный текст лицензии см. в файле LICENSE.