|
wersja 1.0 |
|
Spis treści |
Changelog 1. Dlaczego ? 2. Instalacja 3. Podstawy i pierdy 4. Anonimowi 5. Systemowi 6. Logowanie i timeout 7. Tylko tyle ? Posłowie |
| Changelog |
Zmiany od wersji 0.8: - dodano kilka drobiazgów do punktu nr 3,4 i 6 - testowa wersja vsftpd: 1.2.1 |
| 1. Dlaczego ? |
Odkąd człowiek zszedł z drzewa, szukał on sposobu na przesyłanie plików między komputerami. Opracowano protokół FTP a następnie masę serwerów do świadczenia tej usługi. Jak wybrać najbardziej odpowiedni ? Jestem przekonany, że vsftpd spełni oczekiwania 75% adminów. Jest on szybki, bezpieczny i prosty w konfiguracji.
Niestety, nie znalazłem ciekawego porównania z proftpd, tylko wzmianki o tym, że jest bardziej wydajny i szybszy (ciekawostka: binarka vs zajmuje cztery razy mniej miejsca od pro). Na pewno jest mniej od niego złożony: nie posiada tylu możliwości konfiguracyjnych - jest więc mniej funkcjonalny. Stąd bierze się moje przekonanie o 75%. Niektórych rzeczy nie da się tutaj po prostu zrobić. Uważam, że w większości zastosowań w zupełności wystarczy vsftpd. Do dzieła! |
| 2. Instalacja |
Rozpoczynamy tradycyjnie - od wizyty na stronie domowej i pobraniu źródeł programu: http://vsftpd.beasts.org Wspomnę tylko, że testuję wszystko na Slacku 8.0 i wersji 1.1.3 vsftpd. Kompilacja programu jest równie prosta jak jego konfiguracja (mam nadzieję, że w tym momencie nie dałem dupy ;) ): make make install Nie miałem problemów z kompilacją, Ty także nie powinieneś ich mieć. Nie ma sensu opisywanie szczegółowej kompilacji: nie ma na podstawie czego. Po prostu: albo się uda, albo nie. Strona domowa projektu nie rozpieszcza nas szczegółami na ten temat. A ja mam Slacka - tu chodzi wszystko. Jeśli nie udało się Tobie, "zainstaluj" binarkę. Albo Slacka. Albo napisz do mnie, jaki miałeś problem i jak go rozwiązałeś - pewnie przyda się to komuś. a) Potrzebujemy użytkownika, z którego prawami będzie działał "nadrzędny" serwer, który komunikuje się z klientem poprzez sieć. Oczywiście root odpada. Domyślnym użytkownikiem jest nobody jednak połowa softu na Twoim sprzęcie wykorzystuje tego nieszczęśnika. Dlatego też autor programu zaleca dodanie innego, nowego usera, który będzie działał po stronie serwera. Ja sobie utworzyłem użytkownika vsftp, otrzymał on shell /bin/false oraz dla pewności passwd -l vsftp. Mam więc nieszkodliwego usera do kontroli połączeń. Wazna uwaga - shell, ktory przydzielimy temu userowi powinien znalezc sie rowniez w spisie "waznych" shelli - w pliku /etc/shells. b) Potrzebujemy pusty katalog. Domyślie jest to /usr/share/empty. Prawdopodobnie go nie masz, więc go utwórz ( mkdir /usr/share/empty ). Możesz sobie wybrać inny, byle był on pusty oraz użytkownik ftp (zaraz o nim powiemy) nie miał do niego prawa zapisu. c) Potrzebujemy także użytkownika ftp. Jeśli go nie ma w Twoim systemie - dodaj wała. Katalog domowy użytkownika ftp będzie domyślnym / (root, katalogiem głównym) dla anonimowego ftp więc utwórz go w odpowiednim miejscu (w większości przypadków i tak będzie to /home/ftp). Oczywiście jego shellem może być /bin/false czy /dev/null i może on dostać passwd -l ftp. I jeszcze jedna ważna rzecz, takie małe dziwactwo: katalog domowy użytkownika ftp nie powinien należeć do niego. Co więcej, nie powinien mieć on prawa zapisu dla użytkownika ftp. W skrócie: chown root.root /home/ftp chmod go-w /home/ftp Założyłem oczywista, że /home/ftp to katalog domowy usera ftp. I jeszcze jedna ważna uwaga (podziękowania dla Darka T., SirRomana, Gerarda) dotycząca RedHata i innych systemów z zainstalowanym PAM. Aby umożliwić logowanie lokalnym użytkownikom należy skopiować plik vsftpd.pam z podkatalogu RedHat i umieślić go w /etc/pam.d/ jako plik o nazwie vsftpd. Jeśli nazwa PAMowa vsftpd nam nie odpowiada i wolelibyśmy np. "ftp", wtedy plik ten zapisujemy jako ftp i dopisujemy w głównym konfigu (o tym zaraz) opcje: pam_service_name=ftp. Z grubsza to wszystko, podsumujmy: - istnieje użytkownik vsftp, - istnieje pusty katalog /usr/share/empty, do którego użytkownik ftp nie ma prawa zapisu, - istnieje użytkownik ftp, który nie ma prawa zapisu do swojego katalogu domowego, co więcej, jego katalog domowy należy do roota. Jak pech, to pech... To by było na tyle. I nie pytaj mnie, komu bije dzwon. Zapytaj pliku INSTALL. Teraz tak: przygotujemy sobie program do uruchomienia a następnie stworzymy sobie jego plik konfiguracyjny. Od podstaw - choć domyślny jest dobrze opisany - lepiej wszystko pisać z palca, wyczaisz dużo więcej. Z dokumentów które przeczytałem wynika, że autor softu skłania się bardziej w kierunku (x)inetd, niż standalone. W tą stronę więc pójdziemy. Jeśli używasz inetd, zastanów się na xinetd. Na mojej stronie jest parę słów na ten temat. Dobra, zastanowiłeś się i zostajesz przy inetd: - otwórz plik /etc/inetd.conf - dopisz coś takiego: ftp stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/vsftpd oczywiście tcpd możesz mieć w innym miejscu albo możesz go nie mieć albo możesz go nie chcieć: wówczas wstaw tam ftp stream tcp nowait root /usr/local/sbin/vsftpd vsftpd - upewnij się, że tylko ta linijka zaczyna się od wyrazu "ftp", inne z nim na początku mają hash (#,krzyżyk). - przeładuj inetd, np. poprzez polecenie: kill -HUP `cat /var/run/inetd.pid` Oczywiście "apostrof" w powyższym poleceniu to ten, koło tyldy (~). Pewnie masz wrażenie, że piszę jak do idioty... przepraszam. Podejscie numer dwa, "windows style": żeby przeładować inetd zresetuj komputer ;). Jeśli masz xinetd wystarczy dopisać do /etc/xinetd.conf: service ftp { socket_type = stream wait = no user = root server = /usr/local/sbin/vsftpd } Możesz użyć także całego dobrodziejstwa, które niesie z sobą xinetd, np. ograniczenia ilości połączeń (wszystkich, z jednego adresu), ustalić godziny i adresy z których połączenia będą przyjmowane itp. Nie będę pisał jak to przeładować, nie mam siły a Ty i tak już to dawno zrobiłeś. A jak nie, to resetuj komputer :) Ten fragment zakończę stwierdzeniem: i tak jeszcze nie działa. Zaraz stworzymy sobie konfiga i będzie git. |
| 3. Podstawy i pierdy |
Na początek o podstawach. Tworzymy pusty pliki konfiguracyjny /etc/vsftpd.conf. Na początek umieszczamy w nim następującą treść: # dla demona eftepa nopriv_user=vsftp ftp_username=ftp secure_chroot_dir=/usr/share/empty # na razie nikogo nie wpuszczamy anonymous_enable=NO local_enable=NO Na początek kilka uwag: 1.Plik konfiguracyjny programu to seria opcja=wartość. Nie należy stawiać spacji ani przed ani po znaku "równa się". 2.Komentarze rozpoczynają się od znaku hash (#, krzyżyk) 3.Wartości opcji mogą być logiczne (YES/NO), numeryczne lub znakowe Omówmy ważne, podstawowe, powyższe cztery dyrektywy.
Dopisz do /etc/vsftpd.conf następujące rzeczy: # miłe powitanie łączących się klientów ftpd_banner="Czego tu szuka ?" # można ich też przywitać treścią pliku banner_file=/home/ftp/na_drzewo.txt Jeśli ustawione zostały ftpd_banner i jednocześnie banner_file (jak w naszym przypadku) wyświetlona zostaje treść pliku - a więc banner_file bierze górę. Kolejne drobiazgi (piszę o nich teraz, żebym później nie musiał do nich wracać). Często zdarza się tak, że chcemy aby po każdej zmianie katalogu przez klienta, wyświetlona została treść jakiegoś pliku (np. co znajduje się w tym katalogu). Aby uaktywnić wyświetlanie tych informacji należy posłużyć się dyrektywą dirmessage_enable. Domyślnie wyświetlana jest treść pliku .message z każdego katalogu. Aby zmienić jego nazwę, wykorzystujemy message_file. Jeśli w konfigu umieścimy następujące rzeczy: dirmessage_enable=YES message_file=.wypisz_mnie spowoduje to wyświetlenie treści każdego pliku .wypisz_mnie (o ile istnieje) z katalogu, do którego wszedł klient naszego serwera. No to jeszcze o dwóch interesujących opcjach. Działają one analogicznie więc nie będę się zbytnio tutaj produkował. Ich nazwy to: hide_file oraz deny_file. Już powinieneś wiedzieć o co chodzi. Pierwsza z nich ukrywa określone pliki z listingu (dir), druga natomiast nie pozwala pobierać określonych plików. Pierwsza z nich jest prymitywnym zabezpieczeniem typu "lepiej niech tego nie widzą", ponieważ pliki te można pobrać jeśli tylko zna się ich nazwę. Druga z nich to już bardziej poważna funkcja, nie pozwoli ona na pobranie określonych plików. A teraz wszystko się wyjaśni: # tu powinien być komentarz, ale sensu on by raczej nie miał hide_file={*.avi} deny_file={*.conf,.*_history,dupeczka_nr_??.jpg} |
| 4. Anonimowi |
vsftpd idealnie nadaje się na postawienie anonimowego serwera FTP. Oprócz zagwarantowania bezpieczeństwa i dużej wydajności pozwala on także ograniczyć szybkość z jaką pobierane są z niego pliki. Żeby nie przynudzać, przechodzę od razu do rzeczy. Oczywiście zmiany dokonujemy w pliku /etc/vsftpd.conf. Oto podstawowa treść, którą będziemy rozbudowywać: # ANONIMOWY SERWER FTP # opisane wcześniej nopriv_user=vsftp ftp_username=ftp secure_chroot_dir=/usr/share/empty local_enable=NO # dotyczące anonimowego anonymous_enable=YES no_anon_password=YES anon_world_readable_only=YES anon_upload_enable=NO hide_ids=YES anon_max_rate=7000
Wyglądający w ten sposób plik konfiguracyjny udostępnia anonimowym użytkownikom pliki zawarte w /home/ftp/. Pliki można tylko pobierać. Możesz dopisać do konfiga takie rzeczy jak powitanie i inne pierdoły opisane wcześniej. Kolejną możliwością, stosowaną znacznie rzadziej jest umożliwienie anonimowym użytkownikom umieszczanie plików przez ftp na naszym serwerze. Jest to tzw. upload. Aby toto umożliwić powinieneś nieznacznie zmodyfikować powyższy przykład: write_enable=YES anon_upload_enable=YES Pliki można umieszczać na naszym serwerze przez ftp, gdy utworzymy katalog z prawami zapisu dla użytkownika "ftp" (pamiętaj, że /home/ftp należy do roota i sam user "ftp" nie może do niego pisać). Załóżmy, że chcemy udostępnić katalog "wrzutki" do zapisu przez anonimowych użytkowników eftepa: mkdir /home/ftp/wrzutki chown ftp /home/ftp/wrzutki Powyższe wykonujemy jako root. Od tej pory w katalogu "wrzutki" można umieszczać anonimowo różnego rodzaju rzeczy. Teraz powstaje kilka innych możliwości, a oto kilka opcji, które mogą się przydać:
Dobra, zapytasz: po cholerę ta cała szopka ? A więc... Sorka, nie zaczyna się zdania od "a więc". Otóż masz parę możliwości, jak uploadowane będą pliki na Twój serwer. Na przykład możesz to zrobić w stylu "jesień średniowiecza" - wówczas każdy anonimowy może wrzucać pliki, każdy może je czytać, kasować, zmieniać nazwę itp. Generalnie oznacza to rozpiździel. Styl drugi to "kontrola wewnętrzna". Polega to na tym, że anonimowi mogą wrzucać pliki, lecz nie mogą ich pobierać. Dopiero gdy Ty, lub osoba zarządzająca uploadem stwierdzi, że pliki są o.k., udostępni je wszystkim eftepowiczom. Kolejny rodzaj to "złap mnie, jeśli potrafisz" - użytkownicy mogą wrzucać i pobierać pliki ale tylko wtedy, gdy znają ich nazwę. Chodzi w tym wszystkim o to, że zawsze masz pewne pole manewru. Oto najważniejsze fragmenty vsftpd.conf potrzebne do realizacji powyższych trzech scenariuszy.
Powyżej zaprezentowałem przykładowe problemy i przykładowe rozwiązania. Jednych i drugich jest zapewne o wiele więcej - wszystko zależy od Twojej wyobraźni. I jeszcze mały szczegół - przykłady pisałem "na szybkiego" i w taki sam sposób je testowałem. Jeśli znajdziesz jakieś bugi - daj znać. Znalazłem jeszcze jedną ciekawą opcję - dla naszego małego wareza :) Domyślnie pytamy anonimowych o hasło (zmienia to no_anon_password), ale życie pokazuje, że i tak to nie ma sensu. Może mieć jednak zastosowanie. Istnieje bowiem opcja secure_email_list_enable, która umożliwia wskazanie pliku. Plik ten zawiera spis adresów emailowych - innymi słowy haseł dla anonimowych użytkowników. Aby więc wpuszczać tylko niektórych anonimowych :), email wprowadzony przez nich musi być wymieniony na tej liście. W praktyce jest to więc plik z hasłami dla anonimowego użytkownika. Wspomniałem o warezie - oczywiście żartowałem ;). Ale po co zakładać kilku użytkowników lub dzielić się hasłem skoro można zrobić dostęp na anonimowego przy pomocy kilku haseł... Pozostali anonimowi nie zostaną po prostu wpuszczeni na eftepa: # w pliku znajduje sie lista emaili - hasel dla uzytkownika anonimowego secure_email_list_enable=YES email_password_file=/etc/ftp_anon.passwd Przepraszam za durną nazwę dla tego pliku ale jest już późno i nie mam siły wymyślać czegoś z sensem. Oczywiście składnia tego pliku jest tradycyjna: jedna linijka - jedno hasło (uważaj, żeby nie zrobić niepotrzebnych spacji). Myślę, że wystarczająco obrobiliśmy dupę anonimowym eftepowiczom. Jeśli wymyślisz jakieś inne, ciekawe rozwiązanie - podeślij je do mnie. Chyba wczoraj wypiłem o pare piw za dużo. Ide spać. Nara. |
| 5. Systemowi |
Witam ponownie. Tym razem zajmiemy się użytkownikami systemowymi (inaczej "lokalnymi"). Generalnie chodzi o to, żeby userzy (którzy mają konto na serwerze) mogli umieszczać na nim swoje pliki (np. swoją stronę www lub kopie bezpieczeństwa ważniejszych dokumentów). Oczywiście mamy kilka możliwości konfiguracyjnych, jednak zaczniemy od najbardziej podstawowej. Wyłączam także anonimowych użytkowników, żeby konfig był bardziej czytelny. # tu już wiemy o co chodzi nopriv_user=vsftp ftp_username=ftp secure_chroot_dir=/usr/share/empty # tylko systemowi anonymous_enable=NO local_enable=YES # prawo do uploadu write_enable=YES local_umask=0177 # limit szybkości local_max_rate=14000 Sprawa wygląda tak:
Przechodzimy do ciekawszych rzeczy. Pierwszą z nich jest fakt, że nie zawsze będziesz chciał dać możliwość wrzucania / pobierania plików wszystkim użytkownikom. Innymi słowy nasz serwer umożliwia zdefiniowanie listy użytkowników, którzy nie będą wpuszczeni przez FTP. # nich zadziała kontrola próbujących zalogować się userlist_enable=YES # tych, których nie wpuścimy definiujemy explicite userlist_deny=YES # trzymamy ich w określonym pliku userlist_file=/etc/vsftpd.user_list Komentarze powyżej mówią same za siebie. Plik userlist_file zawiera loginy osób (jedna nazwa użytkownika w jednej linii), którym zostanie odmówiony dostęp do swojego katalogu domowego poprzez FTP. Stanie się to po wpisaniu przez klienta loginu, bez pytania o hasło. Celem tego jest uniknięcie sytuacji, w której hasło jest niepotrzebnie przesyłane przez sieć. Na początek proponuję dopisać do listy użytkownika root, który domyślnie ma możliwość zalogowania się (dziwne...). Dobra, jeszcze jeden szczegół: w powyższy sposób definiujesz w pliku osoby, które nie mogą się eftepować. Jeśli natomiast chcesz odwrócić sytuację - czyli zalogować może się tylko ten, który ma wpis w powyższym pliku, wystarczy że zmienisz userlist_deny na NO (wówczas podany plik zawiera tylko tych, którzy mogą się eftepować, wszyscy inni nie). Chyba się powtarzam... Drugą ważną sprawą jest chroot (jail). Domyślnie wszyscy wpuszczeni przez vsftpd użytkownicy mogą się szwędać po całym dysku serwera (o ile prawa na to pozwalają). Oczywiście chcemy trzymać większość z nich jak najdalej takich katalogów jak np. /etc. Dlatego powinniśmy ich uwięzić w katalogu domowym tak, żeby nie mogli zejść niżej. Zróbmy to dla bezpieczeństwa naszego serwera, dla spokojnego snu admina i dla przyszłych pokoleń. Niech UID równy zero zawsze będzie z Tobą. # włączamy kontrolę chroot przez plik chroot_list_enable=YES # wara od /etc ... chroot_local_user=NO # ...wszystkim umieszczonym w poniższym pliku chroot_list_file=/etc/vsftpd.chroot_list Plik zdefiniowany przez chroot_list_file zawiera listę użytkowników (jeden login w jednej linii), którzy zamknięci zostaną w pierdlu, tzn. w swoim katalogu domowym. Nie będą mogli zejść niżej. Bo i po co ? No i jeszcze jedna rzecz - co zrobić żeby domyślnie wszyscy zamykani byli w domowym a plik definiował tych wolnych, bez ograniczeń ? Wystarczy zmienić wartość parametru chroot_local_user na YES. Teraz czas na małą popierdółkę. Pewnie zauważyłeś, że gdy zalogowany użytkownik ogląda, do kogo należą pliki (np. w jego katalogu domowym :) ) widzi cyferki (uid i gid). Aby zamiast tego widział właściciela plików wypisanego w cywilizowany sposób wystarczy w konfigu dopisać: text_userdb_names=YES Domyślnie jest NO, żeby mniej obciążać serwer. Ale przegięcie... Na koniec pozwolę sobie zaprezentować jeszcze jedną opcję programu - opcję, która umożliwia ustawienie konkretnej wartości jakiegoś parametru konkretnemu użytkownikowi. Chodzi o to, że definiując różne rzeczy, dotyczą one "wszystkich" użytkowników. A co, jeśli mamy równych i równiejszych ? Parametr ten to user_config_dir. Definiuje on katalog, w którym trzymane są pliki z wartościami różnych opcji dla konkretnych userów. Konkretnie: jeśli bardziej lubimy użytkownika mariola :) niż resztę możemy zwiększyć jej speeda (local_max_rate) lub na przykład zmienić maskę wrzucanych plików (local_umask). A wygląda to tak: user_config_dir=/etc/vsftpd_user_conf Taki wpis umieszczony w vsftpd.conf spowoduje, że serwer będzie szukał dla każdego systemowego użytkownika pliku /etc/vsftpd_user_config/[login]. Czyli jeśli zaloguje się mariola, nasz serwer będzie szukał pliku /etc/vsftpd_user_config/mariola. Możemy w nim umieścić indywidualne dla tego użytkownika wartości poszczególnych parametrów. Ot co. |
| 6. Logowanie i timeout |
W poprzedniej wersji tego dokumentu napisalem, ze nie jest to skomplikowane :) Hmmm..... # włączamy logowanie xferlog_enable=YES Jeśli chcemy logować zgodnie ze standardem wu-ftpd i większości analizatorów logów, ustawiamy: xferlog_std_format=YES xferlog_file=/var/log/xferlog.log Wszystko jasne - dla analizatora logów, ale doczytać się w tym pliku może tylko Webalizer. Opcja druga: czytelny zapis logów: xferlog_std_format=NO vsftpd_log_file=/var/log/vsftpd.log W ten oto sposób mamy albo czytelne logi, albo coś w czym tylko analizer(?) logów potrafi się połapać. Aby mieć jedno i drugie (2 pliki z logami) należy dodatkowo wywołać: dual_log_enable=YES W ten oto sposób mamy jedno i drugie. Jest jeszcze opcja syslog_enable, która ustawiona na YES powoduje, że te czytelne logi zamiast do pliku (vsftpd_log_file) trafiają do sysloga. Spróbuj teraz nad tym wszystkim zapanować - niezła zabawa... # A jeśli jeszcze Tobie mało i chcesz debugować klienta czy serwer # (i masz dużo miejsca na dysku), zmień poniższe na YES. # Działa z xferlog_std_format=NO log_ftp_protocol=NO Przejdźmy do timeoutów, czyli do czasu, po którym (bezczynny) klient zostanie przez serwer automatycznie rozłączony. Myślę, że nie ma tu zbyt wiele do wyjaśniania. Jednostkami są sekundy. # maxymalny czas bezczynności w oczekiwaniu na jakikolwiek ruch # ze strony klienta (komendy FTP, np. zmiana katalogu, # pobranie pliku), tutaj 5 minut. idle_session_timeout=300 # Maksymalny czas, przez który przesyłane dane, pliki mogą # "stanąć w miejscu", ang. to stall. Pozdrowienia # dla modemowców... data_connection_timeout=60 # Maksymalny czas na "dogadanie się" klienta z serwerem przed # przesyłaniem danych. Blokować może np. firewall. accept_timeout=30 Domyślnie vsftpd działa w trybie "pasywnym". Aby serwer działał w trybie "aktywnym" należy nadać wartość NO dla pasv_enable. |
| 7. Tylko tyle ? |
Hmmm... Wygląda na to, że to już koniec. Jak napisałem wcześniej, vsftpd nie jest zbyt rozbudowany. Wydaje mi się jednak, że to, co ma do zaoferowania wystarczy w większości przypadków. Może jeszcze kilka stwierdzeń:
|
| Posłowie |
Jest to pierwsza wersja tego dokumentu i zawiera pewnie jakieś błędy/niedoróbki/potknięcia itp. Będę bardzo wdzięczny za wszelkie uwagi, komentarze, poprawki, wyrazy wdzięczności. Z góry przepraszam za powyższe i mam nadzieję, że będziecie mnie informować w których miejscach coś nie gra. Jako (częściowe) wytłumaczenie przedstawiam fakt, że większość tej pracy powstawała w późnych godzinach nocnych. Ostatnia wersja tego dokumentu znajduje się pod niżej wymienionym adresem. Kontakt ze mną: linio@terramail.pl Wesprzyj finansowo autora - kliknij tutaj |
|
=============================== Henryk Liniowski, Poznań 2003 http://linio.terramail.pl =============================== |