Configurazione di una VM sicura e protezione della rete host

Stai prendendo l'approccio sbagliato qui. Lo scopo (il vero scopo iniziale) di un honeypot come definito da Lance Spitzner era intrappolare qualcuno all'interno di un sistema che sembrava riempito di abbastanza chicche che l'attaccante avrebbe perso tempo lì, dando agli amministratori abbastanza tempo per evitare che facessero danni altrove, mentre li studiava. La prima versione open source che ricordo era Deception Toolkit (DTK). Detto questo, un honeypot non è mai stato pensato per essere su una rete isolata.

Isolare la tua rete probabilmente renderà la tua honeypot poco attraente. Allo stesso modo, eseguirlo su una rete aziendale è pericoloso. Molti aggressori hanno metodi per scoprire cosa è e cosa non è un honeypot. Pertanto, gli honeypot spesso catturano attacchi opportunistici di basso livello. Quindi, sii consigliato, eseguire un honeypot su una rete aziendale attiva è una cattiva idea per un hobbista. Quindi sulla tua domanda e alcuni suggerimenti.

Isolare la tua VM - A seconda dell'host e del tuo ospite, vorrai ridurre al minimo la visibilità delle applicazioni di virtualizzazione. Ad esempio, la scheda di rete (vmnet0 è un dead give away), applet, ecc. Creazione di regole FW simmetriche che bloccano la rete e dalla rete. Tuttavia, questo è un vialetto morto. Prossima mossa? Separare la VLAN isolata persino dalla visualizzazione della rete. Svantaggio? Se tu fossi un utente malintenzionato e vedessi una rete vuota senza connessioni, resteresti sul sistema se pensavi che si trattasse di un sistema aziendale?

Suggerimento - Scarica e modifica " NetInVM " e piazza il tuo host e NetInVM nella propria VLAN. Ora hai ancora PIÙ honeypot e una mini rete che genera traffico. Sei su una rete isolata in cui il tuo switch / router / firewall controlla le politiche del traffico per impedire la comunicazione da e verso il tuo honeypot. (inclusi ARP, BCAST, MCAST, ecc.) Ma sii consigliato ... Il tuo honeypot ha bisogno di connessioni dal mondo. Se un utente malintenzionato si connette, anche lui / lei può connettersi DA. Immagina quanto segue:

Attacker --> compromised your honeypot
Attacker --> makes outbound connection FROM your honeypot --> C&C server
Attacker --> analyzes the source of WHO connected to his honeypot
Attacker <-> (thinks) <-> "Odd says I am connecting from a Fortune 100 yet no traffic"
Attacker --> goes dark

Un honeypot deve essere credibile.

Ci sono molti modi per farlo. Pochi che vengono in mente sono la separazione fisica o il filtraggio logico dei pacchetti.

1. La VM può essere configurata per l'ascolto sulla propria interfaccia di rete fisica. Purché tu abbia un host multihomed; potresti avere una VM in ascolto su una particolare scheda di rete; e manderà anche quello. È possibile accedere alla VM solo tramite console o tramite RDP / SSH in tale indirizzo IP.

2. Proteggi il tuo computer host da quella VM usando un firewall. La tua VM ascolta una particolare interfaccia virtuale ( /dev/vmnetX ) che potresti impedire la perdita di pacchetti. Se si eliminano pacchetti provenienti da questa rete per accedere a qualsiasi indirizzo che non si desidera (la propria rete interna, ...), sarebbe difficile per un utente malintenzionato raggiungere la propria rete. Di nuovo, se il tuo set di regole è solido.

Ovviamente è previsto che sia difficile uscire dalla VM e accedere al sistema operativo host.