Linux SSH & Apache Multiuser Security

Shotokan - lunedì 28 gennaio

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?

Dilemma della ‘connessione condivisa’

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:


ora decidiamo la directory in cui posizionare gli utenti (/home/ ?) e creiamo un utente di test:


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.


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 😉


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:


…per poi sostituirla con questa:


Ed infine, per chrootare l’ssh bastera’ aggiungere alla fine del file queste righe:


(Disabilitare l’X11 forwarding e’ un’altra cosa intelligente.)

Ora abbiamo gli utenti chrootati ecc ecc, ma come creare degli spazi web sicuri??

Dilemma dell’ “Apache multiuser”

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


Installiamola eseguendo:


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:


Ok, ora la jail e’ pronta, configuriamola quindi con apache, scrivendo questo nel file /etc/apache2/httpd.conf


Et voila’, la jail di Apache e’ pronta 😛

Ora non resta che sistemare l’ambiente SSH configurato in precedenza perche’ abbia una cartella ‘www’:


Ora uniamo la jail SSH con la jail apache & enjoy the result:


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.

Theme made by Koala