Alcuni suggerimenti per il deployment di OpenVZ

Faccio molto affidamento su OpenVZ. In questo articolo vorrei condividere alcune delle mie esperienze personali nel deployment di OpenVZ. Presumo che i lettori sappiano già come installare OpenVZ e le basi di OpenVZ. Questo articolo descrive alcuni suggerimenti sull’uso di OpenVZ tramite la riga di comando. Se preferisci l’interfaccia grafica alla riga di comando, ti prego di consultare come installare WebVZ.

La configurazione descritta qui segue queste linee guida:

il server reale ha installato il software minimo (uso debian Etch con installazione minima) come punto di partenza. Ulteriori applicazioni vengono installate secondo necessità durante il deployment.
il server reale dovrebbe essere il più sicuro possibile. D’altra parte, voglio mantenerlo semplice e facile da configurare/manutenere. Quindi ho scelto un compromesso: mi affido solo a ciò che può essere facilmente distribuito con debian e non vado per cose di sicurezza extra come openwall, selinux, grsecurity, ecc.
ogni servizio necessario è distribuito in un contenitore separato, in modo che interferiscano il meno possibile tra loro
Il rilevamento delle intrusioni per il server reale e i contenitori è distribuito sul server reale utilizzando OSSEC
il firewalling (iptables) è fatto sul server reale; i contenitori eseguono solo i servizi
mi affido a ssh come unico mezzo per accedere e mantenere il server reale e i contenitori.

Sicurezza di base

Prima di distribuire qualsiasi contenitore ovz, apporta alcune modifiche alla configurazione del server reale per renderlo più sicuro:

disabilita la password di root
aggiungi un utente admin-user che può sudo tutto; questo utente ha una password semplice
aggiungi un utente ssh-user che può ssh al server reale; dopo aver caricato la chiave ssh per questo utente, cambio la riga in .ssh/authorized_keys per leggere: command="/bin/su - admin-user" ssh-rsa AAAA... e cambio /etc/pam.d/su per consentire solo a questo utente di su: auth required pam_wheel.so group=ssh-user
per copiare file da/a il server reale, creo un altro utente sftp-user e installo MySecureShell
cambia sshd_config in modo che: - solo ssh-user e sftp-user siano autorizzati a connettersi
l’autenticazione con password è disabilitata (dopo aver caricato le chiavi ssh per ssh-user e sftp-user)
sshd gira su una porta non standard

Schema sopra funziona come segue: per connettersi al server reale, ci connettiamo come ssh-user. Poi dobbiamo digitare la password per admin-user. Se qualcuno ottiene la chiave ssh per ssh-user, deve comunque conoscere la password per admin-user per ottenere accesso al server (il fallimento di /bin/su - admin genererà immediatamente un avviso via email da OSSEC).

Per copiare file da/a il server, utilizziamo sftp con l’account sftp-user. Se qualcuno ottiene la chiave ssh per questo utente, non è un grande problema, poiché può accedere solo ai file sotto il suo $HOME.

Creazione di contenitori OpenVZ

Trovo più comodo creare un template per tutti i contenitori, in modo che quando ho bisogno di un nuovo contenitore, semplicemente faccio un clone dal template. Uso solo debian stable per il server reale e per i contenitori. Quindi, il primo passo è creare un template e adattarlo ai miei gusti:

crea un nuovo contenitore: vzctl create 2002 --ostemplate debian-4.0-amd64-minimal
imposta alcuni parametri di base: vzctl set 2002 --ipadd 192.168.100.2 --nameserver 1.2.3.4 --hostname host2 --save
avvia il contenitore: vzctl start 2002
entra nel contenitore: vzctl enter 2002
preferisco mantenere tutto al minimo, e aggiungere cose secondo necessità. Poiché installare un pacchetto con debian è così facile, ci vuole molto poco sforzo per installare qualsiasi pacchetto di cui abbiamo bisogno. Quindi faccio le seguenti modifiche per il template: - esegui aptitude e deseleziona Opzioni/Gestione delle dipendenze/Installa automaticamente i pacchetti raccomandati
rimuovi alcuni pacchetti che non voglio nel template: bsdmainutils ed groff-base info iptables libconsole libgdbm3 man-db manpages nano netcat openssh-client openssh-server quota ssh traceroute
modifica /etc/apt/sources.list per adattarlo alle mie preferenze
poi fermo il template: vzctl stop 2002

Poi ogni volta che ho bisogno di un nuovo contenitore, utilizzo uno script vz-clone come segue:

#!/bin/bash

# script per clonare un openvz VE

set -e

if [ -z "$2" ]; then
    echo "Usage: $0  "
    exit 1
fi

cfg="/etc/vz/conf/$1.conf"
newcfg="/etc/vz/conf/$2.conf"

if [ ! -e $cfg ]; then 
    echo $cfg non trovato!
    exit 1
fi

VEID=$1
. $cfg
veprivate="$VE_PRIVATE"

VEID=$2
. $cfg
newveprivate="$VE_PRIVATE"

if [ -e $newcfg ]; then 
    echo $newcfg esiste già!
    exit 1
fi

if [ -e $newveprivate ]; then 
    echo $newveprivate esiste già!
    exit 1
fi

if vzlist | fgrep -w -q $1
then
    vzctl stop $1
fi

echo "Clonazione $cfg in $newcfg"
cp -a $cfg $newcfg

echo "Clonazione $veprivate in $newveprivate"
mkdir -p $newveprivate
cd $veprivate
tar cf - . | (cd $newveprivate && tar xf -)

echo "Non dimenticare di modificare $newcfg (devi modificare almeno HOSTNAME e IP_ADDRESS)"
echo "Non dimenticare di fare un alias"

Uso:

sudo sh vz-clone 2002 2010

Clonazione /etc/vz/conf/2002.conf in /etc/vz/conf/2010.conf  
Clonazione /vz/private/2002 in /vz/private/2010  
Non dimenticare di modificare /etc/vz/conf/2010.conf (devi modificare almeno HOSTNAME e IP_ADDRESS)  
Non dimenticare di fare un alias

A seconda del tuo /etc/vz/vz.conf, i percorsi sopra potrebbero essere diversi. Uso le seguenti impostazioni:

VE_ROOT=/vz/root/$VEID
VE_PRIVATE=/vz/private/$VEID

Poi dobbiamo modificare /etc/vz/conf/2010.conf, cambiare ad esempio HOSTNAME in host10, IP_ADDRESS in 192.168.100.10 e siamo pronti a partire con il nuovo contenitore. Faremo anche un alias per il nuovo contenitore, che sarà descritto nella sezione successiva.

Lavorare con i contenitori OpenVZ

I contenitori ovz sono identificati da un numero. Trovo più facile riferirmi a loro per nome/alias, in modo da non dover ricordare ad esempio che 2010 è l’id del contenitore che esegue il servizio dns. A parte questo, voglio anche liberarmi dal dover ricordare i diversi comandi vzctl, vzlist, vzquota, ecc. e i loro parametri. Quindi creo alcuni semplici script per aiutarmi.

Prima creo un elenco di alias /etc/vz-aliases: # alias per openvz VE's 2001 test 2002 template 2010 dns 2020 ldap 2030 mail 2040 web ...
Per tradurre tra ID e alias, creo uno script /usr/local/bin/vz-get-alias come di seguito e faccio di vz-get-veid un symlink a vz-get-alias: #!/bin/sh vz_alias_file="/etc/vz-aliases" case $0 in *vz-get-alias) cat $vz_alias_file | egrep "^[[:space:]]*$1[[:space:]]" | awk '{print $2}' ;; *vz-get-veid) cat $vz_alias_file | egrep "[[:space:]]$1[[:space:]]*$" | awk '{print $1}' ;; esac
Poi metto comandi frequenti per manipolare i contenitori ovz in uno script chiamato /usr/local/bin/vz-cmd-generic: #!/bin/sh set -e ## gestire vz-list prima, poiché non richiede ID/alias case $0 in *vz-list) sedfile=`mktemp` cat /etc/vz-aliases | egrep '^[0-9]' | \ sed 's/$[0-9]*$ *$[a-zA-Z0-9-]*$/s,\1 .*,\&\2,/' > $sedfile sudo vzlist "$@" | sed 's/ $//' | \ sed -f $sedfile | \ sed '1s/$/ALIAS/' exit ;; esac ## gli altri comandi richiedono un ID o alias if [ -z "$1" ]; then echo "Usage: $0 | []" exit 1 fi veid=`/root/bin/vz-get-veid $1` if [ -z "$veid" ]; then veid=$1 fi shift case $0 in *vz-start) sudo vzctl start $veid ;; *vz-restart) sudo vzctl restart $veid ;; *vz-stop) sudo vzctl stop $veid ;; *vz-enter) sudo vzctl enter $veid ;; *vz-exec) sudo vzctl exec $veid "$@" ;; *vz-edit) sudo vi /etc/vz/conf/$veid.conf ;; *vz-quota-ls) sudo vzquota stat $veid ;; *vz-ubc) sudo head -2 /proc/user_beancounters sudo cat /proc/user_beancounters | egrep -A23 "^[[:space:]]+${veid}:" ;; esac E fai in modo che tutti i comandi vz-start, vz-stop, vz-exec, ecc. siano symlink a questo script vz-cmd-generic.

L’uso è quindi semplice:

per elencare tutti i contenitori in esecuzione: vz-list VEID NPROC STATUS IP_ADDR HOSTNAME ALIAS 2010 15 running 192.168.100.10 host10 dns 2020 8 running 192.168.100.20 host20 ldap 2030 23 running 192.168.100.30 host30 mail 2040 11 running 192.168.100.40 host40 web
per elencare tutti i contenitori (inclusi quelli che non sono in esecuzione): vz-list -a VEID NPROC STATUS IP_ADDR HOSTNAME ALIAS 2002 - stopped 192.168.100.2 host2 template 2010 15 running 192.168.100.10 host10 dns 2020 8 running 192.168.100.20 host20 ldap 2030 23 running 192.168.100.30 host30 mail 2040 11 running 192.168.100.40 host40 web
per avviare/arrestare/riavviare un contenitore: - vz-start dns
```
vz-stop dns
```
```
vz-restart dns
```
per eseguire un comando all’interno di un contenitore: vz-exec dns aptitude update
per controllare UBC di un contenitore: vz-ubc dns
per controllare la quota di un contenitore: vz-quota-ls dns
è anche possibile utilizzare un ID invece di un alias: vz-ubc 2010

È anche una buona cosa mantenere l’alias unico tra diversi server reali, in modo da poter condividere /etc/vz-aliases tra di loro senza conflitti.

Questo articolo è già abbastanza lungo, quindi fermiamoci qui. Continueremo nella prossima parte, dove discuteremo questioni come come distribuire il rilevamento delle intrusioni con OSSEC, come monitorare e impostare i parametri UBC per i contenitori, ecc.