Skip to content
KitploitKITPLOIT
StrumentiBlog
Log in
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
cyber-decoy — Broker di decoy sperimentale | Kitploit
Strumenti/GitHubGitHub/secdev02/cyber-decoy
Strumenti DifensiviSicurezza dei ContenitoriSicurezza di ReteThreat IntelligenceRilevamento IntrusioniAnalisi dei Log
GitHubsecdev02/cyber-decoy

cyber-decoy

Broker di decoy sperimentale

Vedi Repository
3112 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

cyber-decoy

Un'esca di rete containerizzata (honeypot) che pubblicizza SSH, RDP e SMB, osserva ogni connessione in entrata con eBPF e fa da proxy inverso per ogni sessione in un container di decoy isolato.

Il design separa due aspetti:

  1. Osservazione. Un classificatore eBPF TC collegato all'interfaccia del broker registra ogni SYN TCP in entrata, inclusi gli scan contro porte che il decoy non serve. Questo fornisce piena visibilità sull'attività di probing.
  2. Interazione. Un proxy inverso in userspace nel broker accetta connessioni sulle porte pubblicizzate e apre una connessione corrispondente al container decoy per quel servizio, trasferendo byte in entrambe le direzioni e registrando l'intera sessione.

Questo è uno strumento difensivo per rilevare e studiare attività non autorizzate su reti di tua proprietà o che sei autorizzato a monitorare. Distribuiscilo solo dove hai tale autorità.

Architettura

flowchart TB
    A["Attaccante / Scanner"]

    subgraph host["Host Decoy"]
        direction TB

        NIC["broker eth0<br/>pubblicate: 22, 3389, 445"]

        subgraph brk["container broker"]
            direction TB
            E["classificatore eBPF TC<br/>registra ogni SYN<br/>vede il vero IP sorgente"]
            P["proxy inverso<br/>CONNECT al backend"]
            L["log JSON strutturati"]
        end

        subgraph dec["decoynet (interna, senza route host)"]
            direction LR
            S["ssh-decoy<br/>OpenCanary ssh<br/>porta 2222"]
            D["rdp-decoy<br/>OpenCanary rdp<br/>porta 3389"]
            M["smb-decoy<br/>Server SMB Impacket<br/>porta 445"]
        end
    end

    A --> NIC
    NIC --> E
    NIC --> P
    E --> L
    P --> S
    P --> D
    P --> M

Quattro container in totale:

ContainerRuoloRete
brokerPorta pubblica: osservazione eBPF più proxy inversoedge + decoynet
ssh-decoyModulo ssh OpenCanary (handshake reale, cattura credenziali)solo decoynet
rdp-decoyModulo rdp OpenCanary (imitazione NLA, cattura nomi utente)solo decoynet
smb-decoySimpleSMBServer Impacket (SMB2/3 reale, cattura autenticazione)solo decoynet

I decoy vivono su una rete Docker internal (decoynet) senza route verso l'host o il mondo esterno. Solo il broker può raggiungerli. Niente che un attaccante faccia all'interno di un decoy può raggiungere direttamente la rete host.

Come funziona il routing eBPF

Il broker pubblica le porte 22, 3389 e 445 all'host, quindi i pacchetti in entrata arrivano su eth0 del broker. Due cose accadono quindi a ogni pacchetto:

  • Il programma eBPF TC in ingresso (broker/bpf/decoy.bpf.c) analizza le intestazioni Ethernet, IP e TCP, e per ogni tentativo di nuova connessione (SYN impostato, ACK non impostato) scrive un conn_event in un ring buffer: IP e porta sorgente, porta di destinazione, flag TCP e se la porta è un servizio pubblicizzato. Il pacchetto viene inoltrato inalterato (TC_ACT_OK).
  • Il proxy userspace accetta la connessione sul listener corrispondente e esegue l'equivalente di un CONNECT al backend decoy per quel servizio, quindi inoltra i byte in entrambe le direzioni.

La mappa eBPF advertised_ports viene popolata all'avvio da config.yaml, così il classificatore può etichettare se un probe ha colpito una porta servita o una non richiesta. Questo rende visibili gli scan di porte orizzontali anche se solo tre porte sono proxyate.

Se vuoi pubblicizzare "tutto è aperto" e convogliare porte di destinazione arbitrarie nel broker, estendi il classificatore per riscrivere la porta di destinazione o usa un reindirizzamento TPROXY / bpf_sk_assign. La versione corrente lascia il percorso dei pacchetti intatto e si limita all'osservazione, che è l'impostazione predefinita più sicura.

Layout del repository

cyber-decoy/
├── README.md
├── docker-compose.yml         # Stack a 4 container
├── docker-compose.override.yml # Sviluppo locale macOS: nessuna capacità eBPF, rimappatura porta 22
├── Makefile                   # Helper build / up / down / bpf
├── LICENSE
├── scripts/
│   └── setup.sh               # Controlli preliminari host
├── broker/
│   ├── Dockerfile             # Compila oggetto eBPF + binario Go
│   ├── config.yaml            # Servizi pubblicizzati (configurabili)
│   ├── go.mod
│   ├── main.go                # Punto di ingresso
│   ├── bpf/
│   │   └── decoy.bpf.c        # Classificatore eBPF TC
│   └── internal/
│       ├── config/config.go   # Caricatore configurazione
│       ├── proxy/proxy.go     # Proxy inverso TCP
│       └── bpf/loader.go      # Carica + collega eBPF, flusso eventi
└── decoys/                     # Tutti e tre eseguono OpenCanary
    ├── ssh/
    │   ├── Dockerfile
    │   └── opencanary.conf     # Modulo ssh, porta 2222
    ├── rdp/
    │   ├── Dockerfile
    │   └── opencanary.conf     # Modulo rdp, porta 3389
    └── smb/
        ├── Dockerfile          # Singolo processo Python, non-root
        ├── smb_decoy.py        # SimpleSMBServer Impacket + logging JSON
        └── requirements.txt    # impacket (bloccato)

Requisiti

  • Host Linux con kernel 6.6 o successivo per il percorso di collegamento eBPF TCX. Su kernel più vecchi il proxy continua a funzionare; solo l'osservazione eBPF viene saltata (il broker registra un avviso e continua).
  • Docker Engine con il plugin Compose (v2.24+ se usi il docker-compose.override.yml in bundle, che si basa sui tag !reset / !override).
  • Un filesystem BPF montato: sudo mount -t bpf bpf /sys/fs/bpf.

Architettura

L'immagine del broker rileva la sua architettura di build e passa la macro __TARGET_ARCH_* corrispondente a clang, quindi si compila sia su x86_64 che su aarch64 (Apple Silicon, Graviton). Nota che gcc-multilib è deliberatamente non installato: è un pacchetto solo x86 senza candidato arm64, e includerlo rompe la build su arm64 con codice di uscita apt 100. Solo clang e libbpf-dev sono necessari per compilare l'oggetto eBPF.

Sviluppo su macOS

Docker Desktop su macOS esegue i container all'interno di una VM LinuxKit anziché sul kernel host, quindi l'attacco TC/TCX eBPF generalmente non funzionerà lì. Questo non è fatale: eBPF è best effort per progettazione, quindi il broker registra ebpf disabled: attach failed e il proxy inverso più tutti e tre i decoy funzionano e registrano normalmente. Puoi sviluppare e testare l'intero percorso del proxy localmente, quindi ottenere la vera osservazione eBPF quando distribuisci su un host Linux.

docker-compose.override.yml viene caricato automaticamente e rende piacevole questa esperienza: rimuove le capacità eBPF (inutili nella VM) e rimappa la porta host 22 sulla 2022, poiché il sshd del Mac possiede la 22.

docker compose up --build                    # sviluppo locale, override applicato
docker compose -f docker-compose.yml up -d   # distribuzione reale, override bypassato

Esegui prima il controllo preliminare:

./scripts/setup.sh

Avvio rapido

# 1. Compila tutte e quattro le immagini (compila l'oggetto eBPF all'interno dell'immagine broker)
make build

# 2. Avvia lo stack
make up

# 3. Guarda cosa succede
make logs

Quindi sondalo da un'altra macchina (o localhost per un test rapido):

ssh -p 22 utente@DECOY_HOST          # colpisce il decoy SSH
nc DECOY_HOST 3389                 # colpisce il decoy RDP
nc DECOY_HOST 445                  # colpisce il decoy SMB
nc DECOY_HOST 8080                 # non pubblicizzato: osservato da eBPF, nessun proxy

Il broker emette JSON per eventi di probe eBPF e sessioni proxyate; ogni decoy emette eventi JSON OpenCanary. Per vedere le credenziali che arrivano:

Scarica lo strumento