Gli honeypot occupano un ruolo di primo piano all’interno di una struttura di difesa cibernetica di networking in quanto consentono di individuare, deviare o ingannare potenziali cyber criminali inducendoli a pensare che un’azienda abbia punti di ingresso non adeguatamente protetti nei suoi sistemi.
Parliamo di difesa cibernetica perché gli honeypot oltre che simulare sistemi tonti che si fanno attaccare o raggirare dagli attaccanti devono, lato backend, disporre di una certa furbizia o “finta intelligenza celebrale” che permetta l’individuazione di quanto sta accadendo sul lato frontend in quel momento.
Ecco, dunque, una guida utile per iniziare a distribuire un’infrastruttura honeypot e trarne vantaggio, evidenziando le considerazioni e le insidie che possono essere riscontrate nell’installazione di honeypot e nell’infrastruttura di supporto.
Indice degli argomenti
A cosa servono gli honeypot
Gli honeypot possono fornire informazioni preziose sul panorama delle minacce, sia su Internet aperto che sulla rete interna. Distribuirli correttamente non è sempre semplice, né tantomeno lo è interpretare le attività su di essi.
Poiché negli ultimi anni gli attacchi alle infrastrutture rivolte a Internet sono diventati per lo più automatizzati, gli honeypot hanno perso parte del loro significato nel rilevare nuovi exploit e attacchi a tale infrastruttura.
In combinazione con il fatto che le persone che gestiscono gli honeypot di solito non vogliono fornire dettagli su come li hanno personalizzati per evitare che vengano rilevati, questo ha portato a una situazione in cui cercare informazioni sugli honeypot diventa piuttosto complicato.
Tuttavia, sebbene le modalità di comportamento degli aggressori siano cambiate, gli honeypot continuano a fornire dati preziosi sulle campagne in corso, le credenziali utilizzate e i payload distribuiti.
Come funzionano gli honeypot
Sulla base di questa definizione, si può concludere che gli honeypot di solito imitano sistemi che sembrano vulnerabili e sono quindi bersagli preziosi per gli attacchi. I sistemi imitati possono essere servizi dall’aspetto vulnerabile come le connessioni SSH, database o client come, per esempio, browser e via dicendo.
Ad esempio, un browser viene emulato per trovare siti Web che, ad esempio, tentano di eseguire payload dannosi sui client, come cryptominer JavaScript o download di codice malevolo.
Nel primo caso, l’honeypot emula un server o un protocollo completo per trovare strumenti, tecniche e procedure utilizzate da malintenzionati. Tali honeypot possono essere utilizzati per scoprire ad esempio, attacchi su misura per superare dispositivi IoT pubblicamente accessibili o per riscattare istanze di basi dati non protette.
Gli honeypot lato server possono essere ulteriormente raggruppati in tre categorie in base al livello di emulazione che forniscono, quelli a bassa, media e ad alta interazione.
Gli honeypot a bassa interazione
Gli honeypot a bassa interazione sono piuttosto facili da costruire, poiché spesso emulano solo i comandi di base di un protocollo.
Per SSH, un honeypot a bassa interazione può consistere solo nella finestra di dialogo di accesso per raccogliere nomi utente e password potenzialmente utilizzati negli attacchi di credential.
Gli honeypot a media interazione
Gli honeypot di interazione media fanno un ulteriore passo avanti a questo principio ed emulano più comandi e parte del sistema circostante. Ad esempio, con l’interazione media il software Cowrie emula un filesystem completo e molti comandi di sistema integrati come lsof o netstat per sembrare un sistema completamente funzionante.
Gli honeypot ad alta interazione
Infine, quelli ad alta interazione rappresentano un’implementazione completamente funzionante del protocollo in questione, spesso reso disponibile tramite un proxy man-in-the-middle (MitM) che registra ogni interazione con l’honeypot.
Per SSH questo è rappresentato da Dockpot, che è un honeypot che esegue un sistema Linux completo in un’immagine, esponendo la connessione SSH attraverso un proxy MitM che registra tutte le interazioni e impartisce i comandi.
Per ogni connessione da un IP di origine diverso, verrà creato un nuovo contenitore e conservato fino al raggiungimento di un timeout. Ciò non solo consente la separazione delle connessioni, ma anche la persistenza tra le connessioni, poiché l’attaccante trova il filesystem con tutte le modifiche e le aggiunte che sono state eseguite durante la prima connessione.
Vantaggi e casi d’uso degli honeypot
Tutti e tre i gruppi hanno i loro vantaggi e casi d’uso. Mentre il livello di dettaglio e intuizione cresce da honeypot di interazione bassa ad alta, aumentano anche il potenziale di errore, la superficie di attacco, la domanda di risorse hardware e la complessità generale.
Gli honeypot a bassa e media interazione sono spesso sviluppati come script eseguiti da un interprete, per esempio Python. Sebbene forniscano informazioni limitate e siano relativamente facili da rilevare, possono essere installati praticamente su qualsiasi sistema operativo in grado di eseguire una distribuzione Python adeguata.
Potrebbe trattarsi di qualsiasi hardware, da un Raspberry Pi a hardware autonomo completo o implementazioni cloud.
Gli honeypot ad alta interazione sono spesso basati su tecnologie di virtualizzazione o “containerizzazione” e richiedono una configurazione più avanzata. Ciò include l’utilizzo di hardware sufficientemente potente, la configurazione del livello di astrazione e l’impostazione di macchine virtuali o container. Pertanto, è necessario conoscere obiettivi, budget e limiti di tempo prima di decidere quale honeypot distribuire.
Senza dubbio, il metodo più affidabile per la raccolta dei dati frontend, che è anche il più impegnativo, è l’utilizzo degli honeypot.
Ci sono diverse insidie e scenari da considerare a seconda del caso d’uso. Dopo una corretta implementazione, il passaggio successivo consiste nel raccogliere i dati generati e i possibili payload in un’unica repository per consentire la generazione di metriche e il monitoraggio dell’intera infrastruttura.
Cosa tenere presente nella distribuzione degli honeypot
Esistono due scenari principali da considerare quando si distribuiscono gli honeypot, le distribuzioni interne rispetto a distribuzioni con connessione Internet. Entrambi sono scenari validi ma coprono diversi casi d’uso.
In una distribuzione interna, gli honeypot possono essere considerati trappole o sistemi di allarme. L’idea è di distribuirli in tutta l’infrastruttura aziendale, preferibilmente vicino ai server di produzione.
Se un utente malintenzionato cerca un punto d’appoggio in una rete, si imbatte in questi sistemi strategicamente posizionati e cerca di utilizzarli per guadagnare l’accesso. Idealmente, questi honeypot saranno stati impostati per generare allarmi se vengono rilevate connessioni in entrata, poiché non vi è alcun uso legittimo su di loro nelle operazioni quotidiane.
Questo scenario può supportare misure esistenti come i sistemi di rilevamento delle intrusioni o il monitoraggio dei registri come componente attivo per aumentare le possibilità di rilevamento precoce degli intrusi.
Le distribuzioni esposte verso Internet potenzialmente ci mostrano in che modo tentano di attaccare l’infrastruttura dall’esterno.
Le distribuzioni su Internet, d’altra parte, sono più personalizzate per la raccolta di dati su attacchi diffusi. Questo può variare da informazioni di base come i servizi attaccati, per esempio l’individuazione di quanto sono comuni gli attacchi contro Android Debug Bridge, o le credenziali utilizzate, fino a informazioni dettagliate TTP, cioè quali comandi e o script vengono eseguiti, tentativi di spostamento laterale, tecniche di persistenza e possibili tentativi di evasione.
A differenza delle distribuzioni interne, queste sono costantemente esposte al traffico mondiale, pertanto sono sempre da considerarsi compromessi.
Poiché queste distribuzioni mirano a non fornire protezione diretta a una rete interna, è consigliabile isolare completamente gli honeypot con connessione a Internet dall’infrastruttura di produzione. Un isolamento che va oltre una DMZ (zona demilitarizzata), quindi un isolamento pressoché totale.
Suggerimenti per gli scenari di distribuzione degli honeypot
Oltre a queste specifiche, possiamo anche dare alcuni suggerimenti generali per tutti gli scenari di distribuzione. Poiché questi sistemi sono considerati insicuri in base alla progettazione, è consigliabile trattarli di conseguenza.
Non è ammissibile quindi lasciare dati di produzione neanche parziali o informazioni aziendali su di essi, così come riutilizzare nomi utente, password, certificati e chiavi SSH. In caso contrario, se gli aggressori riescono a infrangere l’honeypot al sistema operativo di hosting, potranno ottenere preziose informazioni sull’infrastruttura interna e sui nomi utente attivi.
Inoltre, è consigliato di eseguire i servizi honeypot con utenza non amministrativa, con permessi minimi e non in grado di utilizzare comandi di gerarchia di amministratore root. In caso di compromissione, ciò rende notevolmente più difficile per gli aggressori aumentare i privilegi.
Poiché la maggior parte dei servizi emulati sono in esecuzione nella gamma di porte di sistema che richiedono privilegi elevati, è prudente eseguirli su porte non di sistema e utilizzare le regole di inoltro di iptables per farli sembrare in esecuzione sulla porta di sistema.
Se vengono distribuiti honeypot per servizi comuni come SSH e FTP, dovrebbero essere in esecuzione sulla porta predefinita dei servizi. Soprattutto per SSH come mezzo di accesso per la maggior parte dei sistemi, si consiglia di disabilitare l’autenticazione della password e il login di root per il server SSH reale, oltre a eseguirlo su una porta non standard per liberare la porta 22 per l’honeypot.
Ciò significa anche che è consigliata la creazione di un alias SSH nelle configurazioni locali per evitare di connettersi accidentalmente all’honeypot SSH durante la manutenzione o l’applicazione di modifiche alla configurazione.
Un’altra considerazione è il servizio di hosting per l’infrastruttura. Se non è ospitato su un’infrastruttura di proprietà dell’azienda, è conveniente utilizzare un provider VPS di fascia bassa per ospitarlo.
Sfortunatamente, questi sistemi tendono a essere attaccati pesantemente, quindi vale la pena essere pronti e coscienti a perdere questi sistemi in qualsiasi momento.
In generale, le distribuzioni automatiche basate su strumenti come Ansible o Puppet dovrebbero essere utilizzate per risultati riproducibili e per ridurre il rischio di configurazioni errate. Combinato con una strategia di backup per i dati raccolti, i log e i payload, si garantisce la resilienza alla perdita di dati.
Inoltre, è consigliato di ridurre al minimo l’utilizzo di risorse basate sul sistema operativo per i requisiti specifici degli honeypot. Ad esempio, l’utilizzo di ambienti virtuali locali per progetti basati su Python dovrebbe essere preferito rispetto all’utilizzo di installazioni di pacchetti a livello di sistema per evitare problemi di dipendenza con più progetti in esecuzione sullo stesso livello o aggiornamenti del sistema operativo che interrompono le dipendenze.
Per quanto riguarda i run-up, è anche consigliabile monitorare il regolare funzionamento degli honeypot distribuiti compreso l’utilizzo dello storage, idealmente con test automatizzati su misura per il rispettivo protocollo.
In generale, si sta esponendo al mondo un sistema che sembra vulnerabile e molto probabilmente lo è, ma in altro modo di quanto si pensi.
Le implementazioni honeypot, soprattutto quando si affacciano su Internet, sono un campo di gioco asimmetrico con vantaggi per gli attaccanti. Gli aggressori hanno infiniti modi e tempo per provare gli attacchi, per esempio l’operatore autorizzato deve solo commettere un errore per esporre l’host honeypot, e probabilmente la rete circostante agli attacchi.
Oltre alla distribuzione, ci sono più cose da prendere in considerazione.
Gli aggressori cercano costantemente di individuare gli honeypot, con varie tecniche e percentuali di successo variabili.
Questi sono solo indicatori nella giusta direzione. Si consiglia di monitorare costantemente la propria infrastruttura honeypot e di tenere sotto monitoraggio le disconnessioni che si verificano sempre dopo comandi o flussi di lavoro specifici, poiché possono indicare strategie di evasione.
È importante tenere conto anche dei piccoli segnali di tentativi d’intrusione in quanto potenzialmente questi piccoli tentativi svelano un progetto d’intromissione a lungo termine e lunga scala verso la nostra rete.
Regole di personalizzazione dei sistemi di difesa
Molti honeypot sono dotati di un set predefinito di parametri emulati tra cui nome host, versione del servizio e credenziali. Ciò è particolarmente comune negli honeypot a bassa e media interazione.
Nel contesto delle configurazioni honeypot, la personalizzazione è la chiave per la mitigazione dell’evasione. Ad esempio, viene preso in considerazione l’honeypot SSH Cowrie.
Se la configurazione predefinita non viene modificata, accetta l’utente “Richard” con la password “fout”, annunciando poi che il suo nome di sistema è “svr04”. Il controllo di configurazioni predefinite come queste è relativamente facile e quindi accade spesso.
Come misura preventiva, l’impronta dell’honeypot dovrebbe essere il più personalizzata possibile. In particolare, i nomi host annunciati, le versioni dei servizi e i banner sono dati che possono essere modificati.
Per honeypot a bassa e media interazione può anche essere una valida strategia cambiare gli output dei comandi emulati e creare sottocartelle di filesystem personalizzati per rendere ulteriormente unico il finto sistema.
Come raccomandazione generale, si dovrebbe monitorare attentamente gli honeypot distribuiti sulla topologia, specialmente nei primi giorni di implementazione, poiché sono “freschi” e sconosciuti a questo punto.
Per restare con l’esempio di Cowrie, è possibile individuare abbastanza facilmente le tecniche di evasione nei log generati. In tutti i casi il flusso di lavoro dei comandi sul sistema è lo stesso fino a un punto specifico in cui i comandi falliscono o non vengono eseguiti affatto.
Non sono disponibili molte attenuazioni per compromissioni di penetrazione. A causa della natura stessa degli honeypot a bassa e media interazione, la mitigazione più praticabile è passare a un sistema ad alta interazione.
Gli honeypot ad alta interazione presentano un ambiente completo e persistente a una connessione in entrata che viene spesso memorizzata nella cache anche attraverso le riconnessioni. Ciò significa che tutti i payload rilasciati o scaricati sono disponibili per l’esecuzione invece di essere eliminati dall’honeypot.
Un altro esempio è quello di considerare un honeypot SMTP. Gli aggressori proveranno a connettersi a un server di posta e inviare un messaggio di prova alla propria infrastruttura per verificare se il server di posta consente il traffico di posta in uscita.
Una possibile mitigazione è consentire alla prima posta di ogni connessione di lasciare transitare l’honeypot. Si tenga presente che ciò ha implicazioni legali poiché tecnicamente il sistema in questo modo invia spam.
Oltre al test di produzione completo, ci sono altri controlli di integrità che possono essere osservati. Come linea guida generale, gli honeypot distribuiti dovrebbero esporre una configurazione e un dimensionamento simili alle loro controparti del mondo reale.
Ciò può essere ottenuto più facilmente su honeypot di interazione bassa e media poiché spesso emulano comandi cercando file di testo che facilitano enormemente lo spoofing degli stati del cluster, delle configurazioni delle repliche o persino delle dimensioni del filesystem.
Monitoraggio dei registri e degli eventi interessanti
Dopo l’installazione e la personalizzazione, gli honeypot distribuiti iniziano a generare dati. Una delle sfide principali in questa fase è il monitoraggio dei registri e la ricerca di eventi interessanti.
Poiché i registri non sono utilizzati lato utenza, sono notoriamente difficili da leggere e controllare. È qui che entrano in gioco le visualizzazioni. Quindi è consigliabile inserire i log in un sistema centrale come Elastic o Splunk che indicizza i dati generati.
Oltre a rendere disponibili tutti i dati di log per la dashboard, c’è l’ulteriore vantaggio di rendere disponibili su un sistema centrale i log di tutti gli honeypot distribuiti dell’intera infrastruttura, ciò consente la generazione di dashboard e report dell’intera infrastruttura e informazioni più approfondite.
L’utilizzo delle dashboard non è la miglior soluzione da usare per ottenere informazioni approfondite sui dati prodotti dai registri.
È ancora responsabilità dell’utente ripulire i dati prima di tracciarli. In questo contesto è possibile prendere in considerazione il prestito di procedure comuni di preparazione di set di dati dall’area dell’apprendimento automatico dell’honeypot stesso.
Alcuni suggerimenti possono essere la necessità di deduplicazione di eventi, per esempio più connessioni dallo stesso IP di origine. Anche se in alcuni scenari questo può essere interessante per trovare attacchi di credential stuffing, può essere controproducente in altri, come il conteggio assoluto di connessioni univoche in un determinato periodo di tempo.
Conclusioni
Distribuire e integrare con successo degli honeypot e software di supporto in un’infrastruttura esistente può essere un compito arduo che richiede una discreta quantità di pianificazione.
Tuttavia, i vantaggi sono evidenti in quanto se integrati correttamente, gli honeypot consentono un avviso più rapido e una visione preventiva delle attuali strategie di attacco e degli attacchi automatizzati contro l’infrastruttura disponibile al pubblico, supportando al contempo integrazioni basate su TIP come MISP o TheHive velocizzano e migliorano la qualità di valutazione e riducono la quantità di lavoro manuale svolto dagli analisti.
Combinato con una raccolta di registri diffusa e dashboard ben progettate, questo complementa strategie difensive migliori e contromisure da nuovi attacchi. Soprattutto con la continua popolarità delle tecnologie di virtualizzazione basate su container, si prevede che gli honeypot ad alta interazione guadagneranno popolarità e daranno trazione allo sviluppo.
Allo stato attuale, questo tipo di honeypot è notevolmente più difficile da rilevare, il che lo rende ideale per l’utilizzo nelle distribuzioni con connessione Internet. Ciò è dovuto al fatto che l’architettura mitiga la maggior parte delle tecniche di evasione comunemente utilizzate semplicemente essendo un sistema completamente personalizzato che si comporta in modo coerente e il più vicino possibile a un sistema reale.
Gli honeypot hanno un valore incalcolabile, sia come sistema di avviso preventivo, sia per l’infrastruttura interna o come sensore per scoprire campagne in corso e attacchi di credential stuffing, raccogliendo informazioni di valore senza interazione manuale.
RIFERIMENTI BIBLIOGRAFICI
An awesome list of honeypot resources
T-Pot – The All In One Honeypot Platform
Honeytrap. Advanced Honeypot framework
Cymmetria honeycomb: an extensible honeypot framework
Splunk Dashboards for your Honeypot infrastructure
CMSecurity mailhon: a Python3 SMTP honeypot
CMSecurity CameraObscura: IP Cam Honeypot
Low interaction honeypot designed for Android Debug Bridge over TCP/IP
