Honeynet: rilevare la presenza di un honeywall
Nelle honeynet la presenza di un honeywall è indispensabile per svolgere un’azione di contenimento degli attacchi che possono sfruttare il sistema compromesso come testa di ponte e allo stesso tempo per acquisire maggiori informazioni in maniera trasparente. L’adozione di particolari misure di sicurezza può rivelarsi un’arma a doppio taglio in grado di facilitare il lavoro di riconoscimento di un sistema trappola da parte di un aggressore particolarmente preparato.
Restrizione del traffico in uscita
Questa strategia orientata ad evitare il rischio di attacco di ulteriori sistemi a partire da un honeypot compromesso può essere facilmente rilevata attivando un elevato numero di connessioni in uscita e osservando la presenza di una qualche limitazione.
Invio pacchetti e Snort_inline
La sua presenza può essere facilmente rilevata costruendo dei pacchetti ad hoc contenenti un payload dannoso che sicuramente comporterebbe la loro eliminazione da parte di Snort_inline. Inviando pacchetti “maliziosi” verso un sistema target di cui si ha il controllo è possibile stabilire se tali pacchetti sono stati alterati in qualche modo o addirittura scartati.
Identificazione e disabilitazione di Sebek
Abbiamo già visto in un altro articolo che Sebek è un’applicazione di tipo client/server utilizzata come strumento fondamentale per la cattura di informazioni sulle attività intrusive all’interno di un honeypot. Basato sulla tecnologia dei rootkit (ovvero un insieme di strumenti in grado di conservare i privilegi acquisiti in una precedente intrusione nascondendo file, processi e creando delle backdoor di accesso al sistema che l’aggressore è in grado di sfruttare senza essere scoperto) permette l’acquisizione dei dati a cui si ha accesso tramite la primitiva read(). Sebek opera nello spazio riservato al kernel per cui è in grado di accedere alla maggior parte delle comunicazioni in maniera non criptata. In questo modo può acquisire le sessioni SSH (Secure Shell), recuperare i file copiati attraverso SCP (Secure Copy) e registrare le password impiegate dagli intrusi. Questi dati vengono inviati attraverso il protocollo UDP verso il server di raccolta che ne costituisce l’altra componente. La trasmissione avviene modificando il kernel in modo da nascondere tali pacchetti in uscita, per evitare che l’aggressore si accorga del flusso dati. In più vengono opportunamente alterati i contatori e le strutture utilizzate nella comunicazione in modo da renderla estremamente difficile da individuare. Resta comunque possibile rilevare la presenza di Sebek riferendosi al livello di rete; poiché Sebek registra qualunque attività correlata alla primitiva read() e invia i dati attraverso la rete si evidenzia un notevole incremento del traffico in uscita. Si può procedere generando migliaia di chiamate alla read() per creare un effettivo congestionamento della rete e utilizzare un banalissimo comando ping per osservare il valore medio di RTT. Vari studi al riguardo hanno evidenziato mediamente un incremento da 0.7 ms a 4800 ms.
Una possibilità concreta di disabilitazione consiste nell’effettuare il rebooting del sistema, visto che Sebek non può essere caricato automaticamente allo startup, a meno che non si proceda ad una personalizzazione degli script di shell, lasciando in questo modo una traccia evidente della sua presenza e facilitando la vita all’aggressore. Il metodo più utilizzato per mettere fuori gioco Sebek consiste nell’evitare l’uso della primitiva read(), sostituendola con la funzione mmap() che mappa i file direttamente in memoria, aggirando di fatto le attività di logging, sebbene non tutti i file, come i device file o quelli contenuti nella directory /proc, possano essere gestiti in questo modo. Infine è stata proposta una soluzione più elegante che rappresenta una sorta di suicidio di Sebek. Infatti riuscendo ad ottenere l’indirizzo della funzione cleanup() si può ripristinare lo stato iniziale della tabella delle system call disabilitando ogni attività di logging.
