Dlaczego użytkownik chroot_local_user vsftpd jest niepewny?


20

Konfiguruję na moim VPS vsftpd i nie chcę, aby użytkownicy mogli opuszczać katalog domowy ftp. Używam ftp local_user, nie anonimowy, więc dodałem:

chroot_local_user = TAK

Czytałem w wielu postach na forum, że jest to niepewne.

  1. Dlaczego to nie jest bezpieczne?
  2. Jeśli nie jest to bezpieczne z powodu użycia ssh do dołączenia do mojego VPS, to mogę po prostu zablokować tych użytkowników przed sshd, prawda?
  3. Czy istnieje inna opcja uzyskania takiego zachowania vsftpd? (Nie chcę usuwać uprawnień do odczytu dla wszystkich folderów / plików dla „world” w moim systemie)

Odpowiedzi:


20

Sprawdź tutaj często zadawane pytania dotyczące VSFTPD, aby znaleźć odpowiedź, której szukasz. Poniżej znajduje się ważny fragment, który moim zdaniem odpowie na twoje pytanie.

Q) Pomoc! Jakie są implikacje dla bezpieczeństwa, o których mowa w opcji „chroot_local_user”?

A) Po pierwsze, zauważ, że inne demony ftp mają takie same implikacje. Jest to ogólny problem. Problem nie jest zbyt poważny, ale jest taki: Niektóre osoby mają konta użytkowników FTP, którym nie ufa się, że mają pełny dostęp do powłoki. Jeśli te konta mogą również przesyłać pliki, istnieje niewielkie ryzyko. Zły użytkownik ma teraz kontrolę nad katalogiem głównym systemu plików, który jest ich katalogiem domowym. Demon ftp może powodować odczyt niektórych plików konfiguracyjnych - np. / Etc / some_file. Dzięki chroot () ten plik jest teraz pod kontrolą użytkownika. vsftpd jest ostrożny w tej dziedzinie. Ale libc systemu może chcieć otworzyć pliki konfiguracyjne ustawień regionalnych lub inne ustawienia ...


Dzięki za to sam nie wiedziałem tego wszystkiego. Nauczyłem się czegoś! +1
Yanick Girouard

4
Właściwie przyszedłem tutaj po przeczytaniu FAQ, ponieważ nie rozumiem tego niepokojącego stwierdzenia: „Demon ftp może spowodować odczyt niektórych plików konfiguracyjnych - np. / Etc / some_file. Dzięki chroot () plik ten jest teraz pod kontrolą użytkownik.". Przypuszczalnie byłoby to możliwe tylko w przypadku vsftpdbłędu bezpieczeństwa (przepełnienie bufora) ??? W jaki sposób bieganie vsftpdz użytkownikami chroot'owanymi do ich domowego katalogu zwiększa prawdopodobieństwo tego scenariusza? Proszę wyjaśnij ...
sxc731,

4

Problem polega na tym, że nie można zarówno używać kont lokalnych, jak i wyłączać te konta z logowania do powłoki. Jeśli ustawisz ich powłokę logowania na / bin / nologin, nie pozwoli ci to również zalogować się za pomocą vsftpd.

Lepszym i bezpieczniejszym demonem FTP byłby Pure-ftpd. Sprawdź, jest dostępny w repozytorium EPEL i pozwala tworzyć wirtualnych użytkowników. Serwer korzysta ze wspólnego użytkownika / grupy, aby ustawić wszystkie uprawnienia do folderów domowych użytkowników i „mapuje” użytkowników wirtualnych na tego użytkownika, gdy loguje się w celu obsługi uprawnień. To jest bardziej bezpieczne i nie musisz zajmować się bezpieczeństwem logowania openssh.

Pure-ftpd obsługuje również wiele funkcji, takich jak kwoty, współczynniki i tym podobne. Znacznie lepiej niż vsftpd.

Oto prosty samouczek, jak go zainstalować i skonfigurować podstawowego użytkownika wirtualnego: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd- in-centos /

Jeśli przeczytasz pełny dokument (który powinieneś), będziesz wiedział, że przełącznik -d podczas tworzenia wirtualnego użytkownika jest automatycznym chrootem do tego katalogu dla tego użytkownika.


Korzystam z AllowUsers user1 user2dyrektywy w moim sshd_config, gdzie nie pozwalam ftp_user1 na logowanie się za pomocą ssh, nadal użytkownik ftp_user1 jest w stanie zalogować się za pomocą ftp. Więc działa zgodnie z intencją, ale wciąż moje główne pytanie jest otwarte, dlaczego jest niepewne?
p1100i

4
Tak, to będzie! Wystarczy dodać „non-shell” do / etc / shells. W wielu systemach w / etc / shells istnieje / bin / false lub / bin / nologin. Jeśli jest tam powłoka, vsftpd rzeczywiście pozwoli ci się zalogować, także przy włączonym chroot_local_user.
Frands Hansen

1
Jestem wtedy poprawiony. Dzięki za wskazanie tego!
Yanick Girouard
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.