DebianAlzi la mano il sysadmin che vuole tutti gli utenti con accesso via SSH ((Secure SHell)) che vi vagano per il sistema!

Vedo qualche mano alzata in fondo… ma probabilmente non sanno nemmeno di che si parla 😛

Andiamo al punto; noi vogliamo creare un sotto sistema in cui gli utenti si possono muovere senza inficiare la sicurezza del sistema vero.

Ingredienti:

  1. Debian Sarge 3.1 (meglio Debian ETCH)
  2. SSH
  3. Debootstrap
  4. libpam-chroot

Configurazione preliminare

Lanciamo aptitude update e aptitude upgrade che non fanno mai male.

Installiamo quindi quello che vi serve ovvero il daemon SSH e Debootstrap scrivendo su terminale dopo aver acquisito i permessi di root ((Amministratore di Sistema))

aptitude install ssh debootstrap libpam-chroot

guardatelo mente scarica installa e configura…

Al momento non ci interessa configurare SSH perch?? esulerebbe dallo scopo di questo HowTo, per cui passiamo alla pratica.

Creiamo una cartella che conterr?? il nostro pseudosistema, ad esempio digitando (sempre con privilegi di root) mkdir /chroot e procediamo con l’installazione di una delle versioni di Debian che pi?? ci sconfinfera tra woody, potato, sarge, etch, lenny e sid. Io personalmente opto per una etch quindi scrivo su terminale

debootstrap etch /chroot/ http://ftp.it.debian.org/debian/

ammirate…

Configurare la Chroot

Adesso dobbiamo configurare /etc/fstab del sistema “Padre” in modo da montare automaticamente all’avvio il filesystem /proc del sistema in /chroot per cui scriviamo sul terminale:
echo "proc-chroot /chroot/proc proc none 0 0" >> /etc/fstab
mount proc-chroot /chroot/proc -t proc

per la configurazione della rete dobbiamo copiare /etc/hosts nello pseudosistema digitando

cp /etc/hosts /chroot/etc/hosts

per verificare il corretto funzionamento del sistema ed esclamare “Ave Debian!” scrivete sul terminale:

chroot /chroot /bin/bash

come potrete constatare ?? impossibile risalire al sistema originale una volta entrati nella “gabbia” (vi baster?? scrivere exit per tornare alla vostra normale console di root).

Bene, abbiamo compiuto 3/4 del lavoro, adesso dobbiamo trovare un modo per ingabbiare gli accessi via SSH nella chroot appena creata e per fare ci?? editiamo((con vim, pico, xterm o tutto quello che volete)) /etc/pam.d/common-session ed aggiungiamo la riga

session required pam_chroot.so

Adesso PAM supporta chroot! Facile no? qualcuno direbbe: “a saperlo…”; ma procediamo editando /etc/security/chroot.conf in modo da avere qualcosa di simile al seguente:

# username chroot_dir
user1 /chroot
user2 /chroot
user3 /chroot
tu /

ovviamente sostituite “user1”, “user2” ecc con gli user che volete ingabbiare e “tu” con l’utente che non deve essere ingabbiato (almeno un utente non deve essere nella chroot).

Note:

Adesso ?? tutto, ma vi lascio un paio di indicazioni per la gestione:

  • Quando create un utente da ingabbiare ricordatevi di creargli la home su /chroot/home e non su /home
  • Quando create un utente aggiungete la riga relativa allo stesso utente presente in /etc/passwd in /chroot/etc/passwd
  • non esister?? il file /chroot/etc/shadow il che vuol dire che gli utenti della chroot non possono cambiare la loro password tramite il comando passwd il che contribuisce per?? ad aumentare considerevolmente la sicurezza del sistema in quanto non gli sar?? possibile provare nemmeno per sbaglio attacchi di cracking sul file /etc/shadow (che peraltro non esiste ai suoi occhi).

Adesso gridiamo tutti insieme: “Evviva Debian!” 😛

15 commenti
  1. Gaglia
    Gaglia dice:

    Bell’howto 🙂 funziona tutto bene tranne una cosa: in questo modo gli utenti che non sono chrooted riescono ad accedere anche tramite SFTP (qualora ssh sia stato opportunamente configurato), mentre gli utenti chrooted vengono disconnessi appena tentato il login.

    Come mai? Come si puo’ fare a dare accesso SFTP (nella jail) anche agli utenti chrooted?

    Rispondi
  2. Salvatore Barbera
    Salvatore Barbera dice:

    @Gaglia: effettivamente c’ho provato pure io, per questo non ho parlato di SFTP nell’howto 😉 a dirla tutta non ho insistito più di tanto sull’argomento, però posso dirti che probabilmente è un problema di librerie…

    art3k@titan-laptop:~$ ldd /usr/bin/sftp
    libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00002b8a101a0000)
    libutil.so.1 => /lib/libutil.so.1 (0x00002b8a10521000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00002b8a10724000)
    libnsl.so.1 => /lib/libnsl.so.1 (0x00002b8a1093b000)
    libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002b8a10b55000)
    libresolv.so.2 => /lib/libresolv.so.2 (0x00002b8a10d89000)
    libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00002b8a10f9e000)
    libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002b8a111ca000)
    libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00002b8a1145e000)
    libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002b8a11683000)
    libedit.so.2 => /usr/lib/libedit.so.2 (0x00002b8a11886000)
    libncurses.so.5 => /lib/libncurses.so.5 (0x00002b8a11aa8000)
    libc.so.6 => /lib/libc.so.6 (0x00002b8a11d04000)
    libdl.so.2 => /lib/libdl.so.2 (0x00002b8a12060000)
    libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00002b8a12264000)
    libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002b8a1246c000)
    /lib64/ld-linux-x86-64.so.2 (0x00002b8a0ff82000)

    in questo momento non ho tempo/hardware per provare, comunque queste sono le librerie richieste nella mia architettura… puoi provare a vedere se le dipendenze dentro la tua chroot sono soddisfate tramite il comando ldd…

    Rispondi
  3. Gaglia
    Gaglia dice:

    Quindi teoricamente basta copiare le librerie necessarie? Caso mai quando ho tempo ci provo.

    Se nel frattempo riesci a farlo funzionare fallo presente qui, questo metodo di chrootare gli utenti ssh e’ uno dei piu’ “eleganti” che ho trovato in rete finora, e’ un peccato che ci sia ‘sto noioso problema 🙂

    Rispondi
  4. Gaglia
    Gaglia dice:

    Risolto!!! Erano proprio le librerie 😀

    Basta cercare le librerie mancanti con “locate nomelibreria” e copiarle nella analoga posizione dentro la chroot. Quindi riavviare ssh.

    Rispondi
  5. Salvatore Barbera
    Salvatore Barbera dice:

    @lastfeel: perchè debootstrap non virtualizza ma utilizza direttamente l’hardware della macchina saltando il passo della virtualizzazione utilizzando il sistema operativo in esecuzione come interfaccia, comunque grazie per lo spunto, metto in scaletta 😉

    Rispondi
  6. lastfeel
    lastfeel dice:

    ti ricordo che vserver usa lo stesso hadware della macchina quindi se possiamo dire cosi vserver fa un chroot ma molti piu avanzato

    Rispondi
  7. Matteo
    Matteo dice:

    mi funziona più o meno tutto.
    quando l’utente ssh si collega ottiene questo messaggio:
    Could not chdir to home directory /chroot/home/utente: No such file or directory

    poi la shell non sembra funzionare “bene” in quanto non mette il $ e non trova i comandi… come mai?

    Rispondi
  8. Matteo
    Matteo dice:

    Ho risolto facendo qualche modifica.
    Praticamente la guida è ok ma bisogna fare queste cose:
    1) io ho creato l’utente facendo adduser pippo –home /chroot/home/pippo
    2) editare il file /etc/passwd togliendo /chroot/ (dovrà quindi essere così: pippo:x:1001:1001:Pippo,,,:/home/pippo:/bin/bash che poi, come dice la guida, andrà copiato in /chroot/etc/passwd)
    3) montare il dispositivo devpts:
    a mano -> mount -t devpts devpts /chroot/dev/pts
    fstab -> devpts /chroot/dev/pts devpts none 0 0

    fatto ciò non ho più avuto problemi

    Faccio presente che se dovete installare dei programmi nell’ambiente jailed dovete:
    1) usare il vostro utente root
    2) charoottarvi nell’ambiente jailed
    3)installare

    Rispondi

Trackbacks & Pingbacks

  1. […] Fonte parziale Fare clic qui per annullare la risposta. Name (required) […]

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *