Perché chroot_local_user di vsftpd non è sicuro?


20

Sto configurando sul mio VPS un vsftpd e non voglio che gli utenti possano lasciare la loro directory home ftp. Sto usando local_user ftp, non anonimo, quindi ho aggiunto:

chroot_local_user = SI

Ho letto in molti post del forum che questo non è sicuro.

  1. Perché questo non è sicuro?
  2. Se questo non è sicuro a causa dell'utilizzo di ssh per unire anche il mio VPS, allora potrei semplicemente bloccare questi utenti da sshd, giusto?
  3. C'è un'altra opzione per ottenere questo comportamento di vsftpd? (Non voglio rimuovere i permessi di lettura su tutte le cartelle / file per "world" sul mio sistema)

Risposte:


20

Controlla qui le FAQ di VSFTPD per la risposta che stai cercando. Di seguito è riportato l'importante estratto che penso risponderà alla tua domanda.

D) Aiuto! Quali sono le implicazioni di sicurezza a cui fa riferimento l'opzione "chroot_local_user"?

A) In primo luogo notare che altri demoni ftp hanno le stesse implicazioni. È un problema generico. Il problema non è troppo grave, ma è questo: alcune persone hanno account utente FTP a cui non è garantito l'accesso completo alla shell. Se questi account possono anche caricare file, c'è un piccolo rischio. Un cattivo utente ora ha il controllo della radice del filesystem, che è la loro directory home. Il demone ftp potrebbe causare la lettura di alcuni file di configurazione, ad esempio / etc / some_file. Con chroot (), questo file è ora sotto il controllo dell'utente. vsftpd è attento in questo settore. Ma, la libc del sistema potrebbe voler aprire i file di configurazione della locale o altre impostazioni ...


Grazie per quello, non sapevo tutto da solo. Ho imparato qualcosa! +1
Yanick Girouard,

4
In realtà sono venuto qui dopo aver letto le FAQ perché non capisco questa preoccupante affermazione: "Il demone ftp potrebbe causare la lettura di alcuni file di configurazione - ad es. / Etc / some_file. Con chroot (), questo file è ora sotto il controllo di l'utente.". Presumibilmente questo sarebbe il caso solo se vsftpdavesse un difetto di sicurezza (à il buffer overflow) ??? In che modo l'esecuzione vsftpdcon gli utenti chroot nella loro home directory rende questo scenario più probabile? Per favore, spiega ...
sxc731

4

Il problema è che non è possibile utilizzare sia gli account locali sia disabilitare tali account dall'accesso alla shell. Se imposti la loro shell di accesso su / bin / nologin, non ti permetterà nemmeno di accedere con vsftpd.

Un demone FTP migliore e più sicuro sarebbe Pure-ftpd. Cerca, è disponibile dal repository EPEL e consente di creare utenti virtuali. Il server utilizza un utente / gruppo comune per impostare tutte le autorizzazioni per le cartelle home degli utenti e "mappa" gli utenti virtuali a quell'utente quando accede per gestire le autorizzazioni. È più sicuro e non devi occuparti della sicurezza dell'accesso a openssh.

Pure-ftpd supporta anche molte funzionalità come quote, rapporti e così via. Molto meglio di vsftpd.

Ecco un semplice tutorial su come installarlo e configurare un utente virtuale di base: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd- in-centos /

Se leggi il documento completo (che dovresti) saprai che l'opzione -d durante la creazione dell'utente virtuale è un chroot automatico per quella directory per quell'utente.


Uso la AllowUsers user1 user2direttiva nel mio sshd_config, dove non consento a ftp_user1 di accedere con ssh, tuttavia l'utente ftp_user1 è in grado di accedere con ftp. Quindi funziona come previsto, ma la mia domanda principale rimane aperta, perché non è sicuro?
p1100i,

4
Si lo farà! Devi solo aggiungere il "non-shell" a / etc / shells. Su molti sistemi esiste / bin / false o / bin / nologin in / etc / shells. Se la shell è lì, vsftpd ti consentirà di accedere, anche con chroot_local_user abilitato.
Frands Hansen,

1
Sono corretto allora. Grazie per segnalarlo!
Yanick Girouard,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.