No results found
Nella terminologia della sicurezza IT e di rete, da qualche tempo troviamo il termine Honeypot, che letteralmente significa “barattolo di miele”: questo nome non è affatto casuale ma vuol essere allegorico per indicare che come il barattolo di miele può attirare un orso e tendergli una trappola, l’Honeypot di una rete informatica è un sistema, hardware o software, che viene utilizzato come “esca” nei confronti di un eventuale attaccante, allo scopo sia di smascherare un attacco informatico sulla rete, sia di farlo arrivare allo strumento che adotterà le contromisure del caso.
In questo tutorial spiegheremo di che cosa si tratta esattamente, come si utilizza e quali benefici può portare nella sicurezza informatica.
L’honeypot permette di studiare il comportamento di un attaccante e può fornire informazioni preziose per migliorare la sicurezza complessiva del contesto di rete preso in esame.
Nello specifico, un honeypot fornisce informazioni dettagliate sulla natura e sulla frequenza degli attacchi che coinvolgono la rete bersaglio. Molto dipende dalla tipologia di honeypot che si intende installare, giacché, come si vedrà tra breve, esistono vari tipi di honeypot per soddisfare molteplici esigenze applicative.
Per poter essere efficace, l’honeypot viene tipicamente collocato in un segmento di rete isolato (ad esempio, una VLAN ad-hoc ossia creata allo scopo) e che contiene alcuna informazione critica o rilevante; potremmo considerare questo segmento come il binario morto di una ferrovia o un viottolo senza uscita, dove portare l’attaccante per isolarlo e farlo cadere in trappola senza che possa fare danni. L’immagine seguente schematizza questo posizionamento, che nello specifico è sulla connessione Internet, prima del router e del firewall che va a separare Internet dai due segmenti di rete.
Il posizionamento in posizione isolata e non comunicante con il resto della rete è determinante perché, come verrà spiegato tra breve, se l’honeypot non viene configurato adeguatamente rischia di causare dei danni anche rilevanti.
Per quanto nasca per essere utile, come molti strumenti l’honeypot può essere un’arma a doppio taglio, tanto che un utilizzo improprio può causare danni; infatti, prima dell’utilizzo l’honeypot deve essere configurato adeguatamente, altrimenti esso stesso può diventare un rischio per la rete, in quando, ad esempio, un attaccante potrebbe sfruttare un honeypot che non è stato configurato correttamente per effettuare un’azione di “pivoting” verso altre reti o altri sistemi e in un certo senso, quindi, l’honeypot andrebbe ad aprire la porta della rete alla minaccia in arrivo, perché appoggiandosi ad esso, l’attaccante poi penetra la rete vera e propria, ossia quella di produzione.
In contesti di rete particolarmente critici o complessi, si tende ad utilizzare più honeypot. In questo caso si fa riferimento al concetto di “honeynet” perché si realizza una sorta di rete formata da tanti honeypot.
Una honeynet viene utilizzata per monitorare ampi e molteplici segmenti di rete, perché un solo honeypot non sarebbe sufficiente. Quindi la prasi ricorrente è installare un honeypot su ciascun segmento di rete da monitorare.
Sia gli honeypot che le honeynet possono essere parte di un più ampio sistema NIDS (Network Intrusion Detection System). Il funzionamento di un sistema IDS è indubbiamente più completo del semplice honeypot, il quale può esserne una parte sia da solo che inserito in una honeynet.
Esistono molti tipi di honeypot, che possono essere suddivisi in base a due fattori principali:
Analizziamo dettagliatamente tutte le categorie partendo dalla distinzione per tipologia di utilizzo.
Andiamo ora ad esaminare nel dettaglio le tre categorie di honeypot che rientrano nella classificazione per modalità di interazione con la rete.
Esistono quindi honeypot che sono la combinazione di questi elementi, vale a dire che per la tipologia di utilizzo DI PRODUZIONE possiamo avere honeypot puri, ad alta interazione e a bassa interazione; analogamento, possiamo avere honeypot di ricerca puri, a basa e ad alta interazione.
Ciò detto, si può iniziare a vedere in che modo lavorare con gli honeypot, premettendo che in questo tutorial approfondiremo la tipologia di honeypot di PRODUZIONE basata sulla modalità di interazione A BASSA INTERAZIONE. Questo perché ai fini didattici è meglio utilizzare questi ultimi in quanto la loro configurazione è più semplice e inoltre sono strumenti mirati alla ricerca di attacchi generici. Se utilizzassimo degli honeypot DI RICERCA, essendo questi ultimi molto specializzati finiremmo col confinare il tutorial a uno o due esempi specifici.
Le suddette tipologie di honeypot (di produzione e a bassa interazione) possono essere installate sia su sistemi Windows che su sistemi Linux/Unix. Riguardo all’ambiente Linux, da precisato che la configurazione degli honeypot richiederà diverso tempo perché non è affatto semplice o breve. Invece quelli per Windows hanno solitamente un’interfaccia grafica che ne semplifica notevolmente la configurazione.
KFSensor, un honeypot per Windows
Negli esempi proposti qui di seguito utilizzeremo KFSensor (http://www.keyfocus.net/kfsensor/) che è un honeypot per sistemi operativi Windows. Lo abbiamo scelto per ragioni di semplicità e immediatezza nella configurazione, fermo restando che quello che andrà a fare sarà sostanzialmente lo stesso che farebbe un honeypot per Linux, quindi a livello dimostrativo è indifferente.
KFSensor è disponibile in versione trial che presenta tutte le funzionalità abilitate e valide per una durata di 30 giorni. Alcune delle funzionalità che ci mette a disposizione questo strumento sono:
Un honeypot, per poter funzionare come esca, deve poter monitorare il traffico di rete e analizzare i pacchetti di dati scambiati; non a caso KFSensor utilizza le stesse librerie impiegate in Wireshark (che è un tool specifico per l’analisi del traffico di rete). KFSensor è stato progettato per attirare e rilevare gli attacchi di hacker e worm “simulando” ovvero comportandosi come un servizio di sistema vulnerabile.
Il tool è pre-configurato per monitorare tutte le porte UDP e TCP, oltre all’ICMP (Internet Control Message Protocol) e inoltre per simulare i servizi più comuni in una rete Windows.
Il monitoraggio inizia già dopo l’installazione e può essere facilmente personalizzato allo scopo di aggiungere in un secondo momento servizi specifici.
L’immagine seguente propone una schermata ottenibile durante il monitoraggio del traffico di rete.
KFSensor interagisce con l’attaccante per ingannarlo e fargli credere che sia il target del suo attacco; attraverso un comportamento simile a quello di un servizo reale, il tool riesce a rivelare la natura dell’attacco, mantenendo però il controllo totale (se ben configurato) ed evitando il rischio di essere compromesso o corrotto dall’attacco stesso.
In pratica, quando viene sollecitato alla risposta da un attaccante, l’honeypot risponde con un banner, ovvero simula un certo servizio: in caso di scansione di una rete da parte di un attaccante, questa è mirata a ottenere il banner per cominciare ad acquisire informazioni sul servizio. Pensiamo ad esempio a un Web Server, che in caso di cattura di un banner ritorna la versione in uso.
Quando viene portato un attacco a un servizio, KFSensor rileva e risponde alla scansione delle porte e rifiuta gli attacchi DOS, oltre ad auto-proteggersi dal sovraccarico.
L’immagine seguente propone l’interazione con un servizio simulato, che nel caso specifico è Telnet.
Nello specifico, la simulazione avviene con un comportamento che rispecchia in tutto quello del servizio reale e vero, in modo che l’attaccante non sospetti che si tratta di qualcosa di fittizio creato per aggirarlo (una sorta di “controspionaggio”) ma del servizio reale, quello di produzione.
Trattandosi di un tool nato per identificare gli attacchi sulla rete, KFSensor prevede l’invio di una serie di notifiche di alert via e-mail e tramite integrazione con un sistema SEIM.
La console amministrativa di KFSensor permette di filtrare ed esaminare nel dettaglio gli eventi verificatisi, consentendo un’analisi globale di ciascun attacco rilevato. Rende inoltre disponibile un dump di pacchetti completo per ulteriori analisi che possono essere compiute mediante l’utilizzo di tool specifici come Wireshark, cui sono stati dedicati un tutorial e un video su questo stesso portale.
Qui di seguito è proposta l’immagine di una schermata della console che riporta gli eventi rilevati.
Altra interessante funzionalità di KFSensor è la possibilità di eseguire, grazie a un modulo dedicato, analisi e statistiche riguardanti gli attacchi rilevati.
Il modulo KFSensor Reports fornisce una gamma di report e grafici che permettono di analizzare molti differenti aspetti degli attacchi rivolti verso un’organizzazione.
I report sono particolarmente utili nell’evidenziare i pattern degli attacchi che possono essere identificati soltanto nel tempo.
Tutti i report possono essere filtrati e quindi proposti per periodo temporale, tipo di attacco e localizzazione dell’attaccante, permettendo così di effettuare studi dettagliati delle analisi di determinate minacce.
Un esempio di grafico reportistico riportante la frequenza degli attacchi ragguagliati all’arco temporale è proposto nell’immagine seguente.
Passiamo adesso alla parte pratica e vediamo qualche esempio di utilizzo del tool, supponendo di avere già allestito un ambiente di test ed aver scaricato ed installato il software dal sito di riferimento. Per l’esercitazione ci occorrerà installare, dopo KFSensor, la libreria Network Packet Capture Library, che servirà per acquisire il traffico di rete; si scarica da www.keyfocus.net rammentando che delle due versioni offerte, la WinPcap 4.1.3 è quella idonea a chi ha vecchie versioni di Windows e la npcap (si scarica da www.npcap.org o https://nmap.org/npcap/) è invece quella ottimale per Windows 10 e Windows Server 2016. Se nel computer da usare come honeypot è già installato Wireshark, trattandosi della stessa libreria usata da quest’ultimo per la cattura del traffico non servirà installarla nuovamente.
Una volta completata l’installazione di tutti i pacchetti, si può lanciare KFSensor, la cui interfaccia utente apparirà come nell’immagine seguente, dove è proposta quella della versione Professional.
Per prima cosa la relativa finestra di dialogo proporrà di effettuare, tramite Wizard, la configurazione iniziale: si avvia cliccando su Next (gli altri due pulsanti permettono di aprire il relativo help o di vedere, in Getting Started, una breve guida per iniziare) allorché si passa alla prima finestra, proposta dall’immagine seguente, dove sono riepilogate le porte aperte al momento sulla macchina.
L’immagine mostra una situazione specifica che chiaramente differirà da un computer all’altro. Qui occorre scegliere se lasciare attive le porte native, cosa sensata se si intende analizzare il traffico di rete, oppure disabilitarle tutte (rimuovendo la spunta) se si intende utilizzare la macchina solo come honeypot, allorché tutte le porte vanno disabilitate per fare in modo che KFSensor simuli i servizi e sia esso ad essere accessibile tramite la porta selezionata.
Fatto ciò si clicca su Next e si passa alla finestra di dialono dove specificare l’indirizzo di posta elettronica (Send to) cui inviare le e-mail di alert e la casella di posta da cui verranno inviate (Send from); introdotti questi dati nelle rispettive caselle si clicca su Next e si termina la configurazione iniziale.
Adesso si torna all’interfaccia utente, che descriviamo qui di seguito partendo dalla visualizzazione estesa proposta nell’immagine seguente.
Nella barra dei pulsanti sottostante quella dei menu troviamo tre icone a forma di computer: quella bianca (più a sinistra) avvia il server honeypot e quindi la simulazione del computer in rete che farà da esca, la centrale (è blu a server fermo e si accende di rosso a server avviato) che arresta il server quando è avviato e la gialla (a destra) che riavvia il server dopo che è stato arrestato.
In questa barra si trova anche il pulsante a forma di altoparlante, cliccando sul quale si visualizza una finestra di interfaccia utente come quella proposta nell’immagine seguente, vale a dire con la struttura ad albero relativa ai protocolli.
Salendo nella struttura posta nella zona a sinistra della schermata appare la suddivisione del traffico in base al protocollo esposta nella relativa tree. Cliccando su una delle cartelle, la struttura viene espansa e appaiono tutte le porte con accanto il nome dei relativi servizi che verranno simulati dall’honeypot in base alle impostazioni effettuate e che abbiamo deciso di utilizzare e simulare. Nell’immagine seguente abbiamo espanso la cartella del protocollo TCP, am avremmo potuto fare lo stesso con l’UDP, l’ICMP e via di seguito.
Di fatto, nel caso del nostro esempio si tratta sia di servizi che effettivamente abbiamo disattivato (appaiono in blu barrati e con la dicitura Native service) si di quelli che dal lato attaccante risulteranno effettivi in quanto simulati dall’honeypot; quest’ultimo li simulerà facendo, ad esempio, apparire il banner quando gli viene richiesta una risposta, se il servizio lo prevede, ovvero informazioni utili all’attaccante per comprendere che tipo di servizio è affacciato alla porta interrogata.
Peraltro è possibile mascherare alcuni servizi simulati, ossia fare in modo che non appaiano ma siano visibili solamente all’arrivo di una sollecitazione da parte dell’attaccante; questo permette di risparmiare spazio nell’interfaccia utente in modo da facilitare la visualizzazione degli eventi soprattutto quando nella simulazione ci sono molti servizi e quindi è difficile riuscire a visualizzarli tutti insieme.
Cliccando sul pulsante con l’omino rosso, invece, apriamo la schermata proposta nell’immagine seguente, dove vengono visualizzati i “visitatori” della rete e quindi gli attaccanti che hanno tentato l’accesso alla rete stessa, con utili informazioni come l’indirizzo IP di provenienza dell’attacco.
Nell’immagine precedente vediamo l’IP dell’attaccante, che è simulato all’interno di una rete ed è quindi privato, ma in un esempio reale si vedranno altri IP e le relative informazioni.
Una funzione interessante di KFSensor è quella sccessibile dal comando di menu Signatures>Edit Signatures dal quale si accede alla relativa finestra di dialogo che permette di modificare le signature delle risposte, vale a dire i banner generati dall’honeypot per ciascun servizio simulato quando viene sollecitato da un attaccante esterno.
L’immagine seguente propone la finestra di dialogo nella quale sono riportate le signature del sistema utilizzato per il test
Per modificare una signature bisogna cliccare su di essa e poi sul pulsante Edit… quindi andare a scrivere quella desiderata. Con i pulsanti Add… e Delete si possono aggiungere o cancellare delle signature esistenti.
Passiamo ora a spiegare cosa sono e in che modo si utilizzano gli scenari, che sono un concetto fondamentale di KFSensor: sostanzialmente si tratta della configurazione o situazione della macchina che l’honeypot va a simulare, ovvero i servizi che decidiamo di esporre esternamente. Avere più scenari già pronti permette di attivare di volta in volta quello che ci servwe per un determinato contesto, senza dover cambiare o riconfigurare macchine fisiche o virtuali.
Una delle funzionalità più interessanti di questo prodotto è che possiamo creare tanti scenari in base a cosa vogliamo simulare, quindi se intendiamo simulare una macchina Linux andremo ad attivare e simulare solo i servizi che comunemente si trovano all’interno delle macchine Linux, mentre se vogliamo simulare dei sistemi Windows e possiamo decidere se simulare una Workstation o un server e quindi simulare i servizi correlati.
Nell’immagine seguente abbiamo un esempio di scenario predefinito (ed è anche l’unico creato nell’esempio corrispondente) che è chiamato Main Scenario. Volendolo modificare (e questo vale per qualsiasi scenario esistente che abbiamo creato) si apre il menu Scenario e si impartisce il comando Edit Scenarios... allorché si apre la relativa finestra di dialogo.
In questa finestra (New Scenario, immagine seguente) vengono mostrati tutti gli scenari esistenti e si possono compiere molte operazioni; ad esempio possiamo fare è modificare (cliccando sul tasto Edit) oppure cancellare (cliccando su Delete), copiare (Copy) o esportare (Export) uno scenario dopo averlo selezionato cliccando sul suo nome fino a farlo apparire a sfondo blu.
Oppure, cliccando sul tasto Add... si va ad aggiungere un nuovo scenario; in questo caso si apre la finestra di dialogo mostrata nell’immagine seguente, dove innanzitutto dobbiamo fare clic sul pulsante Add… e accedere così a un’ulteriore finestra di dialogo (quella alta e stretta in sovraimpressione) dalla quale dare un nome allo scenario e poi specificare la classe, ovvero la tipologia e il contesto che vogliamo simulare: applicazioni Windows, workstation, server o macchine Linux, Trojan e Worm ecc.
La classe si sceglie dal menu a tendina accessibile cliccando sulla casella Class. Definito questo, si clicca su Protocol per andare a definire i protocolli, ossia se vogliamo utilizzare il protocollo TCP o l’UDP; poi nelle rispettive caselle dobbiamo specificare la porta e l’indirizzo di binding, ovvero su quale indirizzo IP si deve mettere in ascolto quel determinato servizio che stiamo andando a simulare. Per semplicità possiamo impostare la voce di menu All, invece che scrivere un indirizzo IP specifico.
Sotto la casella Bind Address troviamo i due flag per decidere se attivare il servizio (ponendo la spunta su Active) e se visualizzarlo sempre o solo in caso venga stimolato da un attaccante esterno (in questo caso occorre spuntare Hide if no events). Quest’ultima opzione rientra nel discorso fatto sulla semplificazione dell’interfaccia utente allo scopo di limitare i servizi mostrati quando sono troppi.
Poi possiamo specificare l'azione che deve essere fatta sul banner, ovvero se vogliamo che a seguito della sollecitazione il servizio mostri un banner (per esempio Native), se il banner debba fornire informazioni specifiche o se non vogliamo che il servizio visualizzi il banner (opzione Close).
Completate le impostazioni si torna alla finestra di dialogo New Scenario dalla quale sono accessibili altre funzioni, una delle quali è quella che permette di definire direttamente un’intera classe: allo scopo bisogna cliccare sul pulsante Add/Remove classes (immagine seguente).
Si apre così una piccola finestra di dialogo che sostanzialmente contiene le classi elencate dal menu a tendina visto nella finestra di dialogo Add listen, con la differenza che possiamo porre il segno di spunta e quindi selezionarne più di una. Fatte le selezioni, quando clicchiamo su OK appaiono, nella finestra di dialogo New Scenario, immediatamente tutti i servizi che solitamente si possono trovare nella classe selezionata; nel caso dell’immagine seguente, in un sistema Linux.
Così abbiamo già una configurazione predefinita che semplifica un po’ il lavoro. Scegliamo quindi un nome (se non lo abbiamo fatto) e scriviamolo nella casella Name e se del caso, andiamo a effettuare altre modifiche prima di confermare questo scenario: per esempio togliere dei servizi perché magari ce ne sono troppi, modificarne alcuni dopo avervi cliccato su e cliccando su Edit… (immagine seguente).
Una volta definito quali servizi vogliamo visualizzare e utilizzare cliccheremo su OK e lo scenario sarà creato: lo vedremo nella solita finestra di dialogo Edit Scenarios, che riporterà questa volta lo scenario appena creato (immagine seguente).
Quando nel sistema sono presenti più scenari, bisogna impostare quello predefinito, ossia il principale, che poi è quello che diverrà operativo; allo scopo occorre andare nell’interfaccia utente e impartire il comando Switch Scenario del menu Scenario. Si apre così la finestra di dialogo dove cliccare sullo scenario desiderato e confermare con OK, allorché l’interfaccia utente andrà a mostrare i servizi correlati: nel caso dell’immagine seguent,e vediamo uno scenario da macchina Linux con alcuni sei servizi non mostrati perché è stata selezionata l’opzione hyde in non events, perciò appariranno solamente quando sollecitati da un attaccante.
Vediamo ora cosa accade in questo scenario di test, simulando un attacco, che nello specifico è una scansione della rete effettuata con Nmap ((https://nmap.org/) attraverso l’interfaccia utente Zenmap.
L’esempio proposto qui di seguito è riferito a una simulazione di attacco effettuato da una macchina Linux inserita nello stesso ramo di rete di quella contenente l’honeypot: la prima avrà indirizzo IP 192.168.163.4 e la macchina Windows su cui gira l’honeypot avrà il 192.168.163.3.
Una cosa importante ai fini del test è disabilitare il firewall Windows, che altrimenti ostacolerebbe la comunicazione.
Dall’interfaccia utente di Nmap (Zenmap) possiamo scegliere di effettuare la scansione intensa (Intense Scan) e andiamo a impostare l’indirizzo IP della macchina target (l’honeypot) e il comando relativo alla richiesta di scansione. Nell’immagine seguente vediamo Zenmap con le impostazioni dell’IP address 192.168.163.3 (casella Target) corrispondenti alla macchina dove è installato l’honeypot e il comando (casella Command) impartito, che è nmap -T4 - A- v192.168.163.3. Tale comando indica di eseguire l’attacco con Nmap all’indirizzo IP specificato.
Cliccando su Scan si avvia la scansione, come mostra l’immagine seguente).
Come si può osservare, iniziano ad essere elencate le porte aperte (la scansione intensa va proprio alla ricerca dei punti di accesso alla macchina sottoposta ad attacco) sull’honeypot, perché è l’honeypot che sta simulando tutti questi servizi.
La situazione corrispondente trovata aprendo l’interfaccia utente di KFSensor, per lo scenario Linux, sarà quella mostrata nell’immagine seguente.
Nella parte sinistra dell’interfaccia utente iniziano a esserci dei servizi che sono diventati rossi proprio perché indicano che c'è stata una recente attività (tra l'altro accanto ad essi appare scritto Recent Activity) ad indicare che lato attaccante c’è qualcuno che ha effettuato un’attività corrispondente a delle sollecitazioni su questi servizi.
Se vogliamo approfondire, dobbiamo andare su ognuno di questi servizi e si potrà vedere di che tipo di attività si tratta; per l’esattezza, cliccando su uno di essi vedremo, nella parte destra dello schermo, l’attività rilevata, vale a dire la sollecitazione effettuata dall’attaccante nei confronti del servizio (immagine seguente).
Adesso si può vedere, per ultimo, cosa accade facendo una piccola modifica a una porta dello scenario, per verificare se l’attaccante effettivamente riesce a rilevarla. In questo esempio lavoriamo sulla porta 3000, che è stata rilevata. Andiamo quindi a editare lo scenario corrispondente, cerchiamo la porta 3000, clicchiamo su di essa evidenziandola e poi con un clic sul pulsante Delete
la cancelliamo.
Andiamo su Zenmap e clicchiamo nuovamente il pulsante Scan per riavviare la scansione, tra i cui risultati, questa volta, non dovremmo vedere più la porta 3000. Se è così, significa che l’honeypot sta effettivamente funzionando, nel senso che l’attaccante effettivamente lo vede come una macchina vera.
Chiaramente quello mostrato è un semplice esempio applicativo, riguardante una certa configurazione o scenario, ma si applica a tuti gli scenari previsti dall’honeypot. Potete anche provare, se l’infrastruttura a vostra disposizione lo consente, ad apportare attacchi dall’esterno della rete o da un altro ramo di rete, diverso da quello dove è collocata la macchina in cui è installato l’honeypot.
