Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Manuel Roccon : 14 Ottobre 2024 07:25
Se possiamo definirlo in poche parole direi che l’HoneyPot è un succulento dolcetto in bella vista pronto ad essere azzannato. Infatti contiene dei servizi e vulnerabilità comuni che hanno l’obiettivo di attirare l’attenzione un aggressore che volesse eseguire una ricognizione nei nostri sistemi o possibili movimenti laterali.
Grazie a questa esca, una volta che l’aggressore esegue attività di ricognizione come scansioni, attacchi brute force ecc…, queste vengono prontamente comunicati alla vittima in modo che possa prendere le adeguate contromisure e conoscere l’esistenza di un ospite indesiderato.
Queste esche possono essere posizionate su un qualunque perimetro, come per esempio DMZ, nelle reti IT oppure nelle reti OT. Infatti queste ultime per esempio reti più difficili da monitorare e a difendere rispetto alle altre ovviamente per la tipologia di dispositivi collegati.
Vuoi diventare un Ethical Hacker?
Non perdere i nostri corsi e scrivi subito su WhatsApp al numero
375 593 1011
per richiedere informazioni dicendo che hai trovato il numero sulle pagine di Red Hot Cyber
Supporta RHC attraverso:
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
Ovviamente a seconda di dove piazziamo queste sonde, dobbiamo usare quelle giuste.
Infatti possono essere delle applicazioni che imitano altre, che emulano servizi comuni in ambito IT oppure altre in ambito OT che emulano sistemi PLC o SCADA con vulnerabilità conosciute.
Un honeypot è progettato per replicare un vero sistema informatico.
Questo può spesso essere sotto forma di una pagina di accesso, oppure servizi o applicazioni aziendali tipicamente conosciute e interessanti per gli aggressori, incluse credenziali semplici facili da “exploitare”.
Quando un aggressore effettua il login, l’honeypot rileverà tale attività e invierà immediatamente un avviso all’IT o a un team di sicurezza, fornendo visibilità e tracciando il comportamento.
Questo comportamento potrebbe essere un attacco diretto o un movimento laterale verso un altro sistema compromesso che la vittima non ha avuto evidenza.
Esistono due tipi principali di design di honeypot:
Gli honeypot di produzione è la tipologia più comune. Questa tipologia raccoglie dati sulla sicurezza informatica all’interno della rete di produzione di un’organizzazione con l’obiettivo di identificare tentativi di compromissione e raccogliere dati sui criminali informatici, come indirizzi IP di origine, frequenza del traffico e altro. Un honeypot di produzione funge da esca, mimetizzandosi con il resto dei sistemi e servizi legittimi nelle reti dove viene inserito.
Gli honeypot di ricerca in genere raccolgono più dati degli honeypot di produzione, con l’obiettivo specifico di raccogliere informazioni sulle tecniche degli aggressori.
Mentre le aziende in genere utilizzano honeypot di produzione, il governo e le organizzazioni di ricerca possono utilizzare un honeypot di ricerca.
Honeypot a bassa e alta interazione
All’interno di queste due categorie, ci sono anche diversi tipi di honeypot per vari livelli di complessità.
Gli honeypot ad alta interazione gestiscono una varietà di sistemi di produzione reali progettati per attirare gli aggressori. Un team di ricerca può utilizzare honeypot ad alta interazione per apprendere gli strumenti utilizzati da un aggressore. Tuttavia, gli honeypot ad alta interazione richiedono una notevole quantità di tempo e sforzi per essere impostati e mantenuti, il che non li rende adatti a team più piccoli o meno esperti.
Gli honeypot a bassa interazione, sono relativamente più semplici da implementare perché sono ambienti molto più statici. Mentre un honeypot ad alta interazione agisce essenzialmente come un sistema reale e offre agli aggressori l’opportunità di interagire con una varietà di servizi, un honeypot a bassa interazione offre agli aggressori un accesso limitato al sistema operativo ed emula solo una piccola quantità di servizi e protocolli. Pertanto non sono così efficaci e approfonditi; invece, sono più utili per rilevare minacce meno complesse come i bot, scansioni e ricognizioni comuni.
Gli honeypot sono uno dei meccanismi di rilevamento più potenti che una rete possa avere. Un honeypot completamente configurato può aiutare a rilevare e permettere fermare gli attacchi informatici con estrema precisione.
La presenza di avvisi provenienti dagli honeypot è un chiara segnalazione di un intrusione senza senza alcun dubbio.
Se si dovessero ricevere segnalazioni da queste sonde, si tratterebbe di sicuro di un attacco reale, di un utente curioso oppure di un test di sicurezza pianificato.
Inoltre rende la vita più difficile agli aggressori. Gli honeypot tendono a frustrare gli aggressori facendo perdere tempo in questo asset controllato, consentendo alla vittima di conoscere questa attività in corso e prendere le dovute contromisure.
Ci sono alcuni rischi e limitazioni nell’uso degli honeypot, specialmente se vengono distribuiti in modo improprio.
A volte richiedono hardware per essere implementati quindi potrebbero essere costosi. Sebbene gli honeypot siano generalmente leggeri in termini di risorse, gli honeypot più complessi, come gli honeypot ad alta interazione e di ricerca, necessitano di hardware per apparire il più realistici possibile.
La manutenzione e configurazione possono richiedere tempo in quanto configurare e gestire gli honeypot, di nuovo può richiedere molto tempo, impegno e competenza.
Ora arriviamo al pezzo forte e passiamo alla parte pratica.
Anche se se ne parla poco, di honeypot se ne trovano molti, e di questi molti sono progetti open source. Possiamo in questa repository divisi per ambiti e applicazioni:
https://github.com/paralax/awesome-honeypots
Possiamo trovare infatti progetti molto verticali, come CitrixHoneypot, specifiche per alcune tipologie di reti come Conpot verticalizzati sulle reti OT.
Nel nostro esempio utilizzeremo OpenCanary, un honeypot a bassa interazione che emulerà porte comuni esposte in un server, utile da inserire per esempio in qualche subnet critica della nostra rete, come quella dei server o DMZ.
Alcune porte che possono essere emulate e monitorate sono:
Le porte sono ovviamente tutte personalizzabili.
Cosa è necessario per creare questo laboratorio:
Come accennato, OpenCanary è un honeypot di rete multiprotocollo OpenSource.
https://github.com/thinkst/opencanary
OpenCanary non fornirà nessun strumento di alert integrato ma solo i log dei rilevamento che poloperà in un suo log, lo agganciamo a Wazuh, un SIEM (sarebbe più corretto dire che è un XDR) in cui raccogliamo questi dati per poi visualizzarle anche in delle semplici dashboard.
Come da wiki eseguiamo questi comandi per installare i pacchetti necessari e installare OpenCanary:
sudo apt-get install python3-dev python3-pip python3-virtualenv python3-venv python3-scapy libssl-dev libpcap-dev
virtualenv env/
. env/bin/activate
pip install opencanarySe volessimo attivare in seguito i moduli Windows File Share e SNMP installiamo anche questi pacchetti:
sudo apt install samba
pip install scapy pcapy-ngcreiamo la configurazioni iniziale
opencanaryd --copyconfigCon questo comando verrà creato il file di configurazione al seguente percorso:
/etc/opencanaryd/opencanary.confAprendolo possiamo abilitare modulo per modulo, impostando “modulo.enabled=true” come visualizzato
qui sotto.
Da notare il primo parametro device.node_id servirà in seguito per identificare se ci fossero più sonde. In questo caso ho configurato tutto per poter utilizzare un id numerico, come ad esempio opencanary-1, opencanary-2 ecc…
In questo file possiamo personalizzare anche il file di log, ma non è necessario.
NB: per attivare i moduli non devono esserci altri servizi che utilizzino le porte impostate, per esempio se si volessero monitorare gli accessi SSH è necessario modificare la vera porta standard SSH.
Ora possiamo avviare il programma ogni volta che non sia in esecuzione con i comandi:
. env/bin/activate
opencanaryd --startPossiamo verificare le porte che sono state aperte direttamente da netstat.
Se abbiamo abilitato http, possiamo fare un test veloce accedendo via web al server. Comparirà un finto accesso a un nas Synology, un target molto ghiotto per chi lo rilevi in rete (che ci siano i backup?).
Questa interfaccia grafica per esempio è completamente personalizzabile per emulare portali differenti, se provassimo ora a eseguire un accesso con qualsiasi credenziale l’attività verrà riportata al seguente file.
\var\tmp\opencanary.logDi default viene generato un log come questo:
{“dst_host”:”192.168.50.131″,”dst_port”:80,”local_time”:”2024-10-04 13:21:09.282481″,”local_time_adjusted”:”2024-10-04 13:21:09.282929″,”logdata”:{“HOSTNAME”:”192.168.50.131″,”PATH”:”/index.html”,”SKIN”:”nasLogin”,”USERAGENT”:”Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)”},”logtype”:3000,”node_id”:”opencanary-1″,”src_host”:”192.168.50.133″,”src_port”:52362,”utc_time”:”2024-10-04 13:21:09.282890″}
I valori principali sono il node_id che indica la soda da quale è arrivato l’alert, src_host che indica da dove è partito l’attacco e logtype.
Questo ultimo valore non è documentato benissimo, ma identifica alcuni gruppi di attività.
Analizzando dei dati ricevuti nei test esempio log_type può assumere il significato:
3000 = apertura del applicativo web
5001 = scansione di rete
3001 = tentativo di login
Come prerequisito, avevamo indicato è necessario predisporre un’installazione di Wazuh, pulita o già in uso che sia.
Quindi sulla macchina Ubuntu 24 andiamo ad installare il suo agente con questo comando:
wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.8.0-1_amd64.deb && sudo WAZUH_MANAGER='192.168.50.137' WAZUH_AGENT_NAME='OpenCanary' dpkg -i ./wazuh-agent_4.8.0-1_amd64.debdove WAZUH manager è IP del server Wazuh.
Una volta installato aggiungiamo alla fine del file di configurazione questo codice, che farà in modo allagent di monitorare questo file che OpenCanary andrà a popolare:
/var/ossec/etc/ossec.confQui trovate una referenza: https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/index.html
Quindi andremo a metterci alla fine questa configurazione:
Salviamo e avviamo/riavviamo il servizio agent
systemctl restart wazuh-agent
Infine ora andiamo a configurare Wazuh per collezionare i log e visualizzarli in una dashboard, in quanto come abbiamo detto il progetto non integra nessun modo avvisi.
La fortuna che abbiamo è che Opencanary genererà un file json al percorso con i log dei rilevamenti \var\tmp\opencanary.log come nell’esempio sottostante.
Wazuh nativamente dispone già di una “rule” e “decoder” per catturare questi dati in questo formato.
L’unica cosa che dobbiamo fare invece è fare in modo che Wazuh una volta acquisiti i dati che li importi, quindi dobbiamo impostare il livello di alert.
Quindi accedendo alle roles dalla dashboard
aggiungendo alle regole locali nelle local_rules.xml.
Questa configurazione:
La regola come è stata messa sopra il 10000 come da documentazione per le regole custom, ma è necessario verificare che non siano già state inserite regole con lo stesso ID.
Referenza sulle custom rule: https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html
Ora testando di nuovo la regola possiamo vedere che è stata filtrata correttamente e una volta che verrà generato questo evento verrà importata.
In questo esempio ho catalogato semplicemente tutti gli eventi che contengono un node_id definito, si potrebbe anche suddividere gli eventi per log_type impostando una descrizione e level differente per ciascuno.
A questo punto possiamo provare a utilizzare NMAP per scansionare i servizi e far generare attività di ricognizione e bruteforce.
Per prima cosa analizziamo porte e aperti e servizi attivi, possiamo vedere che le nostre porte aperte viste sopra con netstat vengono rilevate e identificate da NMAP.
Con una scansione più intrusiva invece possiamo attivare più alert possibili.
Questi alert infine possiamo rilevarli tramite funzione di discovery.
A questo punto possiamo vedere graficamente queste attività anomale che arrivano dalla sonda come negli esempi sottostanti.
Ho creato al volo delle semplici dashboard partendo dai dati acquisiti, così la visibilità di questi eventi sarà molto più facile e immediata.
In questo articolo abbiamo accennato a cosa siano e cosa servono gli honeypot, mostrando anche un caso pratico di utilizzo.
Questi dispositivi generando pochissimi falsi positivi, in quanto generalmente nessuno dovrebbe essere interessato ad accedervi come descritto prima, possono essere veramente utili al fine di rilevare attività sospette all’interno delle reti informatiche.
Manuel Roccon
Copyright @ 2003 – 2024 RED HOT CYBER
PIVA 16821691009