Hosting di server virtuali in DMZ con reverse proxy

Host only:
vmnet 1 -> 172.16.102.0/24
vmnet 5 -> 192.168.134.0/24
vmnet 6 -> 178.16.142.0/24
vmnet 7 -> 192.168.169.0/24

ed andiamo ad installare il sistema operativo nelle nostre VM. Per la gestione con l’application proxy è indifferente usare windows o linux nelle VM, ed usare come web server IIS o apache, tanto quello che l’application proxy cerca deve trovare e’ un demone o servizio in ascolto sulla porta 80. Configuriamo la VM e prima di iniziare l’installazione del web server andiamo a specificare nella scheda di rete virtuale di vmware un’impostazione “custom” dove gli indicheremo a mano su quale scheda di rete vmnet dovrà essere attestata. Nel mio test ho installato 2 VM con windows 2000 server con IIS, e li ho attestati sulle schede vmnet 1 e vmnet 5, semplicemente installandone uno e poi copiandolo, cambiando l’indirizzo ip relativo alla sua vmnet, non ho nemmeno cambiato nome al secondo VM, tanto le due VM non si vedono in nessun modo. A fine installazione vmware avrà dato alle VM degli indirizzi ip dinamici di sua scelta, andremo quindi a mettere un ip fisso che sia congruo con la vmnet relativa: alla macchina nella vmnet 1 possiamo dare 172.16.102.2
alla macchina nella vmnet 5 possiamo dare 192.168.134.2 Se non dobbiamo uscire dalla dmz con queste VM possiamo anche non mettere nell’impostazione del tcp/ip default gateway e dns, così rimarrano escluse dal resto della rete e del mondo (una sicurezza in più) Andiamo a configurare un sito www.primo.it nella rete vmnet 1 ed un sito www.secondo.it nella vmnet 5 e configuriamoli con tutto il necessario, poi, nella macchina HOST aggiungiamo e/o modifichiamo il file squid.conf con questi valori:

#Configuro Squid in modo che ascolti sulla porta 80 della macchina host di vmware
http_port IP-MACCHINA-HOST-SU-INTERNET:80 #Disabilito le query ICP da e verso altri proxy
icp_port 0 #I log creati potranno poi essere utilizzati per statistiche di accesso
emulate_httpd_log on #Consento le connessioni dall’esterno
http_access allow all #L’indirizzo del vero web server (ATTENZIONE: l’url non l’indirizzo ip)
httpd_accel_host www.primo.it #L’indirizzo del vero web server (ATTENZIONE: l’url non l’indirizzo ip)
httpd_accel_host www.secondo.it #La porta su cui ascolta il vero web server
httpd_accel_port 80 #Ottimizzo per proteggere più server web
httpd_accel_single_host off #Da settare ON se si vogliono anche le funzioni di caching
httpd_accel_with_proxy off #In caso in cui il server web utilizzi i VirtualHost
httpd_accel_uses_host_header on

A questo punto, per sicurezza, accertiamoci che nessuno possa raggiungere i server web senza passare dal proxy disabilitanto l’ip forwarding nella macchina HOST con un banale

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

e blocchiamo il forward con netfilter

iptables -P FORWARD DROP

Adesso andiamo a dire alla macchina HOST dove stanno i siti virtuali, se sono molti possiamo anche montare un server dns direttamente sulla macchina HOST, altrimenti mettiamo nel file /etc/hosts della macchina HOST la corrispondenza tra url ed ip delle macchine virtuali: 172.16.102.2 www.primo.it
192.168.134.2 www.secondo.it A questo punto abbiamo ottenuto che: – i server sulle VM non si vedono tra di loro
– i server sulle VM non sono raggiungibili dall’esterno senza passare da squid
– i server sulle VM non possono accedere all’esterno nessun caso In più possiamo specificare delle access list su squid per poter bloccare taluni comportamenti come il famoso baco di IIS che permetteva di eseguire cmd.exe dentro un’url del browser semplicemente creando una regola che non permetta di accedere ai server se trova la stringa “cmd.exe” nell’url cosi:

acl iis_nocmd urlpath_regex -i cmd.exe
http_access deny iis_nocmd

questo è solo un esempio, ma si possono cercare di bloccare anche gli attacchi tipo sql injection, cosa che il solo netfilter non riesce a fare perché lavora ad un livello più basso del tcp. C’è da notare inoltre che, essendo la macchina host esposta direttamente in internet è OBBLIGATORIO proteggerla con qualche furba regola di netfilter. Questa gestione ha un altro vantaggio: possiamo registrare su un solo indirizzo ip tutti i domini che vogliamo, sia ospitati da macchine windows che linux, tanto ci penserà squid a dirottare gli url in base al dominio di destinazione nell’url. Ovviamente se i nostri siti sono statici finisce qui, se invece si deve accedere ad un database possiamo montarlo direttamente sul web server oppure dovremo configurare la rete della macchina virtuale e le relative regole di netfilter perché possa arrivare al database posto dove meglio ci piace. Tutto questo lavoro può essere semplificato aumentando il numero delle macchine: non usando delle VM per i web server possiamo usare dei server web veri con degli indirizzi ip veri e delle dmz vere, ma il firewall con squid come application proxy sarà configurato nella stessa identica maniera, dovremo solo da lavorare un po’ di più con netfilter ma avremo bisogno di una macchina molto ma molto meno potente.
Per ogni cosa mi potete trovare all’indirizzo raniero.net at gmail.com ]]>