Cowrie & Grafana Honeypot mit Terraform auf DigitalOcean

Demo-Video

Inhaltsverzeichnis

• Inhaltsverzeichnis
• Systemübersicht
• Technologien
• Projektverzeichnisstruktur
• Hardware-Anforderungen
• Installation und Einrichtung
• Terraform-Statusverwaltung
• CI/CD-Pipeline
• Systemarchitektur
• Beobachtungen
• Nutzung
• Projektdokumentation
  • Architekturentwurf und Abwägungen
  • Systemausführung Schritt für Schritt
  • Aufgetretene Probleme und Einschränkungen
  • Zukünftige Verbesserungen
• Sicherheitsüberlegungen
• Mitwirkende
• Lizenz

Systemübersicht

Ein SSH/Telnet-Honeypot-Stapel, der mithilfe von Terraform auf einem DigitalOcean-Droplet bereitgestellt wird. Angriffe werden von Cowrie erfasst, in Loki gespeichert und in Grafana mit einer Live-Weltkarte der Angriffsursprünge visualisiert.

Technologien

• DigitalOcean
• Terraform
• Docker
• Cowrie
• Loki
• Grafana
• Promtail
• DB-IP (City Lite-Download)

Projektverzeichnisstruktur```

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

## Hardware-Anforderungen

> Hinweis: Diese Anforderungen basieren auf dem DigitalOcean Basic Droplet-Plan vom Mai 2026 und sind die Mindestanforderungen für den Betrieb des Projekts.

- Provider: DigitalOcean
- Plan: Basic Droplet - 1 Intel vCPU
- RAM: 1 GB (+2 GB Swap)
- Storage: 35 GB NVMe SSD
- OS: Ubuntu 24.04 LTS

## Installation & Einrichtung

>Hinweis: Nach der Installation wird empfohlen, ein neues Terminal zu öffnen und zu überprüfen, ob Sie sich weiterhin über SSH auf `ADMIN_SSH_PORT` (Standard: 2022) anmelden können, bevor Sie Ihre ursprüngliche Sitzung schließen.

### Terraform-Bereitstellung (Empfohlen)

1. Erstellen Sie einen DigitalOcean-API-Token mit Lese-/Schreibberechtigungen:

- Melden Sie sich bei DigitalOcean an und navigieren Sie zu Account > API > Tokens > Generate New Token.
- Benennen Sie Ihren Token (z. B. „Cowrie Honeypot“) und wählen Sie die Berechtigung „Full Access“ aus.
- Klicken Sie auf „Generate Token“ und kopieren Sie den Token-Wert an einen sicheren Ort (Sie werden ihn nicht wieder sehen können).

2. Erstellen Sie ein SSH-Schlüsselpaar auf Ihrem lokalen Rechner und kopieren Sie den Pfad des öffentlichen Schlüssels.

3. Wechseln Sie in das Verzeichnis `terraform`, kopieren Sie dann die Variablendatei und bearbeiten Sie sie:

> Hinweis: `do_token`, `ssh_public_key_path` und `grafana_admin_password` müssen mindestens in `terraform.tfvars` konfiguriert werden, bevor `apply` ausgeführt wird.```bash
cd terraform
cp terraform.tfvars.example terraform.tfvars

4. Übernehmen Sie die Konfiguration und starten Sie die Bereitstellung:

Hinweis: Terraform muss auf Ihrem lokalen Rechner installiert sein. Besuchen Sie die Terraform Installationsanleitung für Anweisungen.```bash terraform init # Initialize Terraform and download providers terraform apply

5. Falls Testen - Redeploy mit Ersatz:```bash
terraform apply -replace="digitalocean_droplet.honeypot" 

6. Aufräumen - Zerstöre die Infrastruktur, wenn du fertig bist:```bash terraform destroy

### Manuelle Bereitstellung (Legacy)

1. Erstellen Sie einen DigitalOcean-Droplet mit den oben genannten Hardwareanforderungen und Ihrem SSH-Schlüssel.

2. SSH in den Droplet oder verwenden Sie die DigitalOcean-Webkonsole und führen Sie die folgenden Befehle aus:```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 Zustandsverwaltung

Hinweis: Standardmäßig schreibt Terraform den Zustand in terraform/terraform.tfstate auf Ihrem lokalen Rechner. Diese Datei enthält sensible Ausgabewerte (Droplet-IP, Grafana-Passwort, SSH-Schlüssel-Fingerabdruck) und darf niemals committet werden. .gitignore deckt *.tfstate und *.tfstate.* ab.

Risiken des lokalen Zustands:

• Verloren, wenn der Rechner verloren geht oder die Datei gelöscht wird
• Kann nicht mit Teammitgliedern geteilt werden
• Keine Sperre – zwei gleichzeitige Ausführungen von apply können die Datei beschädigen

Für alles, das über ein persönliches Labor hinausgeht, wechseln Sie zu einem entfernten Backend. terraform/backend.tf enthält eine auskommentierte DigitalOcean Spaces-Konfiguration (S3-kompatibel).

Um das entfernte Backend zu aktivieren:

1. Erstellen Sie einen Spaces-Bucket in Ihrem DigitalOcean-Konto
2. Generieren Sie einen Spaces-Zugriffsschlüssel unter API > Spaces Keys
3. Exportieren Sie die Schlüssel als Umgebungsvariablen (setzen Sie sie nicht in terraform.tfvars): ```bash export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY=
   root@kitploit:~

4. Kommentieren Sie den backend "s3"-Block in terraform/backend.tf aus und geben Sie Ihren Bucket-Namen und den Region-Endpunkt ein.
5. Führen Sie terraform init -migrate-state aus, um den vorhandenen lokalen Status zu Spaces zu verschieben.

CI/CD-Pipeline

.gitlab-ci.yml führt bei jedem Push drei Jobs in einer einzigen validate-Stufe aus:

Hinweis: terraform:fmt und terraform:validate blockieren die Pipeline bei Fehlschlag. checkov:scan ist auf allow_failure: true gesetzt, da einige Ergebnisse bewusste Kompromisse sind. Unterdrücken Sie spezifische akzeptable Ergebnisse mit Inline-# checkov:skip=CKXXX-Kommentaren, anstatt den Job vollständig zu deaktivieren.

Bekannte akzeptierte Risiken

CKV_DIO_4 ("Stelle sicher, dass der Firewall-Eingang nicht weit offen ist") wird einmal für die gesamte digitalocean_firewall-Ressource ausgelöst. Es wird durch einen einzelnen # checkov:skip=CKV_DIO_4:-Kommentar unterdrückt, der innerhalb des Ressourcenblocks in terraform/main.tf platziert ist. Die folgende Tabelle dokumentiert, warum jeder offene Port beabsichtigt ist.

Systemarchitektur```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

## Beobachtungen

Daten, die über 5 Tage des Live-Einsatzes (05.05.2026 bis 09.05.2026) erfasst wurden:

| Metrik                    | Wert     |
|---------------------------|----------|
| Gesamtverbindungen        | 41.700   |
| Anmeldeversuche           | 15.400   |
| Erfolgreiche Anmeldungen  | 868      |
| Ausgeführte Befehle       | 836      |
| Heruntergeladene Dateien  | 6        |
| Einzigartige Herkunftsländer | 106   |

### Top Angriffsländer

| Land               | Verbindungen |
|--------------------|--------------|
| Deutschland        | 9.768        |
| Niederlande        | 9.110        |
| Vereinigte Staaten | 7.706        |
| Vereinigtes Königreich | 3.858    |
| Singapur           | 1.770        |
| Belgien            | 1.422        |

### Anmeldedaten-Muster

Der am häufigsten versuchte Benutzername war `root` mit 3.866 Versuchen, gefolgt von `admin` (728) und `user` (494), was auf automatisierte Scanner hinweist, die auf Standard-Anmeldedaten und bekannte Dienstkonten abzielen. Das am häufigsten verwendete Passwort war `123456` (1.480 Versuche), gefolgt von `123` und `12345`, was auf wörterbuchbasierte Brute-Force-Werkzeuge hindeutet.

### Angreiferverhalten in der gefälschten Shell

868 Anmeldeversuche waren gegenüber dem gefälschten Anmeldedatensatz erfolgreich. Von diesen Sitzungen wurden 836 Befehle ausgeführt. Der häufigste Befehl war `uname -s -v -n -r -m` (360 Ausführungen) – ein standardmäßiger System-Fingerprinting-Befehl, der von automatisierten Post-Exploitation-Skripten ausgeführt wird, um das Zielbetriebssystem und die Architektur zu identifizieren, bevor eine Payload bereitgestellt wird. Weitere beobachtete Befehle umfassten `export HISTFILE=/dev/null` zur Deaktivierung der Shell-Verlaufsprotokollierung und `export HISTSAVE=/dev/null`, was darauf hindeutet, dass Angreifer aktiv versuchen, ihre Spuren zu verwischen, selbst in dem, was sie für ein kompromittiertes System hielten.

### Wichtigste Erkenntnis

Das Volumen des automatisierten Scan-Traffics – 41.700 Verbindungen in 5 Tagen aus 106 Ländern – bestätigt, dass jeder öffentlich zugängliche SSH-Dienst innerhalb von Stunden nach der Freischaltung ständigen Brute-Force-Versuchen ausgesetzt ist. Das Verhaltensmuster, sofort `uname` auszuführen, gefolgt von Befehlen zur Unterdrückung des Verlaufs, stimmt mit automatisierten Post-Exploitation-Frameworks überein, die mit minimaler menschlicher Beteiligung arbeiten.

## Verwendung

### Verwendung des Grafana-Dashboards

> Hinweis: Die Dashboard-Anmeldedaten werden in terraform.tfvars oder .env (für manuelle Bereitstellung) festgelegt.

Das Dashboard kann unter folgender Adresse aufgerufen werden:```
http://<your-droplet-ip>:3000

Anmelden mit admin / <GRAFANA_ADMIN_PASSWORD>.

Vom Cowrie-Honeypot akzeptierte Anmeldeinformationen

cowrie/etc/userdb.txt - enthält die akzeptierten Anmeldeinformationen für den Honeypot.

• Bearbeiten Sie diese Datei, um die Honeypot-Anmeldeinformationen anzupassen.

• Akzeptierte Anmeldungen setzen den Angreifer in eine gefälschte Shell, in der alle Befehle protokolliert werden.

• Abgelehnte Einträge werden als fehlgeschlagene Versuche protokolliert.

Projektdokumentation

Dieser Abschnitt beschreibt die getroffenen Entscheidungen und aufgetretenen Probleme während der Entwicklung dieses Projekts. Er dient als Reflexion des Entwicklungsprozesses und der gewonnenen Erkenntnisse. Überspringen Sie zu Sicherheitshinweise, wenn Sie nur wissen möchten, wie das Projekt zu verwenden ist.

Architekturentwurf und Kompromisse

Warum Cloud-Hosting?

• Honeypots sind darauf ausgelegt, hochverfügbar zu sein, um rund um die Uhr Daten zu erfassen und zu analysieren. Während der Honeypot auf einem lokalen Rechner mithilfe von virtuellen Maschinen oder Containern bereitgestellt werden könnte, ist es nicht praktikabel, diesen Rechner rund um die Uhr online und zugänglich zu halten. Cloud-Hosting bietet eine praktischere und zuverlässigere Lösung für den Betrieb des Honeypots und die kontinuierliche Datenerfassung.
• Da Cloud-Hosting es ermöglicht, bestimmte Ressourcen und Dienste auszuwählen, ist es außerdem einfacher, eine Codebasis zu erstellen und zu warten, die bereitgestellt und erweitert werden kann. Jeder, der seinen eigenen Honeypot bereitstellen möchte, kann dies ohne zusätzliche Schritte tun, solange das Projekt funktioniert und die bereitgestellte Umgebung dem entspricht, was das Projekt erwartet.

Warum DigitalOcean?

• Obwohl andere Anbieter wie AWS, GCP und Azure verfügbar sind, bietet DigitalOcean eine günstigere Option für dieses Projekt. Da ein Honeypot rund um die Uhr online sein und Daten in und aus dem Droplet senden muss, hilft das Preismodell von DigitalOcean, die Kosten vorhersehbar zu halten. Dies berücksichtigt nicht die Werbeaktionen anderer Anbieter, wie z. B. kostenlose Gutschriften oder Rabatte für Neukunden oder langfristige Verpflichtungen.

Warum Terraform?

• Die Alternative, manual-deployment.sh, ist für Benutzer gedacht, die keine Erfahrung mit Terraform haben oder es nicht verwenden möchten. Dieser Pfad erfordert die Bereitstellung eines Droplets, das Herstellen einer Verbindung, das Klonen des Repositorys und das Ausführen des Skripts. Mit Terraform ist eine schnellere Iteration möglich: Bearbeiten Sie die Codebasis und stellen Sie sie erneut bereit, ohne jeden manuellen Schritt von Ihrem lokalen Rechner aus zu wiederholen. Es erleichtert auch das Abbauen der Infrastruktur und den Neustart. Wenn das Projekt von einem einzelnen Honeypot zu einem Honeynet wächst, skaliert Terraform sauberer als die manuelle Bereitstellung oder das alte Skript allein.

Warum Cowrie?

• Cowrie ist ein bekannter, aktiv gewarteter Medium-Interaction-Honeypot. Es kann mehr Ressourcen verbrauchen als leichtere Fallen, aber seine Funktionen und die Übereinstimmung mit dem Rest des Stacks machten ihn zu einer natürlichen Wahl. Andere Honeypots könnten für bestimmte Anwendungsfälle ausgetauscht werden, obwohl viele nicht gewartet werden oder noch mehr Ressourcen benötigen.

Warum Loki?

• Die Haupteinschränkung war die Hardware: Log-Aggregation und -Suche auf einem 1 GB RAM Droplet mit mehreren anderen laufenden Diensten. Elasticsearch war zu schwer. Graylog hängt immer noch unter der Haube von Elasticsearch ab und lief innerhalb der Grenzen nicht richtig. Andere Optionen waren ähnlich ressourcenhungrig. Grafana Loki passte zum Stack und blieb innerhalb des Budgets, außer bei sehr schweren Abfragen. Einige Abfragefunktionen wurden geopfert: Wenn Dashboards zu viele Daten abrufen, wird Loki langsam, die UI fühlt sich träge an und der Honeypot kann Daten verpassen oder verzögern.

Warum Grafana?

• Ich hatte ursprünglich ein benutzerdefiniertes Dashboard in Betracht gezogen, aber Grafana ist vollständig, anpassbar und gut dokumentiert, was die Einrichtung beschleunigte, sodass ich mich auf das Sammeln und Versenden von Logs konzentrieren konnte. Es ist nicht so leichtgewichtig wie eine minimale benutzerdefinierte UI, aber nach einem kleinen Droplet-Upgrade läuft es komfortabel innerhalb der Hardware-Grenzen. Andere Tools mit vorgefertigten Dashboards hätten mehr Ressourcen verbraucht, ohne klare Vorteile für diesen Anwendungsfall zu bieten.

Warum Promtail?

• Promtail ist der etablierte Loki-Log-Versender (Grafana Alloy ist der neuere Nachfolger). Promtail ist speicherschonend und unterstützt Pipeline-Stufen (JSON-Parsing, GeoIP, Labels), die zu diesem Projekt passen. Alternativen wie Fluentd oder Logstash waren für ein 1-GB-Droplet zu schwer.

Warum GeoIP?

• Angriffskarten benötigen Stadt- und Länderkontext von Quell-IPs. Das Projekt verwendet DB-IP City Lite über scripts/geoip-update.sh: kein Konto oder API-Schlüssel erforderlich, was die Bereitstellung für jeden, der das Repo klont, einfach hält. Die integrierte GeoIP-Stufe von Promtail liest die lokale MMDB-Datei und fügt Labels für das Grafana-Geomap-Panel hinzu.

Systemausführungs-Durchlauf

Schritt-für-Schritt-Übersicht darüber, was passiert, wenn der Honeypot mit Terraform oder dem manuellen Bereitstellungsskript eingerichtet wird.

Terraform (empfohlen)

Auf Ihrem Rechner:

1. Konfigurieren Sie terraform/terraform.tfvars: API-Token, Pfad zum öffentlichen SSH-Schlüssel, Grafana-Passwort, Repo-URL/Branch, optionales manage_do_firewall
2. Führen Sie terraform init aus: installiert den DigitalOcean-Provider lokal
3. Führen Sie terraform apply aus: Terraform erstellt einen Plan und dann die Ressourcen oder aktualisiert sie

In DigitalOcean:

4. Der öffentliche SSH-Schlüssel wird auf Ihr Konto hochgeladen
5. Das Droplet wird aus Ihren Terraform-Variablen erstellt:
   • Image (Ubuntu), Größe und Region stammen von droplet_image, droplet_size, region usw.
   • Der SSH-Schlüssel aus Schritt 4 wird angehängt
   • user_data wird auf das gerenderte cloud-init gesetzt: Beim ersten Start erhält die VM den Admin-SSH-Port, das Repository repo_url / repo_branch und eine base64-codierte Kopie der generierten .env (Grafana-Passwort und ADMIN_SSH_PORT aus env.tftpl)
6. Cloud-Firewall (nur wenn manage_do_firewall wahr ist):
   • Terraform erstellt eine DigitalOcean-Firewall und ordnet sie diesem Droplet zu
   • Eingehendes TCP: Ihr Admin-SSH-Port, 22, 23 und 3000 (siehe terraform/main.tf)
   • Ausgehend: breites TCP/UDP und ICMP, damit das Droplet Pakete aktualisieren, Images ziehen und GeoIP-Daten herunterladen kann

Auf dem Droplet wird cloud-init automatisch ausgeführt:

7. Cloud-Config: package_update / package_upgrade, dann installierte Pakete (curl, git, ufw, …). Früh im Startvorgang erstellt write_files /root/honeypot.env (von Terraform gerendertes env.tftpl als base64: Grafana-Passwort, ADMIN_SSH_PORT, usw.)
8. runcmd-Bootstrap-Skript (Reihenfolge in terraform/templates/cloud-init.yaml.tftpl): Setzen von iptables / ip6tables auf Legacy-Backends
9. Swap: 2-GB-Datei, falls nicht vorhanden (/swapfile, fstab, swappiness)

Innerhalb von Docker Compose:

18. Loki startet und muss seinen Healthcheck bestehen (/ready auf Port 3100 im Container; auf dem Host nur 127.0.0.1:3100)
19. Promtail und Grafana warten darauf, dass Loki gesund ist (depends_on in docker-compose.yml), und starten dann
20. Cowrie kann unabhängig starten: es veröffentlicht die Host-Ports 22 und 23 in den Container und schreibt JSON-Logs unter data/cowrie-logs, die von Promtail gelesen werden

Manuelle Einrichtung (veraltet)

Benutzer erstellt die VM, verbindet sich per SSH und führt das Skript aus dem geklonten Repo aus.

manual-deployment.sh führt Folgendes aus:

1. .env laden und validieren
2. Systemupdate: apt update & apt upgrade
3. Pakete installieren: Tools plus ufw und iptables
4. Swap konfigurieren: 2-GB-Datei, falls nicht vorhanden
5. Docker installieren: Engine + Compose-Plugin, Dienste aktivieren
6. SSH konfigurieren: sshd auf ADMIN_SSH_PORT und ssh.socket deaktivieren
7. Firewall konfigurieren: scripts/setup-firewall.sh
8. GeoIP konfigurieren: scripts/geoip-update.sh und monatlicher Cron
9. Stack starten: docker compose pull / up -d, dann wartet das Skript auf Loki- und Grafana-Healthchecks und gibt eine Zusammenfassung aus

Aufgetretene Probleme

Hardware-Einschränkungen

• Begrenzte Hardwareressourcen führten zu langsamer Leistung und gelegentlichen Timeouts. Dies wirkte sich auf das Dashboard aus, das darauf angewiesen ist, die Datenbank schnell in benutzerdefinierten Intervallen abfragen zu können, manchmal von mehreren Geräten, die gleichzeitig auf das Dashboard zugreifen.

In Betracht gezogene Lösungen:

• Vertikale Skalierung für mehr Ressourcen
• Benutzerdefiniertes Dashboard mit weniger Panels, um die Belastung der Datenbank zu verringern
• Begrenzung der Anzahl der Geräte, die gleichzeitig auf das Dashboard zugreifen können
• Aggregieren von Logs in einer separaten Datenbank, aus der das Dashboard liest, um die Hauptdatenbank zu entlasten

Lösung:

• Auf ein etwas größeres Droplet mit besserer Leistung skaliert

Kompromisse:

• Während die Kosten um etwa 1–2 USD pro Monat stiegen, verdoppelten sich die verfügbaren Ressourcen. Der Zugriff auf NVMe-SSD-Speicher und mehr RAM im Vergleich zum Basic Droplet ermöglichte ein stabileres und leistungsfähigeres Dashboard. Dadurch wurde vermieden, Zeit in die Erstellung eines benutzerdefinierten Dashboards mit weniger Panels und einer weniger reaktionsschnellen Erfahrung zu investieren.

Erkenntnisse:

• So viele Ressourcen wie möglich innerhalb des Budgets durch Nutzung von Werbeaktionen, Rabatten und Preisstufen zu erhalten. Der Unterschied zwischen dem günstigsten Droplet und einer geringfügigen Kostensteigerung führte zu einer Verdoppelung der verfügbaren Ressourcen, was Zeit sparte, da ein vollständigeres Produkt ermöglicht wurde. Darüber hinaus bedeutete der frühere Betrieb des Honeypots, dass Daten früher erfasst und analysiert werden konnten.

Zeitüberschreitungsprobleme

• Beim Versuch, per SSH auf das Droplet für den Admin-Zugriff zuzugreifen, traten Timeouts auf. Separat schlug docker compose up fehl, da Port 22 bereits verwendet wurde und von Cowrie nicht gebunden werden konnte.

In Betracht gezogene Lösungen:

• sshd war falsch konfiguriert oder hörte auf dem falschen Port
• Firewall-Regeln blockierten den Admin-SSH-Port, nachdem er verschoben wurde
• Ein anderer Prozess hielt bereits Port 22

Lösung:

• Korrektur der Reihenfolge der Operationen: sshd wird zuerst auf ADMIN_SSH_PORT (Standard 2022) verschoben und neu gestartet, dann wird ssh.socket gestoppt und deaktiviert, um Port 22 für Docker freizugeben, damit Cowrie ihn binden kann. UFW-Regeln werden nach beiden Schritten angewendet, um den neuen Admin-Port zuzulassen.

Kompromisse:

• Keine funktionalen Kompromisse. Dies war eine Konfigurations- und Reihenfolgekorrektur.

Erkenntnisse:

• Es ist wichtig, sich aller Dienste bewusst zu sein, die bestimmte Ressourcen in einer bestimmten Reihenfolge freigeben müssen, bevor sie starten können. In diesem Fall auf Ubuntu 24.04 ist ssh.socket eine systemd-Socket-Unit, die Port 22 für die On-Demand-SSH-Aktivierung reserviert hält. Sie muss gestoppt und deaktiviert werden, bevor Docker den Host-Port 22 für Cowrie binden kann. Wenn sie noch aktiv ist, schlägt docker compose up mit „address already in use“ fehl.

Zukünftige Verbesserungen

GeoIP-Funktionalität

• Stadt-Level-GeoIP ist ungefähr. Die Karten-Panels hängen von der DB-IP-Datenbank ab und können einige IPs (Mobilfunk, VPNs, veraltete Daten) übersehen oder falsch beschriften. Der Stack könnte später um eine andere Datenbank oder eine Anreicherungspipeline für eine höhere geografische Genauigkeit erweitert werden.

Grafana HTTPS

• Grafana läuft derzeit über HTTP. Eine zukünftige Verbesserung wäre die Platzierung hinter einem Reverse-Proxy (nginx oder Caddy) mit einem TLS-Zertifikat, was auch die Einschränkung des Grafana-Ports auf localhost und das Proxying über 443 erlauben würde.

Proxy-Server-Funktionalität

• Um den Honeypot legitimer erscheinen zu lassen, könnte er über einen Server in einer anderen Region proxyt werden. Dies würde es Angreifern erschweren, ihn anhand seiner IP oder Geopositionierung als Honeypot zu identifizieren.

Sicherheitshinweise

• Grafana verwendet HTTP. Port 3000 ohne TLS bedeutet, dass Anmeldeinformationen im Klartext übertragen werden.
• Loki hört nur auf 127.0.0.1 (nicht exponiert)
• terraform.tfvars wird ignoriert und darf niemals committet werden.
• Cowrie läuft als unprivilegierter Benutzer innerhalb seines Containers.
• Grafana sollte hinter einem Reverse-Proxy mit HTTPS platziert werden, wenn es über eine Testumgebung hinaus exponiert wird.

Mitwirkende

• Oseguera12

Lizenz

GNU General Public License Version 2.0 (GPLv2) Siehe den vollständigen Lizenztext in der LICENSE-Datei.