Sicurezza server con VMware

LEGANERD 035015

VmWare e’ un software che fa’ una cosa semplice e spettacolare nello stesso tempo, permette di far girare un sistema operativo come se fosse un programma qualunque.

I signori che hanno studiato questa cosa, che funziona perfettamente da molti anni, hanno emulato il bios di un computer, un processore, una scheda di rete, un paio di controller, sia eide che scsi, un chip di controllo usb, una scheda audio e le porte seriali / parallele.

Tutto questo riunito in un software che emula una macchina virtuale (d’ora in avanti VM) capace di fare il boot di un sistema operativo da un cdrom o direttamente da un’immagine iso sul disco della macchina host (d’ora in avanti HM) ed installarsi su un filesystem contenuto in un file.

La macchina virtuale consumera’ parte delle risorse della macchina vera che la ospita e non necessariamente la macchina host dovra’ far girare una sola VM, anzi, per ambienti di produzione e test e’ auspicabile far girare piu’ VM per ogni HM, in modo da ottimizzare risorse e semplificare i backup.

Un’altra caratteristica delle VM e’ che una volta spento il sistema operativo sono dei banali files sul disco della macchina host, che possono essere copiati, salvati, ripristinati e spostati a piacimento, impacchettati, masterizzati, spediti e reinstallati su altre HM anche con hardware e sistema operativo diverso dall’originale, tanto il sistema contenuto nella VM non si accorge di
nulla: l’hardware virtuale e’ sempre lo stesso.

VmWare gira sia su linux che su windows, e fa’ girare come VM molti tipi di linux e varie versioni di windows, io ultimamente sto’ usando in modo massiccio la versione server (al momento la ver. 1.0.1) che e’ gratis, purtroppo non e’ software libero ma tant’e…

Ci sono altri software che fanno piu’ o meno quello che fa’ VmWare, anche gratis e liberi, tipo bochs, xen, virtualpc ed altri, ma nessuno ha le prestazioni e la duttilitia’ di VmWare, e poi l’anzianita’ del progetto lo rende veramente rock-solid.

Questo software ha molti pregi: lo possono usare gli sviluppatori che vogliono fare prove di installazione dei software su macchine “pulite” e non vogliono stare a installare continuamente il sistema operativo di test, chi fa’ uso intenso di server di sviluppo o di test di applicazioni prima di metterle in produzione puo’ usare macchine “precotte” da poter rovinare senza rischi, chi lo usa in produzione per semplificare i backup e ottimizzare l’hardware (in VmWare lo chiamano “consolidamento dei server”), i suoi drivers sempre uguali permettono di tenere una VM spenta sempre pronta da mettere online, installare dei cluster di server virtuali in una sola macchina vera per motivi di studio e test e’ banale, molta gente si certifica su windows server usando questi ambienti che richiederebbero costoso hardware per fare test reali, all’hardware virtuale possiamo assegnare un numero arbitrario di schede di rete, in modo da poter fare dei firewall con gestione di reti lan / internet / dmz / wireless per poter fare test di regole iptables prima di metterle in produzione.

Se proprio vogliamo trovare un difetto lo dobbiamo cercare nelle prestazioni: e’ ovvio che uno strato software fra il sistema operativo e l’hardware “vero” ovviamente rallentera’ un poco le operazioni, ma se avete un pc di ultima generazione potrete far girare i vostri sistemi senza problemi, tant’e’ che molte distribuzioni linux ormai inseriscono i driver di VmVware direttamente assieme ai driver hardware canonici.

Dopo questo breve preambolo vorrei fare un esempio, che a dire il vero esempio non e’ visto che una applicazione del genere gira e sta’ tutt’ora girando in rete nell’azienda dove lavoro.

[spoiler]

Vorrei mettere un pc linux su internet con 4 server web virtuali, due apache su linux debian e due IIS (Internet Information Server) 6 su windows 2003, tutti esposti su internet con lo stesso indirizzo ip pubblico, ogniuno con una propria DMZ, in modo che la compromissione di uno dei sei non permetta al cracker di turno di arrivare a nessuna delle altre 5 macchine.

Per aumentare la sicurezza metteremo anche un reverse proxy sulla macchina linux vera per poter filtrare gli url richiesti alle VM.

Nota per chi non sa’ cos’e’ un reverse proxy: partiamo da cos’e’ un proxy di una lan, praticamente un server a cui i browser gli utenti della lan stessa chiedono le pagine web che vogliono navigare, lui se le scarica al posto loro e le passa al browser dell’utente, un reverse proxy e’ fatto alla rovescia, e’ tutto il mondo che quando arriva a vedere le pagine sul mio sito www.primosito.it si mettera’ in contatto con il proxy sul firewall linux che passera’ la richiesta al server web virtuale il quale rispondera’ al proxy il quale rispondera’ all’utente esterno che chiedeva la pagina.

Voi direte: e’ una complicazione inutile, e invece no, perche’ il proxy non e’ messo li a consumare cicli di cpu, squid, cioe’ IL proxy server per antonomasia, ha la possibilita’ di gestire filtri sulle richieste che dall’esterno vanno verso il sito web virtuale ed eventualmente segare via richiesta strane, subdole, malformate o quant’altro.

Ovvio che chi installa il proxy deve sapere quel che fa’, onde evitare di segare via anche del traffico legittimo.

Avere un reverse proxy ci permette una cosa che altrimenti sarebbe impossibile: non avere il default gateway sul server virtuale, il proxy e il server infatti saranno nella stessa lan (virtuale), e quindi si parlano direttamente, percio’ se per qualche motivo un cracker riuscisse a bypassare squid ed ad inniettare una url malformato per far arrivare un file dall’esterno sul web server, tipo una backdoor, un virus o qualcosa del genere non potra’ perche’ il web server NON PUO’ uscire dalla sua lan ed andarsene a zonzo per internet a scaricare i cavoli suoi, ed inoltre il firewall / proxy blocchera’ ogni porta che non sia la 80 in uscita.

Per mettere in opera la nostra macchina attrezziamoci con una hardware con “buoni polmoni” un core duo 2.13 con 4 giga di ram e un disco sata2 da 250 giga (magari due in mirror) andra’ bene.

Installiamo linux, io uso preferibilmente debian stable per queste cose, eliminiamo servizi inutili, aggiorniamo il sistema operativo, installiamo squid con le impostazioni di default, accertiamoci che il kernel supporti il multiprocessore, facciamo un po’ di hardening del tcp/ip ed installiamo VmWare.

L’installazione di VmWare su linux e’ banale, serve il programma liberamente scaricabile previa registrazione dal sito VmWare, un codice di attivazione che viene rilasciato all’atto della registrazione, e gli header del kernel dellamachcina host necessari al setup di VmWare. Il resto del necesario, come compilatori e librerie, sono di serie su debian quando si fa’ un’installazione di default.

La macchina fisica puo’ avere una o piu’ schede di rete, questo dipende dall’uso che ne faremo, la mia ne ha due: una esposta su internet all’indirizzo ip (fasullo) 77.66.55.44/30 ed una nella lan della ditta all’indirizzo ip (privato) 10.10.10.1/24

I miei quattro domini devono essere correttamente registrati come domini di 3 livello, rispettivamente www.testuno.it, www.testdue.it, www.testtre.it, www.testquattro.it e tutti e quattro devono puntare all’indirizzo ip pubblico di cui sopra: 77.66.55.44.

Di solito e’ banale avere piu’ web server su un solo indirizzo ip, si chiama virtual hosting e si fa’ facilmente sia con apache che con iis di windows, pero’ non e’ possibile, senza reverse proxy, poter puntere a wenb server che girano su sistemi operativi diversi, nel nostro caso avremmo dovuto avere per lo meno 2 server, un linux per apache, un windows per iis.

Iniziamo il setup di VmWare.

Durante l’installazione ci verra’ chiesto dal programma se vogliamo delle reti “HOST ONLY”, dobbiamo dire di si e dobbiamo farne tante quante sono le noste macchine virtuali, quattro nel mio caso, possiamo farne anche di piu, tanto non costano e nulla e non appesantiscono il sistema. Ogniuna di queste reti virtuali potra’ ospitare piu’ server, di fatto fino a 252. In realta’ sarebbero 253, ma un indirizzo lo prende la scheda virtuale della macchina HM, ma non credo che esista ad oggi un pc acquistabile da tasche comuni che possa far girare contemporaneamente 253 VM.

Appuntiamo gli indirizzi delle 4 reti che abbiamo creato, gli indirizzi li fornisce VmVware da solo, andando a cercare reti libere nella nostra lan. Poniamo di avere avuto:

192.168.101.0/24
192.168.102.0/24
192.168.103.0/24
192.168.104.0/24

Segnamoceli ed andiamo ad installare la 4 macchine virtuali, nell’impostazione della VM dobbiamo ricordarci di impostare la rete come “custom” ed indichiamo su quale scheda di rete “vmnet” (cosi’ le chiama VmWare) dovra’ essere attestata la lan virtuale.

Per ogni lan virtuale avremo 2 indirizzi ip occupati,quello nella HM, nel ns caso 192.168.10x.1 e 192.168.10x.2 che e’ quello del server viruale.

Ricordiamo che nella macchina vituale il default gateway NON deve essere impostato, non serve.

A questo punto, una volta che le 4 macchine virtuali sono up & running andiamo a sistemare squid.

Rispetto alla configurazione di serie di debian per funzionare si devo solo fare queste piccole modifiche:

# Metto il proxy in ascolto sull’indiirzzo ip pubblico, sulla porta 80
http_port 77.66.55.44:80

# Non permetto query ICP da e verso altri proxy
icp_port 0

# Tengo i log perche non tenerli e’ MALE e soprattuto e’ MALE non andarli mai a vedere
emulate_httpd_log on

# Permetto (ovviamente) le connessioni da fuori
http_access allow all

# Qui indico i veri indirizzi web, NOTA: si deve mettere l’url, e MAI l’indirizzo
# ip, altrimenti il reverse proxyng non funziona

httpd_accel_host www.testuno.it
httpd_accel_host www.testdue.it
httpd_accel_host www.testtre.it
httpd_accel_host www.testquattro.it

# Indico dov’e’ in ascolto vero web server
httpd_accel_port 80

#Questo ottimizza il fatto di avere più server web
httpd_accel_single_host off

# Non fare caching delle pagine, non m’importa visto che non ci guadagno in
# performance e potrei avere pagine dinamiche e quindi la cache e’ comunque inutile
httpd_accel_with_proxy off

# Setto ON solo nel caso in cui il server web utilizzi a sua volta i VirtualHost
httpd_accel_uses_host_header off

Adesso accertiamoci che l’ip forwarding sia disabilitato:

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

e blocchiamo il forward con netfilter

iptables -P FORWARD DROP

Altre regole di firewalling andranno ovviamente aggiunte, a protezione della macchina esposta su internet, ma questo e’ un argomento che non e’ di questo paper.

Alla macchina host HM dobbiamo dire a che indirizzo stanno i web server, se fossero molti, compreso quelli in VirtualHost, potremmo montare nel server linux host un server dns ed usare quello, ma con poche macchine come nel nostro caso bastera’ modificare a mano il file hosts cosi:

192.168.101.2 www.testuno.it
192.168.102.2 www.testdue.it
192.168.103.2 www.testtre.it
192.168.104.2 www.testquattro.it

FINE DEL SETUP.

A questo punto abbiamo ottenuto che:

i server virtuali non si vedono tra di loro, quindi la compromissione di uno di loro non mettera’ a rischio gli altri.

i server virtuali non sono raggiungibili dall’esterno se non passando attraverso un proxy squid ed un firewall iptables e solo sulla porta 80 con cosi’ tanti filtri da far cacare bulloni roventi al cracker piu’ motivato

i server virtuali non possono raggiungere l’esterno in nessun modo, se ci fosse necessita’ di far deploy di aggiornamenti, sia di sistema che di programmi per i web server bastera’ accendere una route statica verso la lan, aprire il firewall quel tanto che basta per arrivare alle macchine virtuali e basta.

abbiamo a disposizione un potente strumento come squid per poter bloccare comportamenti anomali, il primo che mi viene in mente e’ il vecchio e famigerato baco di IIS che faceva eseguire una shell (cmd.exe) dentro un’url che permetteva di eseguire comandi da browser. Con una semplice regola tipo:

acl iis_nocmd urlpath_regex –i cmd.exe
http_access deny iis_nocmd

possiamo negare l’accesso al web server se nell’url e’ contenutala stringa “cmd.exe”, filtri di questo tipo sono impossibili a firewall che girano a livello piu’ basso, come il pur potente iptables.[/spoiler]
Scritto da Largine aka Lo Spippolo.

Metto sotto spoiler il resto dell’articolo, così se lo legge solamente chi è interessato.
Anni or sono nel mio sito c’era anche un e-zine (cioè una rivista gratuita) trattante argomenti informatici.
Farò una serie di post riportando qualche articolo che reputo interessante, così da dilettarvi un po’ ma sopratutto per non far perdere nei meandri della rete degli scritti (a mio avviso di valore) solamente per il fatto di non fornire più questo servizio nel mio spazio web privato.
Certo, potrei linkare direttamente il file, ma non vorrei cadere nell’ottavo peccato capitale: lo spam, proprio qui, dentro Lega Nerd, che reputo un luogo in cui un pagliaccio come me si trova a suo agio.

WhatsApp, attenzione al codice di attivazione: si rischia di perdere l'account
WhatsApp, attenzione al codice di attivazione: si rischia di perdere l'account
Cybersecurity: in Italia c'è ancora molto da fare
Cybersecurity: in Italia c'è ancora molto da fare
Hacklog: Volume 2, il corso di hacking più seguito in Italia ritorna su IndieGogo
Hacklog: Volume 2, il corso di hacking più seguito in Italia ritorna su IndieGogo
Security of the Digital Natives
Security of the Digital Natives
Ghost in the Wires di Kevin Mitnick
Ghost in the Wires di Kevin Mitnick
Ingegneria sociale e reazioni a catena: un pericolo reale
Ingegneria sociale e reazioni a catena: un pericolo reale
Come scegliere una password sicura