Dilemmi, dilemmi continui!
Se aggiungo un utente, cosa potra’ fare sul mio server?
Cosa potra’ leggere, dove potra’ scrivere?
Sembrano risposte facili <<dai pochi privilegi all’utente e non fare cazzate, cretino!>>
..Ma se questo non dovesse bastare?
Dando accesso SSH ad un utente, l’utente potrebbe usare il mio server come proxy sfruttando direttamente il TCPForwarding dell’SSHD.
Vediamo di ridurre i privilegi agli utenti, creando un gruppo apposito:
root@zh-os:~# addgroup jailed
ora decidiamo la directory in cui posizionare gli utenti (/home/ ?) e creiamo un utente di test:
root@zh-os:~# useradd testuser root@zh-os:~# usermod -s "/bin/bash" testuser root@zh-os:~# usermod -G jailed testuser root@zh-os:~# mkdir /home/testuser
Ok, l’utente e’ creato ma ora abbiamo bisogno di un po’ di security! 🙂
Per maggiore security vediamo di effettuare una restrizione delle cartelle che l’utente comune puo’ navigare tramite SSH jail, appunto.
path_user="/home/testuser";
echo "Starting the magic..";
magic_dirs=( /bin /dev /etc /lib /proc /usr );
for d in ${magic_dirs[@]};
do
mkdir "$path_user$d";
chmod 755 "$path_user$d";
echo "Mounting it..";
mount $d "$path_user$d" --bind;
echo "Remounting in RO..";
mount -o remount,ro "$path_user$d";
echo -e "n$(mount | grep " $path_user$d " |cut -d" " -f6)t$dt-> $path_user$dn";
done;
Ottimo, ma cosa abbiamo creato?
sotto /home/testuser/ abbiamo ‘montato’ (in read only) “/bin /dev /etc /lib /proc /usr” in delle sottocartelle, cosi’ da avere un ambiente linux funzionante ma sicuro.
Ora vediamo di creare un ambiente ‘confortevole’ per l’utente finale, evitando che l’utente possa usufruire di tutto il nostro disco, lasceremo a lui solo 100MB di spazio di archiviazione, mettendo la sua home in un’img file di appunto 100MB 😉
u_space=100;
echo "Creating userspace (${u_space}MB)";
dd if=/dev/zero of="$path_user/home.img" bs=1k count=${u_space}kB
sleep 1; echo s | mke2fs "$path_user/home.img";
chown root:root "$path_user/home.img";
chmod 700 "$path_user/home.img";
chown root:root "$path_user";
chmod 755 "$path_user";
mkdir "$path_user/home";
chmod 755 "$path_user/home";
chown root:root "$path_user/home";
mount -o loop "$path_user/home.img" "$path_user/home";
mount | grep "$path_user/home";
chown testuser:testuser "$path_user/home";
chmod 700 "$path_user/home";
echo "Creating user home dir..";
mkdir "$path_user/home/testuser";
chown testuser:testuser "$path_user/home/testuser";
chmod 755 "$path_user/home/testuser";
usermod -d "/home/testuser" "testuser";
echo "Creating external tmp.."
mkdir "${path_user}/tmp";
chmod 755 "${path_user}/tmp";
chown root:root "${path_user}/tmp";
echo "Creating internal .tmp.."
mkdir "${path_user}/home/.tmp";
chmod 755 "${path_user}/home/.tmp";
chown testuser:testuser "${path_user}/home/.tmp";
echo "Mounting temp..";
mount "${path_user}/home/.tmp" "${path_user}/tmp" --bind;
mount | grep "${path_user}/tmp";
Ottimo, ora l’utente ha tutti i permessi per potersi muovere all’interno della home, potendo sfruttare solo 100MB di spazio (tmp compresa!).
Ora vediamo di patchare /etc/ssh/sshd_config in modo che sia attivo l’sftp (per comodita’ dell’utente) MA non possa uscire dalla jail, ed attiviamo la jail SSH.
Per attivare l’sftp integrato dell’SSHD (che sfruttera’ poi la jail) e’ sufficente cercare in /etc/ssh/sshd_config questa riga:
Subsystem sftp /usr/lib/openssh/sftp-server
…per poi sostituirla con questa:
#Subsystem sftp /usr/lib/openssh/sftp-server Subsystem sftp internal-sftp
Ed infine, per chrootare l’ssh bastera’ aggiungere alla fine del file queste righe:
Match Group jailed
ChrootDirectory /home/%u/
AllowTCPForwarding no
X11Forwarding no
(Disabilitare l’X11 forwarding e’ un’altra cosa intelligente.)
Ora abbiamo gli utenti chrootati ecc ecc, ma come creare degli spazi web sicuri??
Di default Apache crea un utente dai privilegi limitati, chiamato www-data, usato per eseguire tutti gli script gestiti da Apache.
Mh, che sia corretto?
E’ giusto che l’utente x e l’utente y vedano i propri script eseguiti dall’utente z?
Ovviamente, no.
Un utente dev’essere sempre limitato ai suoi stessi privilegi, quindi vediamo di effettuare un controllo dell’utente all’esecuzione dei suoi script, eseguendo gli script con l’id dell’utente, ed evitando l’esecuzione di script con privilegi elevati (file con own root non verranno eseguiti)
Per questo ci viene in aiuto una mod di apache chiamata suphp
root@zh-os:~# apt-cache search mod-suphp libapache2-mod-suphp - Apache2 module to run php scripts with the owner permissions
Installiamola eseguendo:
root@zh-os:~# apt-get install libapache2-mod-suphp root@zh-os:~# a2enmod suphp root@zh-os:~# service apache2 restart
Ok! ora i file creati dall’utente x verranno eseguiti dall’utente x 😉
Ora vediamo di creare una struttura che possa permettere all’utente di usare tutti gli script che vuole di un ambiente pulito debian, con la sicurezza di non far mai ‘raggiungere’ all’utente il sistema stesso.
Procediamo col creare una jail di Debian sid:
mkdir /var/chroot debootstrap sid /var/chroot http://ftp.debian.org/debian/ cat /etc/resolv.conf > /var/chroot/etc/resolv.conf cat /etc/hosts > /var/chroot/etc/hosts mkdir /var/chroot/var/www chmod 755 /var/chroot/var/www chgrp www-data /var/chroot/var/www
Ok, ora la jail e’ pronta, configuriamola quindi con apache, scrivendo questo nel file /etc/apache2/httpd.conf
ServerName localhost PidFile /var/run/apache2.pid ChrootDir /var/chroot/
Et voila’, la jail di Apache e’ pronta 😛
Ora non resta che sistemare l’ambiente SSH configurato in precedenza perche’ abbia una cartella ‘www’:
echo "Creating www_sec dir.."; mkdir "$path_user/home/testuser/www_sec"; chown root:testuser "$path_user/home/testuser/www_sec"; chmod 750 "$path_user/home/testuser/www_sec"; mkdir "$path_user/home/testuser/www_sec/www"; chown testuser:testuser "$path_user/home/testuser/www_sec/www"; chmod 755 "$path_user/home/testuser/www_sec/www";
Ora uniamo la jail SSH con la jail apache & enjoy the result:
www_test="/var/chroot/var/www/~testuser/" mkdir $www_test chmod 700 $www_test chroot_dir=/var/chroot/ mount --bind "$path_user/home/testuser/www_sec/www" $www_test mount -o remount,ro $www_test
Non sara’ perfetta, infatti ad ogni avvio avrete bisogno di rieffettuare il mount delle directory, ma e’ possibile chmoddare i file persino a 200 e verranno eseguiti ugualmente da Apache, e difficilmente un’altro utente riuscira’ ad accedervi, ed inoltre grazie al mount in RO abbiamo una protezione nativa fornita appunto da mount contro la modifica e cancellazione degli script.
In pratica: prima che un attacker vi rooti il server credo dovra’ passare diversi deterrenti non da poco.
