Komunikat o błędzie „500 OOPS: vsftpd: odmowa uruchomienia z zapisywalnym rootem w chroot ()” - uwięzić użytkownika


19

Do tej pory nie byłem w stanie uwięzić użytkownika FTP w katalogu witryny. Czy istnieje rozwiązanie, które naprawia ten błąd i powoduje, że użytkownik jest więziony w swoim katalogu?

Moje ustawienia vsFTPd, które zmieniłem:

listen_port=9000
Set: anonymous_enable=NO
Uncomment: local_enable=YES
Uncomment: write_enable=YES
Uncomment: local_umask=022
Set: connect_from_port_20=NO
Uncomment: idle_session_timeout=600
Uncomment: data_connection_timeout=120
Comment out: #ftpd_banner=Welcome to blah FTP service. [should be on line 104]
Added: banner_file=/etc/issue.net
Uncomment: chroot_local_user=YES
Uncomment: chroot_local_user=YES
Uncomment: chroot_list_enable=YES
Uncomment : chroot_list_file=/etc/vsftpd.chroot_list

Na końcu pliku dodałem:

# Show hidden files and the "." and ".." folders.
# Useful to not write over hidden files:
force_dot_files=YES

# Hide the info about the owner (user and group) of the files.
hide_ids=YES

# Connection limit for each IP address:
max_per_ip=10

# Maximum number of clients:
max_clients=5

# FTP Passive Settings
pasv_enable=YES
#If your listen_port is 9000 set this range to 7500 and 8500
pasv_min_port=[port range min]
pasv_max_port=[port range max]

Użytkownik, o którym mowa, mybloguserjest więziony w swoim katalogu swojej witryny pod, /srv/www/mybloga ten użytkownik nie jest częścią nano /etc/vsftpd.chroot_listpliku. Katalog domowy użytkownika jest również tym, /srv/www/myblogktóry działał w przeszłości.

Wypróbowałem allow_writeable_chroot=YESrozwiązanie, które nie działało i faktycznie całkowicie zepsuło vsFTPd.

Próbowałem:

Jak możemy naprawić ten błąd i zatrzymać użytkownika w katalogu domowym?


Jakoś dla mnie, przynajmniej z „wirtualnymi” użytkownikami ftp, samo dodanie ustawienia allow_writeable_chroot=YESwystarczyło i faktycznie działało „zgodnie z oczekiwaniami” FWIW ...
rogerdpack

Odpowiedzi:


18

W przypadku VSFTPD 3

  1. Iść do: /etc/vsftpd.conf
  2. i dodaj to:

    allow_writeable_chroot=YES
    

    Po prostu dodaj go, jeśli jeszcze nie istnieje.

  3. Uruchom ponownie usługę vsftpd:

    service vsftpd restart
    

I powinno działać.


3
Pytający faktycznie twierdzi, że już tego próbował i nie zadziałało, więc nie jest to odpowiedź na jego pytanie.
Wymagaj

2
Gdzie mogę przeczytać o konsekwencjach bezpieczeństwa dla tego wyboru?
flickerfly

pracował dla mnie (wspomniano to również w komentarzu do zaakceptowanej odpowiedzi)
Sverre

16

Prawdziwe rozwiązanie tego problemu: folder domowy użytkownika nie powinien być zapisywalny, a jedynie czytelny.

Tak więc, jeśli witryna użytkownika znajduje się w folderze jest cat/example.com/http/, folder catmusi mieć chmod 555i wszystko będzie w porządku.


12
To nie ma sensu. Katalog użytkownika nie powinien być zapisywalny?
Kevin Bowen

6
Jak dokładnie użytkownik powinien UPLOAD pliki, jeśli nie mogą pisać ?!
Cerin,

Działa dobrze dla anonimowego ftp bez praw do przesyłania, dzięki!
palacsint

dobrze! teraz jest ok
użytkownik1406691

5
To działa idealnie! Po prostu stwórz dom dla użytkownika z chmod 555, a następnie stwórz dom dla strony internetowej (lub stron), z chmod 755 lub potrzebną: wszystko będzie działać, a użytkownik będzie miał uprawnienia do zapisu.
lucaferrario,

13

Po dalszej recenzji tego postu w komentarzach opublikowano paczkę, która rozwiązała mój problem. Możesz go wyszukać według mojego nazwiska lub Dokumentacji „Znaki”: http://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/ . Oto moje szczegóły, jak to naprawić.

UŻYTKOWNICY WCIĄŻ SĄ WIĘZI DO SWOICH DOMOWYCH KATALOGÓW !!!

# ------------------------------------------------------------------------------
# SETUP FTP USERS --------------------------------------------------------------
# ------------------------------------------------------------------------------

# create the ftp users and lock them to the website directories
useradd -d /srv/www/[website/appname] -m [ftp user name]

# set the ftp account passwords
passwd [ftp user name]

# add the ftp users to the www-data user/group
adduser [ftp user name] www-data

# BUG FIX: 500 OOPS: vsftpd: refusing to run with writable root inside chroot()
sudo add-apt-repository ppa:thefrontiergroup/vsftpd
sudo apt-get update
sudo apt-get install vsftpd

# Edit the vsftpd.conf and append this setting to the end of the file to keep users' jailed!
nano /etc/vsftpd.conf

# add all of the text between the starting [[ and ending ]]
# [[

# Keep non-chroot listed users jailed
allow_writeable_chroot=YES

# ]]

# restart the service for changes to take effect
sudo service vsftpd restart

#test ftp via secondary terminal window:
ftp [ftp user name]@[server ipaddress] [ftp port]

11
Uwaga: rozwiązanie Chrisa doda serwer pakietów innych firm do listy repozytoriów! Po co instalować bezpieczny, chrootowany serwer FTP, gdy ślepo śnisz akceptujecie zagraniczne pakiety oprogramowania do zainstalowania w systemie. (Chris: Nie sądzę, że skorzystasz, ale korzystanie z tego rozwiązania IMHO jest kiepskim zarządzaniem)
reto

1
czy masz lepsze podejście do rozwiązania tego dylematu? To był mały bałagan do rozwiązania. Dziękuję za pomoc.
Chris Hough,

jeśli jest jakiś zaktualizowany pakiet z dystrybucji, spróbuję go użyć. Większość dystrybucji zapewnia backport dla starszych wersji. Jeśli nie jest to możliwe, pozyskam źródło od oryginalnego programisty i sam go zbuduję. Jeśli wokół jest łatka, mogę ją zastosować (zazwyczaj są one małe i można je sprawdzić ręcznie).
reto

Wątek ma 12 000 wyświetleń, załóżmy, że 5% korzysta z twojego rozwiązania i dodało twoje repo. Możesz łatwo dodać nową wersję pakietu podstawowego ze zintegrowanym backdoorem. W ciągu tygodnia możesz mieć dostęp do 600 systemów. Nie sądzę, żebyś to zrobił, ale dodanie repozytorium innej firmy po prostu nie jest zbyt bezpieczne.
reto

1
Nie potrzebowałem aktualizacji z repo. Dla mnie dodanie wiersza „allow_writeable_chroot = YES” naprawiło błąd
abumalick

7

Zgodnie z poprzednią odpowiedzią „PRAWDZIWE rozwiązanie tego problemu: folder domowy użytkownika nie powinien być zapisywalny tylko do odczytu”. Ogólne myślenie jest słuszne, ale z błędną realizacją.

Poniżej postaram się podać prosty przykład:

Na początek musimy zbudować topologię katalogu użytkownika:

 / home (ro)
   | -someuser (rw, 700)
         | -ftp_upload (ro, 555) - ch_rooting tutaj, wymagane tylko do odczytu przez vsftpd :(
           | -temp (rw, 755)
           | -in_box (rw, 755)
           | -out_box (rw, 755)

Wytnij vsftpd.conf:

# Włącz chrooting
chroot_local_user = TAK

# chroot wszyscy użytkownicy oprócz nasłuchiwani wewnątrz listy chroot_list
chroot_list_enable = TAK

# Lista wyjątków. Idealnie powinno być puste;)
chroot_list_file = / etc / vsftpd / chroot_list

# Zamapuj katalog główny ftp na określony katalog
local_root = / home / someuser / ftp

Ta konfiguracja działa świetnie z konfiguracją dla jednego użytkownika . W przypadku wielu użytkowników należy dodatkowo zastosować dyrektywę „user_config_dir”.

** AKTUALIZACJA 20/09

------ **

Oto trudne obejście, nie najlepszy pomysł, ale ... Jeśli potrzebujesz zapisywalnego folderu głównego ftp, po prostu wstaw polecenia zmiany uprawnień w poleceniach przed uruchomieniem i po uruchomieniu.

  1. Przed uruchomieniem - zmień uprawnienia na tylko do odczytu, których wymaga serwer (:

  2. Uruchom serwer

  3. Po uruchomieniu - zmień uprawnienia do odczytu i zapisu lub potrzebne.


Próbowałem wielu odmian, ale nie mogłem sprawić, by działał na serwerze WP. Czy to działa w przypadku konfiguracji WP?
Chris Hough

zajrzyj do działu aktualizacji, mauby, ten wariant może ci pomóc, nie jest to całkowicie bezpieczne, ale jeśli nie ma innych możliwości ...
Reishin

1

To właściwie to, o czym wspomniał toastboy70. Ustaw katalog ftp-root w chown'd na ftp.ftp i nie do zapisu (/etc/vsftpd.conf): anon_root = / srv / ftp

Następnie utwórz zapisywalny katalog potomny: / srv / ftp / upload


0

Musiałem również dodać następujące elementy do pliku /etc/vsftpd.conf:

seccomp_sandbox=NO

I nie ma potrzeby niestandardowego repo !!

I odkomentuj linię:

write_enable=YES

0

Prosta poprawka polega na zrobieniu tego, co sugeruje komunikat o błędzie: spraw, aby root nie był zapisywalny, a następnie, jeśli chcesz włączyć przesyłanie, utwórz podkatalog, który ma uprawnienia do zapisu. Nie wymaga zmian w konfiguracji.


0

Po 3 godzinach googlingu uruchomiłem Ubuntu 14.04.2 LTS VSFTPd 3. Folder domowy będzie widoczny / home / vimal po uzyskaniu dostępu do klienta. Zalogowałem się w Vimal z uprawnieniami roota. Mam utworzony folder ftpShare, ale nie ma on większego znaczenia.

sudo chown vimal:vimal /home/vimal/ftpShare/

kilka przydatnych poleceń:

sudo nano /etc/vsftpd.conf
sudo service vsftpd restart
sudo apt-get purge vsftpd
netstat -a | grep ftp
tcp        0        0        *:ftp         *:*        LISTEN
ftp://12.345.23.xxx/  for browser login

Powyżej oznacza, że ​​demon ftp działa

Mam następującą konfigurację:

seccomp_sandbox=no
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
chroot_list_enable=NO
secure_chroot_dir=/var/run/vsftpd/empty
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
allow_writeable_chroot=YES

Po uruchomieniu FTP możesz go dostosować do konkretnych potrzeb, niektóre z powyższych mają wartości domyślne, ale nie pamiętam dokładnie.

Błędy widoczne w kliencie FTP:

1. 500 OOPS: niepowodzenie prctl PR_SET_SECCOMP

Rozwiązanie.

seccomp_sandbox=no    

[dodaj go w pierwszym wierszu vsftpd.conf, po zakończeniu początkowej komentowanej sekcji]

2. 500 OOPS: vsftpd: odmowa uruchomienia z zapisywalnym rootem w chroot ()

allow_writeable_chroot=YES

Dodałem go w ostatniej linii.


0

Rozwiązałem problem odmowy vsFTPd odmowy działania z zapisywalnym rootem w chroot () na moim serwerze Ubuntu w następujący sposób:

Właśnie dodałem poniższy wiersz w vsftpd.confpliku:

allow_writeable_chroot=YES
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.