VMWare e il promiscuous mode

Non si finisce mai di imparare…
E quando si impararano cose che fanno male, ti restano più impresse nella mente!

Ecco una caratteristica (per non dire una falla di sicurezza) di VMWare che non conoscevo e che mi ha creato non pochi problemi in quello che doveva essere il mio periodo di riposo ferragostiano.

Innanzi tutto, cos’è il promiscuosus mode? Si tratta di una modalità di configurazione delle schede di rete che permette di accettare tutto il traffico in ingresso, compreso quello che il sistema operativo normalmente ignorerebbe. E’ una configurazione che si utilizza in casi un po’ particolari ma nemmeno troppo remoti: ad esempio la configurazione di un bridge tra due interfacce le pone automaticamente in promiscuous mode; ma anche l’utilizzo di software di analisi del traffico di rete (ad esempio tcpdump oppure snort) abilitano il promiscuous mode… ma poco male perchè normalmente a monte di una interfaccia di rete abbiamo uno switch che associa automaticamente gli ARP con le schede di rete per cui al server con la scheda in promuscuous mode arriva comunque solo il traffico a lei indirizzato e la sudetta modalità servirà quindi solo a gestire quei pacchetti “spuri” che verrebbero normalmente scartati.
La caratteristica di VMWare che mi ha fatto penare è proprio quella di “sentire” se una interfaccia di rete di una VM è settata in modalità promiscua e, in questo caso, agisce configurando automaticamente lo switch virtuale in modalità hub… per cui a quella macchina arriveranno tutti i pacchetti che cirolano su quella rete fisica (virtuale) a cui è collegata l’interfaccia configurata in modalità promiscua.
Personalmente ritengo che questa sia una falla di sicurezza di VMWare proprio perchè non è sempre detto che le VM siano gestite da persone serie è può capitare che il gestore poco serio di una VM abbia posto volutamente la scheda di rete in modalità promiscua per scopi non corretti (ad esempio leggere le password in chiaro che passano in rete).
Sebbene quello che è successo a me non abbia nulla a che fare con l’esempio qui sopra (per fortuna), tecnicamente la cosa che mi è capitata è ancora più grave: difatti volevo configurare una VM in modo che agisse da IPS con snort_inline configurando le due schede di rete in modalità bridge; in questo caso abbiamo due schede di rete collegate a due switch virtuali e, a causa del promiscuous mode settato su entrambe le schede, si avrà in pratica un’unica grande rete con due hub collegati da un bridge. Ovviamente questa configurazione ha creato subito blocchi e disservizi tali che sarebbe stato impossibile non accorgersi del problema (provate a fare un ponte tra due porte di un hub…), però capirne qual è la causa non è stato per niente facile.

Se qualcuno dei lettori conosce il modo per disabilitare questa feature di VMWare ESXi 3.5 oppure sa se le nuove versioni (4.0 e 4.1) non la implementano… batta un colpo!

Attivazione del Web Application Firewall

In questi giorni abbiamo attivato il Web Application Firewall, un sistema di protezione specifico per i nostri server web che si aggiunge ai già presenti contolli di filtraggio porte e di intrusion prevention.
Il web application firewall è un sistema di intrusion prevention evoluto che permette di bloccare attacchi che sfruttano comuni leggerezze a livello applicativo: pertanto siti web affetti da errori di programmazione che permetterebbero attacchi come SQL Injection oppure Cross Site Scripting saranno resi invulnerabili grazie a questo nuovo controllo a livello perimetrale.
Inoltre, da oggi, tutto il traffico da e verso i nostri web server viene controllato attraverso l’antivirus.

Una sicurezza in più per tutti i nostri clienti!

Udev e il MAC address delle interfaccie di rete

In linux molto spesso viene utilizzato un demone chiamato udev in grado di rilevare la configurazione hardware del computer e creare dinamicamente i device nella directory /dev.

E’ un demone molto utile e comodo per cui viene installato di default in quasi tutte le distribuzioni Linux.

Tra le peculiarità di udev c’è quella di mantenere una serie di regole persistenti per quanto riguarda storage ed interfacce di rete: riguardo a queste, il device (/dev/ethX) viene associato in maniera persistente al MAC Address della scheda di rete, questo per far si che la configurazione di ethX rimanga sempre associata ad una determinata scheda di rete fisica.

Nella maggior parte di situazioni questo è comodo ed utile, ma ce ne sono altre in cui si ha la necessità di variare questa impostazione.

Ammettiamo di aver creato una VM in VMWare o KVM le cui schede di rete hanno il Mac Address assegnato automaticamente e che si effettui un clone della VM (non un live migration) su un altro server fisico: in questo caso, all’accensione, non si avrà più la rete configurata in quanto le schede di rete precedentemente impostate spariranno e appariranno nuovi device (con il numero identificativo immediatamente successivo a quelle precedentemente configurate) senza configurazione.

Come fare per tornare alla configurazione precedente e funzionante?

La maggior parte delle distribuzioni salva un file all’interno della directory /etc/udev.d/rules.d chiamto XX-persistent-net-rules.conf: è sufficiente cancellare questo file e riavviare il sistema. I device delle nuove schede di rete verranno ricreati usando la precedente configurazione e tutto dovrebbe ripartire regolarmente.

Ieri mi sono trovato però in una situazione analoga con Vyatta, un appliance basato su linux ottimizzato per fungere da router e firewall: in questo caso la directory /etc/udev.d/rules.d/ rimane vuota e bisogna trovare un altro metodo.

Innanzi tutto rimuoviamo lo script vyatta_net_name:

sudo su

cd /lib/udev/
mv ./vyatta_net_name ./vyatta_net_name_backup

Quindi, cosa più importante, aggiungiamo la reguente riga al file /lib/udev/rules.d/75-persistent-net-generator.rules

<strong>/lib/udev/rules.d/75-persistent-net-generator.rules</strong>
...
ENV{MATCHADDR}==”0*”, ENV{MATCHADDR}=”"

per far si che la configurazione delle schede di rete non venga considerata persistente.

Configurazione di un server OpenVPN su Debian Squeeze

OpenVPN è il sistema più semplice per gestire VPN in ambiente Linux. In questo Howto vediamo come configurare un concentratore OpenVPN utilizzando Debian Squeeze. Fortunatamente l’installazione è piuttosto semplice.

Installazione del server
Innanzi tutto installiamo i pacchetti necessari:

apt-get install openvpn udev

OpenVPN mette a disposizione un tool chiamato EasyRSA per creare i certificati per il collegamento. Installiamo il tool e generiamo i certificati per la Certification Authority interna:

cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn
cd /etc/openvpn/easy-rsa/2.0/
. /etc/openvpn/easy-rsa/2.0/vars
. /etc/openvpn/easy-rsa/2.0/clean-all
. /etc/openvpn/easy-rsa/2.0/build-ca

Quindi generiamo i certificati per il server:

. /etc/openvpn/easy-rsa/2.0/build-key-server server

e per il client:

. /etc/openvpn/easy-rsa/2.0/build-key client1

Inifine generiamo i parametri Diffie Hellman; questa operazione può essere parecchio lunga…

. /etc/openvpn/easy-rsa/2.0/build-dh

A questo punto copiamo i certificati server nella directory corretta:

cd /etc/openvpn/easy-rsa/2.0/keys
cp ca.crt ca.key dh1024.pem server.crt server.key /etc/openvpn

e copiamo sul client i certificati client. I file da copiare sono:

  • ca.crt

  • client1.crt

  • client1.key

Ora copiamo la configurazione del server OpenVPN:

cd /usr/share/doc/openvpn/examples/sample-config-files
gunzip -d server.conf.gz
cp server.conf /etc/openvpn/
/etc/init.d/openvpn start

Attraverso questa configurazione, il server negozierà con il client l’ip del tunnel e creerà l’interfaccia. Se il nostro scopo è quello di creare una connessione punto-punto tra un client ed un server, siamo perfettamente operativi; più avanti vedremo come utilizzare il nostro server OpenVPN per rendere accessibile al client tutta la rete interna.

Configurazione del client OpenVPN
Ovviamente esistono numerosi clien OpenVPN a seconda del sistema operativo che utilizzate. Se usate Linux con l’interfaccia GNOME, l’applet della rete nel quale potete configurare le VPN PPTP può essere utilizzato anche per comandare le VPN OpenVPN: vi serviranno i tre file segnalati prima e, attenzione, nel pannello “Avanzate” ailitate la compressione LZO.
Per MacOS esiste il client Tunnleblick
Per Windows, invece, esiste il client OpenVPN GUI.

Configurazione dell’ip forwarding, del nat e del DNS forwarding
Nel caso in cui vogliate che i vostri client abbiano accesso sia alla rete locale del server, ma anche alla rete Internet attraverso il server, è necessario fare qualche altra configurazione.
Innanzi tutto bisogna abilitare sul server l’IP forwarding ed il nat:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Per rendere definitive queste modifiche, consiglio di aggiungere le righe qui sopra anche al file /etc/rc.local in modo che siano eseguite ad ogni riavvio del server.
Attraverso il tunnel OpenVPN saremo in grado di raggiungere qualsiasi rete collegata al server, però non è possibile utilizzare DNS esterni, per cui sarà necessario configurare un DNS sul server.
Il metodo più semplice è quello di installare il pacchetto dnsmasq che funge da proxy DNS tra il tunnel OpenVPN e i resolver impostati sul server:

apt-get install dnsmasq

Quindi modifichiamo il file /etc/openvpn/server.conf per far istruire i client che si collegano riguardo le rotte e il DNS:

<strong>/etc/openvpn/server.conf</strong>
....
push "dhcp-option DNS 10.8.0.1"
push "redirect-gateway def1"

e riavviamo OpenVPN

/etc/init.d/openvpn restart