di Alissa
Contesti di Sicurezza
Emulazione o non emulazione, questo e’ il problema…
Parte 1)
Fino ad oggi la parola d’ordine per i contesti di sicurezza era “emulazione”, almeno fino all’avvento del progetto GNU Linux Vserver. Suddetti non sono solo destinati a essere giocattoli oppure adibiti ad ambienti di test (ciò per cui sono stati creati), i vserver esprimono tutta la loro potenzialità proprio dove i progetti di emulazione falliscono.
Ma cominciamo dall’inizio: “Cosa sono i contesti di sicurezza, o per meglio chiamarli, i CHROOT?” I CHROOT, o macchine virtuali, sono sistemi operativi, che in alcuni casi agiscono all’interno di hardware emulato, in esecuzione su una più macchine reali denominate host.
La macchina virtuale, o chroot, non è consapevole di essere un ospite all’interno di una macchina reale. Ovviamente anche gli utilizzatori dei servizi presenti sulla macchina virtuale non riescono a distinguere la differenza. L’unica cosa reale è che i servizi forniti funzionano alla perfezione.
Uno degli scopi principali di una macchina virtuale (chroot, vserver, UML o altro), ora diventa chiaro: poter operare in TOTALE sicurezza in un ambiente di test dovre provare funzionalità, nuovi programmi, colegarsi ad internet in sicurezza, senza aver paura di essere attaccati dal cracker di turno, oppure sperimentare cambiamenti che poi verranno effettuati su un sistema padre.
Uno scenario interessante ove applicare i vserver è l’hosting condiviso, dove utilizare un server virtuale significa consegnare al cliente un vero e rpoprio server dedicato senza, ovviamente, consegnargli anche hardware dedicato. Naturalmente ogni cliente ha solo potere entro il suo vserver, ciò permette di mettersi al sicuro dai problemi di sicurezza, che avrebbero conseguenze catastrofiche nel caso si un server condiviso da più utenti.
Un’altro aspetto interessante, che stà determinando il successo dei vserver, è per gli usi non dedicati ai provider. Spesso un pc deve dare servizi all’esterno (su internet o intranet),e per ogni servizio aperto possono esistere dei problemi di sicurezza (exploit, cracker malintenzionati, etc) che possono compromettere la sicurezza dell’intera machina reale. Una delle strade, utilizzate per evitare questo inconveniente, è di allocare i singoli servizi sensibili all’interno di un chroot.
I server virtuali (LInux Vserver) permettono di separare ulteriormente il contesto utilizzatodal servizio, separando non solo il filesystem, ma tutta la gestione dei processi legati ad esso.
Esstono diversi modi di realizzare server virtuali basati su GNU/Linux, e cominciando ad escludere WmWare, i 2 progetti più importanti sono User-Mode-Linux e GNU/linux Vserver, entrambi rilasciati sotto licenza GPL, il primo basato su emulazione, e il secondo basato su contesto di sicurezza.
Emulare o NON emulare?
Sembra essere un dubbio Amletico, in realtà è una questione vitale: quando si vuole fornire un servizio/ provare programmi o settaggi del computer da macchine virtuali, bisogna ugualmente avere buone se non ottime prestazioni rispetto ad un
computer/server reale. L’emulazione non gioca a favore in quanto la macchina virtuale comunica con la macchina host utilizzando unicamente l’emulatore. Prendendo come esempio User-mode Linux, esso agisce eseguendo un kernel emulato per l’architettura
virtuale “UM” ed utilizza hardware virtuale indipendente da quello della macchina host.
Anche la gestione dei dischi fissi può essere emulata facendo credere alla macchina virtuale che un file sia in realtà un disco rigido. Anche se sembra molto comodo avere un disco rigido virtuale su file, la verità come al solito non è così rosea come si vorrebbe che fosse., basta pensare alla frammentazione: file che alla macchina virtuale sembrano contigui, in realtà sulla macchina host sono chissà dove sono sparsi sul disco rigido reale. L’emulazione inoltre non è mai perfetta, e per alcuni programmi potrebbero ugualmente non funzionare o potrebbero mandare in panne l’intera macchina virtuale.
Linux Vserver: la Soluzione
Il progetto vserver nasce nel 2001 per un colpo di genio di Jacques Gèlinas, l’idea originaria era di entendere il concetto di contesto di un processo includendo anche un contesto di sicurezza. In parole semplici, l’obbiettivo di Linux Vserver è di associare ad ogni processo un contesto di sicurezza che comprende le risorse utilizzabili quali un IPv4 di rete, un’area di filesystem e, con alcune patch sperimentali, una quota del disco rigido e/o memoria. Un processo associato a un contesto di sicurezza può vedere soltanto le risorse e i processi associati a quel contesto, senza quindi mettere le zampe altrove. Le carte in tavola ci sono tutte, direi, solo che non è ancora chiaro come entrino in gioco i server virtuali con tutto ciò.
Non è banale, l’idea è quella di associare le risorse destinate al server virtuale ad un nuovo contesto di sicurezza a cui associare tutti i processi di tale linux vserver. La spiegazione tecnica del funzionamento è molto complessa, e porterebbe via
molto tempo,ma realizzare e gestire un server virtuale con questo sistema è in realtà molto più semplice di quanto si possa pensare. A differenza di UML, non abbiamo bisogno di emulare hardware, i processi dei server virtuali sono schedulati ed eseguiti direttamente dalla macchina host, con ovvi vantaggi sulle prestazioni. Inoltre il server virtuale non usa un Kernel virtuale emulato, ma quello della macchina host su cui è realmente in esecuzione. Può sembrare un vantaggio da poco, ma considerate questo caso: su una macchina ci sono 100 macchine virtuali con un proprio kernel, se per qualche evenienza si dovesse effettuare l’aggiornamento, si deve procedere ad aggiornare il Kernel a tutti e 100 chroot. Utilizzando i Linux Vserver invece l’unico Kernel da aggiornare è soltato quello della macchina host, un bel risparmio di lavoro al sistemista di turno, non c’è che dire eh? ;)
Parte 2)
Prepapare la macchina HOST
Ma ora ciancio alle bande, e fuoco alle polveri! abbiamo parlato troppo passiamo ai fatti. Dopo tante parole è arrivato il momento di mostrarvi e sperimentare il sistema vserver allestendo con poche operazioni la macchina host che sarà la casa dei nostri server virtuali. Purtroppo bisogna partire con un paio di note dolenti: nel momento in cui stò scrivendo questo speech il kernel ramo 2.6 non è pienamente suportato, data la sua enorme diversità dal ramo 2.4, nonostante siano presenti delle patch sperimentali e una dichiarata stabile (anche se provata personalmente dopo 2 giorni il pc host crasha inesorabilmente), esse sono da utilizzare a proprio rischio e pericolo, invece per i kernel ramo 2.4 nessun problema finora riscontrato. Inoltre non è ancora suportato il protocollo IPv6, anche se nGnet stà creando qualcosa in merito, stiamo a vedere cosa uscirà.
Il primo passo è procurarsi i sorgenti del kernel da http://www.kernel.org
Il codice sorgente ovviamente deve essere decompresso e configurato a dovere. Ora serve tutto il necessario per i Vserver ovvero la patch per il kernel scelto e le utility per la gestione dei server virtuali:
dazio1:/usr/src# tar -xjf linux-2.4.30.tar.bz2
dazio1:/usr/src# cd linux-2.4.30
dazio1:/usr/src/linux-2.4.30# wget http://www.13thfloor.at/vserver/s_release/v1.2.10/patch-2.4.30-vs1.2.10.diff
--08:33:42-- http://www.13thfloor.at/vserver/s_release/v1.2.10/patch-2.4.30-vs1.2.10.diff
=> `patch-2.4.30-vs1.2.10.diff'
Resolving www.13thfloor.at... 212.16.62.55
Connecting to www.13thfloor.at|212.16.62.55|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/octet-stream]
[ ] 154,007 41.29K/s
08:33:48 (41.17 KB/s) - `patch-2.4.30-vs1.2.10.diff' saved [154007]
dazio1:/usr/src/linux-2.4.30# patch -p1 /dev/null
dazio1:/usr/src/linux-2.4.30# make mrproper && make menuconfig
Dopo aver applicato la patch al kernel, è necessarrio attivare la voce di configurazione necessarie al funzionamento dei vserver:
[ Block devices => Root device support]
A meno di non aver applicato anche la patch per la quota disco o GRsecf, o altre funzionalità questa è l’unica voce necessaria. Ora basta il canonico:
dazio1:/usr/src/linux-2.4.30# make dep && make bzImage && make modules && make modules_install
e le alte consuete operazioni di installazione del nuovo kernel. Dal punto di vista della macchina host, ora, abbiamo soddisfatto tutte le esigenze Kernel-space, or mancano soltanto le utility User-space, problema che con i classici:
dazio1:/usr/src/linux-2.4.30# cd /root
dazio1:~# wget http://www.13thfloor.at/vserver/s_release/v1.2.10/util-vserver-0.30.tar.bz2
--08:39:45-- http://www.13thfloor.at/vserver/s_release/v1.2.10/util-vserver-0.30.tar.bz2
=> `util-vserver-0.30.tar.bz2'
Resolving www.13thfloor.at... 212.16.62.55
Connecting to www.13thfloor.at|212.16.62.55|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 212,911 (208K) [application/x-bzip2]
100%[==================================================================================>] 212,911 35.13K/s ETA 00:00
08:39:54 (35.22 KB/s) - `util-vserver-0.30.tar.bz2' saved [212911/212911]
dazio1:~# tar -xzf util-vserver-0.30.tar.bz2
dazio1:~# cd util-vserver-0.30
dazio1:~/util-vserver-0.30# ./configure && make && make install
siano capaci di risolvere.
L’ultima operazione da fare è la creazione della directory/partizione /vservers con i permessi richiesti per il corretto funzionamento dei Vserver:
dazio1:~/util-vserver-0.30# dazio1:~/util-vserver-0.30# mkdir /vservers (oppure create una partizione e mountatela come /vservers) dazio1:~/util-vserver-0.30# chmod 000 /vservers/ dazio1:~/util-vserver-0.30# chattr -t /vservers/ dazio1:~/util-vserver-0.30#
Parte 3)
Preparare e configurare un Vserver linux e configurazione medesimo
La creazione di un Vserver è estremamente semplice, si può partire costruendo un CHROOT con tutto il necessario, ma la soluzione migliore è di usare uno script creato ad hoc, quelli contenuti nel pacchetto delle utility installate prima,
dazio1:/usr/bin# cd /usr/local/lib/util-vserver/ dazio1:/usr/local/lib/util-vserver# ls capchroot install-fc1 install-rh8.0 readlink sample.sh vbuild vsysvwrapper distrib-info install-mdk8.2 install-rh9.0 rh7.3-minimum save_s_context vcheck vunify fakerunlevel install-post.sh legacy rh8.0-minimum setattr vprofile fc1-minimum install-pre.sh listdevip rh9.0-minimum showattr vreboot filetime install-rh7.2 mdk8.2-minimum rootshell showperm vserverkillall ifspec install-rh7.3 parserpmdump sample.conf util-vserver-vars vservers.grabinfo.sh dazio1:/usr/local/lib/util-vserver#
in modo da installare un Vserver basato su una distribuzione specifica. Avete capito bene, possiamo far girare qualsiasi distribuzione linux nei Vserver. E non è importante neanche che distribuzione stia girando sulla macchina host. Ad esempio creiamo un Vserver Debian woody. Possiamo usare 2 script in questo caso:
debian-newvserver.sh oppure deploy-vserver.sh (crea-vserver.sh versione italiana by Infinity) http://www.paul.sladen.org/vserver/debian/debian-newvserver.sh http://debian.marlow.dk/vserver/guest/ (qui trovate la utility e varie distro prefatte.)
Nel primo caso serve l’utility DEBOOTSTRAP, nel secondo caso basta solo ed esclusivamente lo script. Nel secondo caso
dazio1:~# ./deploy-vserver.sh notreally notreally.mynetwork.bofh 192.168.0.10 sarge | more
utilizzando deploy-vswerver.sh, creerà un vserver virtuale chiamato notreally e con IP 192.168.0.10, il tutto occupando meno di 500MBdi spazio disco. Nella direcotry /etc/vservers/ verrà creato anche il file di configurazione di suddetto vserver, che altrimenti dovrebbe essere creato a mano , la cui creazione cmq non è un’operazione difficilissima, anzi…
dazio1:~# cat /etc/vservers/notreally.conf S_HOSTNAME=notreally.mynetwork.bofh IPROOT=192.168.0.10 IPROOTDEV=eth0 IPROOTMASK=255.255.255.0 IPROOTBCAST=192.168.0.255 ONBOOT=yes S_FLAGS="lock nproc" ULIMIT="-H -u 1000" S_CAPS="CAP_NET_RAW" dazio1:~#
Il vserver appena creato è in esecuzione, se non lo fosse per dare via alle danze serve dare il comando:
dazio1:~# vserver notreally start
Verrà creato un contesto di sicurezza, assegnato ad esso un IP di rete impostato nella configurazione ed avviato il sistema minimale,composto nel nostro caso da soli 5 servizi vitali quali cron,syslog e inetd. Per controllare quali e quantoi vserver sono in esecuzione basta dare il comando:
dazio1:~# vserver-stat CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME DESCRIPTION 0 115 1GB 130kB 7h43m05 1d12h34 95d05h04 root server 49152 18 151MB 16kB 15m04.17 9m34.46 95d05h01 hosting 49153 4 6MB 713B 4m01.49 2m29.93 79d04h58 windows 49155 24 328MB 47kB 9m42.69 1m50.57 2d07h12 notreally dazio1:~#
Verranno elencati i contesti di sicurezza attivi comprensivi di uptime e numero di processi. Un aspetto interesante è osservare come i singoli processi sono visti sulla macchina. Eseguire un “ps aux” sulla macchina host, non mostra alcun processo delle macchine virtuali. Nello stesso modo, all’interno di una macchina virtuale, lo stesso comando, mostra solo i processi del proprio contesto. Le utility date a corredo dal progetto Vserver, comprendono i rpogrammi “vtop” e “vps” che funzionano allo stesso modo dei prorpi “omonimi” mostrando però tutti i processi dei contesti di sicurezza.
Come vedete sono elencati i processi del server host e dei vserver, chiamandoli per nome. E si può facilmente anche notare che i processi “virtuali” siano effettivamente dei processi “reali” sulla maccchina host. Inoltre analizzando la gestione della rete nei vserver, possiamo notare che non si tratta di una interfaccia emulata in bridge come avveniva su UML. Il Server Virtuale utilizza un IP alias sulla interfaccia reale scelta (eth0), come possiamo verificare con i comandi di sistema IP:
Il server virtuale non deve preoccuparsi di configurare internamente la rete, il contesto di sicurezza include già una interfaccia e un idirizzo IP già visibili ed utilizzabili dai processi ad esso associati.
dazio1:~# vserver notreally enter
/usr/local/sbin/vserver: line 715: ulimit: max user processes: cannot modify limit: Invalid argument
ipv4root is now 192.168.0.10
New security context is 49155
notrealy:/# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:DC:CD:63:D8
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1440216160 errors:0 dropped:0 overruns:0 frame:0
TX packets:1427935129 errors:274379 dropped:0 overruns:0 carrier:548758
collisions:1268402
RX bytes:1688978731 (1.5 GiB) TX bytes:2649455012 (2.4 GiB)
eth0:notr Link encap:Ethernet HWaddr 00:10:DC:CD:63:D8
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8130793 errors:0 dropped:0 overruns:0 frame:0
TX packets:8130793 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:1392012198 (1.2 GiB) TX bytes:1392012198 (1.2 GiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:353 errors:0 dropped:0 overruns:0 frame:0
TX packets:27769 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:23439 (22.8 KiB) TX bytes:1785907 (1.7 MiB)
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:27468 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:180 (180.0 b) TX bytes:1757972 (1.6 MiB)
notreally:/#
La gestione dei file dei vserver è quasi un banale CHROOT, che offre tutti i vantaggi di evitare un file immagine per l’intero filesystem e di avere lo spazio libero condiviso tra host e vserver. Questo sistema potrebbe permettere, anche se ufficialmente è una pratica sconsigliata, operazioni di modifica o aggiornamento dei file contenuti nei vserver da parte della macchina host, permettendo cambi centralizzati.
Parte 4)
Come utilizzare i Vserver LINUX
Con pochi e semplici passi abbiamo creato i nostri vserver, quando un server è attivo possiamo accedervi utilizzando il comando “vserver”:
dazio1:~# vserver notreally enter /usr/local/sbin/vserver: line 715: ulimit: max user processes: cannot modify limit: Invalid argument ipv4root is now 192.168.0.10 New security context is 49155 notreally:/#
Il prompt di comando che apparirà è una bash, o un’altra shell installata (ad esempio sh) che agisce all’interno del vserver stesso. E’ possibile avere anche altri metodi di accesso al Vserver, basta installare un demone SSH (sshd)
notreally:/# apt-get install sshd
al suo interno oppue agganciare una consolle al device utilizzato dal vserver, operazione non difficile composta in 3 semplicissimi passi:
1) commentare la riga del tty scelta nel file /etc/inittab e ricopiarla nel file /vservers/nomevserver/etc/inittab
2) eseguire il seguente comando sulla macchina host:
cp -ax /dev/ttyX /vservers/nomevserver/dev
dove X stà per la tty scelta.
3) riavviare il vserver
Sulla consolle scelta ora apparirà il rpompt del login del server virtuale. Una volta essere entrati nel vserver, la libertà di utilizzo è infinita: è possibile eseguire comandi, installare o compilare qualsiasi tipo di applicativo, creare utenti e impostare servizi. Ad esempio vogliamo che il vserver in cui stiamo operando fornisca un servizio basato sul web (volete hostare da soli il vostro sito internet?)?
notreally:/# aptget install apache php mysql-server
è la risposta. Se vogliamo accedere al servizio web del server virtuale dall’esterno della nostra LAN, nel caso si disponesse di un solo IP pubblico (adsl, dial up, etc) è possibile configurare il vserver per utilizzare lo stesso IP della macchina host, ma questa pratica la sconsiglio vivamente, invece consiglio di usare una semplicissima regola di NAT impostata con IPTABLES sulla macchina HOST:
iptables - t nat
Ma non è sempre necessario dover accedere al vserver utilizzando il comando vserver enter o via ssh. Il comando vserver per mette anche l’esecuzione di comandi non interattivi , utile per automatizzare alcune operazioni, visto che siamo su debian, ad esempio apt-get update && upgrade. Quindi se vogliamo automatizzare il processo di aggiornamento dei pacchetti basta uno scriptino che segua:
for i in $listadiserverdebian; do vserver $i exec apt-get update, vserver $i exec apt-get upgrade, done
Non è necessario conoscere altro, a meno di necessità particolari, l’unica difficoltà è solo quella di non considerare i vserver come i classici giocattolini usa e getta (guardate il tempo per creare e configurare un vserver ;), ma come veri e propri sistemi operativi. Il server virtuale quindi necessiat di cure, tra cui in primis i controlli di sicurezza (quelli non dovrebbero mai mancare, gli exploit si sussegono a un ritmo sempre più incalzante) dei servizi forniti, quanto un PC normale.
Parte 5)
Pecorella Dolly e i backup
Come dicevamo prima creare sempre un vserver partendo dal nulla, se sono richieste modifiche e personalizzazioni particolari, può essere un operazione assolutamente non banalissima e immediata. Il progetto vserver si dimostra ancora una volta una soluzione versatile e soprattutto di facile uso. Infatti basta creare un vserver “scheletro” da usare come se fosse la pecorella Dolly (scusate la similitudine), pronto per clonare ed esere clonato. Se noi vogliamo clonare il vserver notreally per creare un suo clone basta una semplicissima operazione:
dazio1:~# /usr/sbin/vserver-copy -i 192.168.0.1 -d mynetwork.bofh notreally infinity
Il comando clonerà il server virtuale notreally in un nuovo vserver infinity e scriverà automaticamente il file i configurazione partendo dal file originario. I parametri permettono di specificare il cambiamento di alcuni parametri di configurazione, in questo caso l’IP e il dominio di rete. Naturalmente potrebbe essere necessario aggiornare la configurazione di alcuni programmi presenti nel nuovo vserver, ma la maggior parte del lavoro oramai è fatta.
Effetturare il backup dei vserver è un’operazione altrettanto semplice: la macchina host ha PIENO ACCESSO ai file e le directory dei vserver, quindi la possibilità di effetturare dei salvataggi e dei backup, compresi quelli incrementali, sono infinite. Largo spazio quindi ad Amanda o a script banalissimi (come uso io) che esegua semplicemente:
dazio1:~# tar -cf vserver.tar.gz /vserver/nomevserver /etc/vservers/nomevserver.conf
Il file generato può essere utilizzato su qualsiasi macchina, che abbia un Kernel con attivo il supporto per i vserver, senza che il vserver stesso non si accorga di nulla. Un aspetto MOLTO utile se si considera che un eventuale ripristino dei vserver su un’altra macchina fisica dopo un guasto hardware consistente o per la necessita di un upgrade della macchina host stessa.
Parte 6)
Conclusioni
Come visto da questo howto i virtual server sicuramente faranno strada, poiche’ il loro utilizzo non richiede esperienza e i vari settaggi si fanno ad occhi chiusi. L’unica cosa da tener presente e di non utilizzare i Vserver come giocattolini
ma come e veri e propri pc (non di meno molti li usano come ambienti di test ove UML, XEN e altri falliscono).
I Vserver permettono di affrontare cambiamenti radicali di settaggi in pochissimi passaggi, senza riavviare il pc, o avere downtime, cosa che ad alcuni risulta molto fastidioso, non di meno si puo’ dedicare hardware al vserver in modo da effettuare test in sicurezza senza “incasinare” il pc vero e proprio ;)
Link utili:
Progetto Linux Vserver: http://www.linux-vserver.org
Patch Kernel e utility: http://www.13thfloor.at/vserver/
Distro preconfigurate per il funzionamento da Vserver:
http://debian.marlow.dk/vserver/guest/
Per info: infinitycommunicatio@tiscali.it
Alissa
FINE
ottimo howto, dovresti rilasciarlo con qualche licenza (GFDL? cc?) e mtterlo in giro.
grazie, i complimenti vanno all’autrice :)
cga se guardi in alto sotto “PollyCoke Legalese” leggerai che tutto il materiale del sito è rilasciato sotto CC: si può distribuire e copiare ma non modificare