P

rofesjonalny demon FTP posiada duże możliwości konfiguracji i składnię przypominającą plik konfiguracyjny serwera Apache. Obok demona Wu-FTP może pochwalić się szeregiem opcji niedostępnych w większości innych demonów ftp, w tym limitami dyskowymi, wirtualnymi serwerami i budową modularną pozwalającą na pisanie własnych modułów. Mimo, że jego dokładna konfiguracja może wymagać od nas większej uwagi (choć standardowa postać jego pliku konfiguracyjnego zapewnia już dość wysoki poziom bezpieczeństwa) serwer ten uważany jest za najbezpieczniejszy (korzystają lub korzystały z niego takie serwisy jak sourceforge.net oraz kernel.org).

Przesyłanie plików jest niezwykle istotne dla funkcjonowania systemu Linuksowego (o ile założenia danej komunikacji sieciowej nie wymagają korzystania z protokołu przesyłania plików – zaleca się wykluczenie możliwości korzystania z tej usługi). Decydując się na serwer FTP należy pamiętać, że w większości serwerów FTP wykorzystywana jest standardowa autoryzacja oparta na identyfikatorze użytkownika i haśle. Serwer nie może, więc z całą pewnością stwierdzić, że użytkownik jest tym, za kogo się podaje. Domyślnie hasła przesyłane są w postaci niezakodowanej. Pozwala to na założenie podsłuchu i przechwytywanie haseł, w dodatku także sesje FTP nie są szyfrowane, tym samym nie oferując prywatności. Gdy jednak funkcjonowanie serwera FTP jest koniecznością, istnieją różne jego metody ochrony. Postaram się omówić szerzej kilka sytuacji oraz sposobów zabezpieczenia demona proftpd (założenia dotyczące samego protokołu File Transfer Protocol określono w dokumentach RFC 0765, 0959, 2228, 2389). Sytuacje te głównie będą się tyczyć:

– zmiany komunikatu powitalnego – ponieważ zaleca się zmianę komunikatu wyświetlanego przez demon FTP bezpośrednio po nawiązaniu połączenia. Zależnie od stosowanego programu, ujawnić on może osobom niepowołanym: typ demona, wersję, platformę systemową jak i inne istotne dane.
– ograniczenia połączeń FTP – z którym wiąże się stosunkowo niebezpieczne zjawisko m.in. atak typu DoS. Standardowo, wiele programów określa tę wartość jako dość wysoką. Przy jej modyfikowaniu należy zachować roztropność. Przelicznikiem tej wartości może być poważne zastanowienie się ile połączeń dany serwer faktycznie jest w stanie obsłużyć.
– uprawnienia – bardzo ważną kwestią jest ścisłe określenie dla każdego użytkownika jego praw umieszczenia na serwerze i pobierania plików, jak również uprawnień dotyczących poszczególnych plików i katalogów.

Cały proces zaczynamy od pobrania najnowszych źródeł demona z serwera ftp.proftpd.org. Po ich pobraniu rozpakowujemy je poleceniami (w dystrybucji Slackware ProFTPD jest standardowym serwerem FTP w tej dystrybucji, który jest już skompilowany do formy gotowego do zainstalowania pakietu tak, więc tak samo można go pobrać z serwera ftp.slackware.com z sekcji N – etwork):

gunzip proftpd-1.2.9.tar.gz
tar -xvf proftpd-1.2.9.tar
rm proftpd-1.2.9.tar
cd proftpd-1.2.9

Następnie określamy szczegóły kompilacji programu za pomocą skryptu “configure” poprzez dodanie do niego odpowiednich opcji wywoławczych powodujących zmianę jego standardowych ustawień. ProFTPD instalowany jest standardowo w katalogu /usr/local/sbin/, jego składowe programy (ftpcount i ftpwho) w /usr/local/bin, plik konfiguracyjny w /usr/local/etc/ oraz strony manualne i pliki stanowe odpowiednio w /usr/local/man/, i /usr/local/var/proftpd/:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-shadow --with-modules=mod_readme:mod_ratio:mod_tls:mod_wrap
make
make install

Opisując poszczególne opcje: –prefix – określa ścieżkę gdzie zostanie zainstalowany program – w naszym przypadku /usr/sbin; –sysconfdir – położenie pliku konfiguracyjnego, czyli /etc/proftpd.conf; –localstatedir – w tym przypadku określamy położenie plików .log oraz .pid; –enable-shadow – wymuszamy używania mechanizmu szyfrowanych haseł; –with-modules – wymieniamy dodatkowe moduły, jakie mają być uwzględnione podczas instalacji programu. Wszystkie moduły znajdujące się w katalogu /modules po rozpakowaniu programu są standardowymi modułami, które zostaną wkompilowane w program chyba, że sami zdecydujemy o ich dezaktywacji (./configure –help). Dodatkowe moduły, które podlegają możliwości instalacji znajdują się w katalogu /contrib. Każdy z nich oferuje nam różne możliwości rozszerzenia samych możliwości programu ProFTPD. Np. moduł TLS umożliwia nam kryptografię transmisji plików na podstawie szyfrowania SSL i certyfikatów generowanych właśnie w tym standardzie, moduł wrap oferuje autoryzację na podstawie biblioteki TCP Wrapper. Więcej informacji na temat możliwości oraz opcji każdego z modułów znajdziemy w ich dokumentacji (jeśli skorzystaliśmy z pakietowej wersji proftpd listę wkompilowanych modułów możemy uzyskać poprzez wydanie komendy: proftpd -l). Skoro mamy już proces instalacji za sobą możemy przejść do samej konfiguracji serwera. Na samym początku skopiujemy dotychczasowy plik konfiguracyjny, a sami stworzymy nowy krok po kroku zawierając w nim użyteczne opcje, które będą wydawać się nam potrzebne:

cp /etc/proftpd.conf /etc/proftpd-standard.conf
echo "" > /etc/proftpd.conf

Poniżej zawarte opcje są ustosunkowane do wydajnością serwera. Chodzi głównie o ilość możliwych połączeń, obsługiwanych użytkowników oraz czasu bezczynności. Każdą z tych opcji należy dostosować do własnych potrzeb mając na uwadze możliwości własnej maszyny oraz łącza. W poniższym przykładzie nie zostało uwzględnione logowanie za pomocą konta anonymous, które umożliwia dostęp do serwera każdej osobie łączącej się zewnątrz. Jeśli pragniemy udostępnić taką usługę należy bezwzględnie przestudiować opcje pozwalające na ograniczony zapis czy odczyt plików na serwerze. Warto wspomnieć, że konta anonymous są 90% powodem udanych włamań na serwery FTP spowodowanych złą konfiguracją tego konta. Pozostałe 10% wynika z samych, wewnętrznych błędów oprogramowania. Powracając do tematu konfiguracji – zaczynamy oczywiście od edycji pliku oraz umieszczaniu w nim danych opcji:

ServerName "NARF Inc. FTP Server"

Określamy nazwę naszego serwera. W nazwie nigdy nie należy podawać nazwy oprogramowania oraz jego wersji.

ServerAdmin hostmaster@nfsec.org

Określamy adres kontaktowy z administratorem systemu – czyli nasz własny (należy usunąć spacje).

ServerType standalone

Określamy tryb uruchomienia serwera. Opcja standalone pozwala nam na niezależność demona ftp od innego np. inetd, w ten sposób jesteśmy w stanie kontrolować go jako osobny proces, a co za tym idzie – mamy możliwość nakładania na niego własnych ograniczeń względem połączeń.

Bind 217.25.72.175

Określamy adres, a tym samym interfejs, na którym ma nasłuchiwać serwer FTP. Opcja jest ta szczególnie przydatna, gdy np. serwer WWW, który jest aktualizowany przez pracowników łączących się wyłącznie z sieci lokalnej – wtedy nie mamy potrzeby udostępniania serwera FTP dla całego Internetu, lecz tylko dla danej sieci lokalnej wpisując w tej opcji adres wewnętrznego interfejsu, czyli podłączonego do sieci lokalnej. Jeśli posiadamy łącze stałe, lecz z dynamicznym adresem IP, należy nie uwzględniać tej opcji w pliku konfiguracyjnym – co spowoduje nasłuch na wszystkich możliwych interfejsach, a blokadę nie potrzebnych połączeń z kolejnych adresów możemy przeprowadzić za pomocą zapory sieciowej lub TCP Wrappers.

DeferWelcome on

Zezwalamy na komunikat powitalny dopiero po autoryzacji przez danego użytkownika.

DefaultServer on

Określamy by standardowa konfiguracja serwera była używana podczas przyjmowania wszystkich połączeń.

RequireValidShell on

Do poprawnej autoryzacji użytkownik musi posiadać przyznaną powłokę wylistowaną w pliku /etc/shells. Jeśli takowej nie posiada logowanie nie powiedzie się. Mechanizm ten pozwala nam na szybką blokadę dostępu do usługi FTP poprzez zmianę powłoki użytkownika.

ServerIdent on "NARF Inc. FTP Server Ready."

W tej opcji zmieniamy komunikat powitalny FTP. Zaleca się zmianę komunikatu wyświetlanego przez demon FTP bezpośrednio po nawiązaniu połączenia (w celu uniknięcia ataku typu banner grabbing). Zależnie od stosowanego programu, ujawnić on może osobom niepowołanym typ demona, wersję, platformę systemową i inne istotne dane. Standardowa konfiguracja pozwala w samej próbie połączenia uzyskać kilka podstawowych informacji: typ demona FTP i jego wersję. Potencjalnemu agresorowi nie pozostaje nic prostszego jak przejrzeć listę powszechnie znanych wad stosowanego programu (jeśli takie istnieją) i rozpocząć ich wykorzystywanie.

AccessGrantMsg "Welcome %u - your transfer is logged."

Definiujemy kod wiadomości 230 – oznajmiający użytkownikowi poprawne logowanie oraz ostrzegamy go, że jego poczynania w naszym systemie są monitorowane.

AccessDenyMsg "Login incorrect. Access denied for %u."

Definiujemy kod wiadomości 530 – oznajmiający użytkownikowi niepoprawne logowanie do serwera FTP.

Port 21

Nakazujemy nasłuch demona na porcie o numerze 21 według przyjętych międzynarodowych standardów. W przypadku, gdy pragniemy, aby nasz serwer w ogóle nie używał praw administratora (co jest dobrym pomysłem), wtedy należy podać port powyżej wartości 1025 – oraz dodać opcję RootRevoke on. W przypadku, gdy opcja ta zostanie zastosowana, a serwer będzie nasłuchiwał na porcie mniejszym niż 1025, czyli standardowo 21’rwszym – spowoduje to dezaktywację trybu aktywnego przesyłu danych pozostawiając tylko dostępny tryb pasywny (używany przez przeglądarki korzystające z adresów typu: ftp://). Decydując się na ten krok warto także dodać opcję: Passive Ports 49152 65534.

Umask 022

Ustalamy maske / standardowe prawa dostępu z jakimi będą tworzone nowe pliki oraz katalogi (więcej na temat praw dostępu możemy dowiedzieć się z artykułu “prawa dostępu do plików i katalogów”).

MaxInstances 15

Określamy maksymalną, dopuszczalną liczbę procesów, demona FTP, która może być uruchomiona na naszym systemie. Dzięki tej dyrektywie możemy ustrzec się przed atakami typu DoS, ograniczając zużycie serwera względem usługi FTP. Warto wspomnieć, że z limitem ilości połączeń FTP wiąże się dość ciekawe zagrożenie. Standardowo, może określać ono tę wartość jako stosunkowo wysoką. Dlatego przy jej modyfikowaniu, warto zachować zdrowy rozsądek. Przede wszystkim warto rozważyć ile strumieni połączeniowych nasz serwer faktycznie potrafi obsłużyć.

MaxLoginAttempts 2

Ilość nieudanych prób logowań, po których serwer zerwie z klientem łączność. Maksymalną wartością jaka może być w tym polu przyznana nie powinna przekraczać wartości 3, ze względu na możliwość próby ataku brute force.

MaxClients 10 "Server is full. Please wait."

Definiujemy maksymalną ilość klientów mogących naraz korzystać z serwera FTP. Wartość ta jest uzależniona od ilości posiadanych użytkowników w naszym systemie oraz ich gwarantowanym dostępie do konta przez FTP.

MaxClientsPerHost 2 "Two clients per one host only."

Określamy maksymalną ilość klientów mogących naraz korzystać z serwera FTP łącząc się z tego samego hosta docelowego. Jeśli udostępniamy serwer FTP wyłącznie komputerom pochodzącym z sieci lokalnej możemy prezentowaną wartość obniżyć do wartości jedynki będąc pewnym, że każdy komputer z sieci posiada jednego użytkownika przypadającego na nasz serwer FTP. W innym przypadku może się zdarzyć się z serwera, który jest autoryzowany do naszego serwera FTP konto posiada dwóch lub więcej użytkowników, którzy posiadają oficjalny dostęp do naszej maszyny. W tym przypadku należy odpowiednio zwiększyć powyższą wartość.

MaxClientsPerUser	2 "Download And Upload - And What?"

Jeśli posiadamy obawy, że zbyt duża ilość użytkowników z danego hosta może łączyć się z naszym serwerem to opcja ta pozwala na wprowadzenie limitu polegającego na określeniu maksymalnej, dopuszczalnej liczby połączeń przypadających na jednego użytkownika. Nadając jej wartość 1 – zmuszamy danych użytkowników do ściągania lub umieszczania plików z / na serwer. Jeśli posiadamy szybkie łącze oraz wydajny sprzęt serwerowy możemy umożliwić im wykonywanie tych czynności na raz poprzez nadanie tej wartości 2.

TimeoutIdle 120

Definiujemy przedział czasowy, w ciągu którego serwer przerwie połączenie jeśli w ciągu danej wartości czasowej nie zostanie odnotowana żadna aktywność ze strony użytkownika. Wartość ta określana jest w sekundach, czyli w naszym przypadku 2 minuty.

TimeoutLogin 60

Dyrektywa ta określa maksymalny w jakim użytkownik ma prawo do przeprowadzenia procesu logowania. Moim zdaniem jedna minuta to bardzo dużo czasu – szczególnie dla osób wstukujących 200 parę znaków na minutę, lecz nawet osoby dopiero uczące się pisania na klawiaturze powinny zmieścić się w tym przedziale.

TimeoutNoTransfer 180

Opcja określająca przedział czasowy, w którym użytkownik zobowiązany jest określić wszystkie zmienne (tryb i rodzaj przesyłu itp.) włącznie z lokalizacją pliku, który będzie pobierał / wysyłał z / na serwer. Standardowo opcja ta posiada wartość 300’stu sekund. Jednak należy się zastanowić czy wartość ta jest prawidłowa skoro nie prowadzimy żadnego serwera FTP z ogromem danych, które wymagają czasu by je przeszukać i znaleźć cel wizyty na serwerze FTP? Użytkownik logujący się na serwer FTP powinien posiadać sprecyzowany cel, do którego osiągnięcia powinny mu wystarczyć 3 minuty by przeszukać swoje dane.

TimeoutSession 86400 users !agresor,!firedoll

Ostatnim czasomierzem serwera jest określenie czasu całej sesji FTP. Zakładając, że na serwerze operuje się nie dość dużymi plikami – możemy ograniczyć czas trwania sesji do jednego dnia. Oczywiście zdarzają się wyjątki tak, więc z ograniczeń zwalniamy małą grupę użytkowników, którzy potrafią ściągać całymi dniami zapychając nasze łącze.

User ftp
Group ftp

Nakazujemy demonowi proftpd by po zakończeniu niezbędnych czynności wymagających praw administratora porzucił jego uprawnienia przyjmując prawa zwykłego użytkownika (ftp). Takie postępowanie daje nam gwarancje, że osoba która w jakiś sposób złamała zabezpieczenia serwera FTP nie przejmie całkowitej kontroli nam systemem jak to by miało mieć miejsce w przypadku, gdy serwer by działał z uprawnieniami administratora. Dlatego na tą okazję należy stworzyć użytkownika ftp, który będzie posiadał zablokowane konto (passwd -l ftp lub wstawiamy “*” w drugim polu pliku /etc/passwd odnoszącym się do tego konta) oraz brak możliwości logowanie się do systemu (jego powłoką powinno być pseudo urządzenie /dev/null lub /bin/false).

SystemLog /var/log/proftpd
TransferLog /var/log/xferlog
ExtendedLog /var/log/ftpsnif
ExtendedLog /dev/tty7
PidFile /var/run/proftpd.pid
ScoreboardFile /var/run/proftpd.scoreboard

Określamy położenie plików dziennika, w których zapisywane będą informacje dotyczące połączeń z naszym serwerem FTP, przesyłaniem plików (wysyłaniem oraz ściąganiem) pomiędzy klientem, a serwerem oraz poszczególne komendy, których użyli użytkownicy przebywając zalogowani przez usługę FTP. Przed ostatnia linijka wymienionych opcji dotyczy miejsca, gdzie zostanie zapisany plik posiadający numer procesu przyznanego ProFTPD w celu jego identyfikacji w systemie. Ostatni wpis ustawia położenie pliku gdzie nasz demon będzie przechowywał informacje na temat aktualnych sesji. Plik ten jest niezbędny dla poprawnego działania dyrektywy MaxClients jak i takich narzędzi jak ftpwho i ftpcount, które potrafią dostarczyć nam informacji w czasie rzeczywistym o osobach działających na serwerze FTP.

DefaultChdir ~
DefaultRoot ~

Powyższe dwie opcje określają pole na jakim uprawniony użytkownik jest w stanie działać w systemie przy pomocy usługi FTP. Pierwsza z nich określa katalog, do którego zostanie przeniesiony użytkownik zaraz po zalogowaniu się do systemu – tylda określa jego domowy katalog. Druga opcja powoduje uwięzienie go w tym katalogu tym samym izolując go od innych krytycznych zasobów systemu jak i innych użytkowników – tym samym powodując, że jego działania będą tylko i wyłącznie tyczyły się jego konta systemowego. Są to bardzo przydatne opcje powodujące brak możliwości poruszania się po systemie użytkownika jak to ma miejsce w przypadku zwykłego zalogowanie się do powłoki.

RootLogin off

Opcja ta nawet jeśli by nie została zawarta w pliku konfiguracyjnym pozostaje pod taką postacią standardowo. Więc czemu ją tu wstawiać? By mieć podwójną pewność? Też. Ale stanowi dobry pretekst by wytłumaczyć, że zezwalając na możliwość jakiejkolwiek akceptacji do sieciowego zezwolenia logowania administratora popełniamy wielki błąd. Opcja ta po wpisaniu poprawnego loginu i hasła użytkownika root – proftpd nie pozwoli na jego zalogowanie. Nawet w przypadku włączenia tej opcji w tryb On – nasz demon za pomocą programu syslog prześle odpowiednią adnotacje do logów systemowych.

DefaultTransferMode binary

Jest to raczej opcja udogadniająca niż mająca wpływ na bezpieczeństwo serwera. Określona ona po prostu standardowy tryb przesyłania plików poprzez serwer FTP (bin – binarny ; ascii – tekstowy).

DeleteAbortedStores on

Jest to bardzo przydatna konfiguracja związana z zadbaniem zajętości dysku. Podczas wrzucania większego pliku na serwer, czasami może się zdarzyć, iż pomyliliśmy pliki lub zmieniliśmy zdanie – w tym celu anulujemy tzw. upload (do serwera przesyłana jest komenda ABOR). Część pliku który przez ten czas został wrzucony pozostaje na serwerze zajmując miejsce. Po zakończeniu tej operacji należy odczekać na przerwanie połączenia; ponowne odczytanie i wyświetlenie aktualnej zawartości katalogu. Po uaktywnieniu tej opcji nasz serwer FTP automatycznie będzie kasować fragmenty plików z niedokończonych sesji – przez co po rozmyśleniu się możemy nie martwiąc się o nic zerwać zupełnie połączenie z serwerem.

HiddenStor on

Opcja powiązana z jej poprzedniczką. Mamy już zabezpieczenie przed niedokończonymi transferami, ale jak się zabezpieczyć przed możliwością używania pliku dopiero po jego całkowitym transferze? Właśnie poprzez wyżej wymienioną opcję. Zakładając przypadek, w którym strona internetowa korzysta z systemu nowości – najnowsze informacje dotyczące aktualnego dnia są właśnie umieszczane na serwerze – plik jest w 50% przegrany – i w tym samym czasie użytkownik odwiedza stronę w celu przeczytania dzisiejszych wydarzeń – ku jego zdziwieniu jeden z artykułów kończy się w 1/3 długości. By temu zapobiec należy uaktywnić bezpieczny upload. Powoduje on zapisywanie pliku podczas jego transferu w postaci: “.in.nazwa_pliku” – i dopiero w momencie jego całkowitego i ukończonego powodzeniem umieszczenia na serwerze – zmienia jego nazwę na oryginalną. W ten sposób nasz system newsów – który oczywiście posiada sprawdzanie przed wyświetleniem artykułu czy dany plik istnieje poinformuje, odwiedzającego użytkownika, iż artykuł jest jeszcze nie gotowy.

MaxRetrieveFileSize 25 Mb group users
MaxRetrieveFileSize *
MaxStoreFileSize 25 Mb group users
MaxStoreFileSize *

Stos opcji określających maksymalny rozmiar pobieranego (retrieve) / wysyłanego (store) pliku. W powyższym wypadku ograniczamy tylko grupę użytkowników (users), reszta grup i należących do nich użytkowników nie posiada żadnych ograniczeń (*). Ograniczenia możemy określać poprzez jednostki od Gigabajtów (Gb) po Mega (Mb); Kilo (Kb), a nawet poszczególne bajty (B). Dodam tylko, że przelicznikiem limitu może być 55% – 70% objętości konta, ponieważ dwa pliki po 50% każdy zmieszczą się na serwerze, jednak 2 x 55% – już nie – dlatego najlepiej przed tym doświadczeniem uchronić użytkowników którzy posiadają jeszcze jakieś złudzenia.

TransferRate RETR 25.0:204800 group !vipusers
TransferRate APPE,STOR 30.0:204800 group !vipusers

Wprowadzamy limity zużycia łącza. Pierwszy wpis tyczy się pobierania plików z serwera, a jego interpretacja jest następująca: wszyscy oprócz grupy użytkowników – vipusers (! – pełni rolę negacji – czyli wszyscy oprócz) – będą mogli pobierać małe pliki (do 200 Kb – 200b x 1024 = 204800) – z maksymalną prędkością aktualnie oferowaną przez cały serwer – jeśli plik będzie posiadał większą pojemność od 200 Kb serwer ograniczy transfer do 25 Kb/s. Drugi wpis posiada tą samą regułę, lecz odnosi się ona do umieszczania plików na serwerze, oraz limit w przypadku większych plików wynosi 30 Kb/s. Jeśli chcemy zastosować limity do tylko jednej grupy użytkowników – wystarczy usunąć znak “!” oraz wpisać nazwę danej grupy.

DisplayConnect /etc/issue.net

Jest to mały zabieg kosmetyczny związany z poinformowaniem użytkowników łączących się z naszym serwerem FTP. W pliku issue.net, w którym zapisana jest informacja dotycząca ogólnie serwera – możemy umieścić info o możliwości uwierzytelniania tylko przez powołane osoby, w ten sposób ostrzegając przypadkowych wizytantów o rezygnacji z połączenia. Plik issue.net może zawierać przykładową treść:

Welcome to The Network Server:
Unauthorized Access Prohibited 
---

Do pliku issue.net możemy także odwołać inne demony oferujące wyświetlanie banerów ostrzegawczych np. OpenSSH – w ten sposób nie będziemy musieli tworzyć osobnych plików o identycznej zawartości.

ListOptions "+a"

Normalnie do komend FTP listujących zawartość katalogów możemy dodać parametry, które decydują jakie pliki mają być wyświetlone, a jakie nie. Poprzez dodanie do powyższej dyrektywy opcji “+a” powodujemy, że parametr listujący wszystkie pliki, nawet te ukryte będzie ignorowany, czyli po wydaniu komendy: ls -a – zawsze będzie ona traktowana jako zwykła komenda: ls – w ten sposób ukryte pliki systemowe nie będą widzialne dla użytkownika.

<Directory />
  AllowOverride off
  HideNoAccess on
<Limit CWD PWD LIST>
  IgnoreHidden on
</Limit>
</Directory>

Kończący naszą standardową konfigurację stos opcji. Pierwszy wpis tyczy się przeszukiwania plików .ftpaccess w katalogach użytkowników. Pliki te regulują dostęp do serwera FTP (tak samo jak pliki .htaccess w Apaczu tak tutaj .ftpaccess). W standardowej konfiguracji opcja ta jest zezwolona. Jednak radzę ją wyłączyć, ze względu na to, że użytkownicy nigdy nie powinni decydować o zezwalaniu na jakiekolwiek połączenia (nawet jeśli tyczą się one wyłącznie ich kont) – unikniemy w ten sposób możliwości odblokowania naszych restrykcji połączeń wprowadzonych na cały serwer. W przypadku wyjątku od reguły możemy zastosować wpis: AllowOverride on login_użytkownika – w ten sposób zezwalając pojedynczemu, a zarazem naprawdę zaufanemu użytkownikowi możliwość zezwalania oraz odmawiania połączenia z jego kontem FTP. Kolejna opcja – HideNoAccess – powoduje ukrywanie przed użytkownikami katalogów, do których nie posiadają dostępu (mają brak praw dostępu lub w ogóle nie są ich właścicielami). W ten sposób możemy dokładnie zinterpretować powiedzenie – czego oczy nie widzą tego dusza nie pragnie. Ostatnia opcja odnosząca się do limitu przy użyciu komend listingu oraz operacji na aktualnym katalogu jak i jego zmianie – powoduje ignorowanie wyświetlania plików ukrytych, czyli tych zaczynających się od “.” np. .bash_history. Jeśli dane konto zostało stworzone dla potrzeb strony www lub przechowywania plików programowych – nie ma potrzeby zajmowania ekranu użytkownika plikami konfiguracyjnymi jego konta, do którego nie posiada dostępu (lub jeśli posiada to może pliki te skonfigurować poprzez używanie nadanej mu powłoki).

Pozostaje nam teraz tylko blokada innych – systemowych kont, by nie zostały one wykorzystane do celów próby logowania przez serwer FTP. W tym celu wystarczy ich identyfikatory systemowe w formie loginów wprowadzić do pliku /etc/ftpusers. Dla przykładu mogą to być takie konta jak:

www
nobody
mail
pop
root
ftp
oidentd
ssh

  Na koniec wspomnę tylko dla tych zainteresowanych, którzy bardzo pragną posiadać konto anonymous (dostępne publicznie – choć jeszcze raz przypominam – jeżeli połączenia anonimowe muszą być dostępne, wymagana jest niezwykła dbałość o ustawienia uprawnień dostępu do plików i katalogów) – niech zainteresują się następującymi opcjami: Anonymous, AllowFilter, AnonRejectPasswords, DirFakeMode, DirFakeUser, DirFakeGroup i GroupOwner, a także dokładnie przeanalizują przykładowy plik konfiguracyjny dla tego konta dostarczony wraz ze źródłami lub dokumentacją (w zależności od tego czy posiadamy wersję pakietową) ProFTPD. Dobrym pomysłem by było także stworzenie osobnej partycji dyskowej na te cele lub nawet umieścić “anonimową” usługę FTP na jednym systemie, który nie zawiera żadnych poufnych danych i który będzie umieszczony na zewnątrz sieci firmowej. Bardzo dobrą alternatywą jest zastąpienie publicznego FTP dobrze skonfigurowanym serwerem Apache, który może symulować serwer FTP oraz udostępniać publicznie wybrane pliki oraz katalogi. Po zakończeniu jakiejkolwiek konfiguracji polecam uruchomienie serwera ProFTPD na pierwszym planie z odpowiednim poziomem debugowania pracy, co pozwoli na analizę pracy i ewentualne poprawienie błędów: proftpd -n -d 5

Bonus:  Poniżej postaram się przedstawić dwa sposoby na uzyskanie prostego poza systemowego (innego niż /etc/passwd) źródła autoryzacji dla serwera FTP. Pierwszą z nich będzie prosta konfiguracja, która pozwoli na odizolowanie użytkowników od naszego systemu oraz pozwoli na nadanie im zupełnie innego hasła niż posiadają przy używaniu powłoki – oto ona: Na początek przed sekcją <Directory /> musimy dodać opcję określającą, skąd ProFTPD ma odczytywać dane o audytucie użytkowników:

AuthUserFile /etc/ftp/ftpd.passwd
AuthGroupFile /etc/ftp/ftpd.group 

Jak sami widzimy, określają one miejsce podstawowych plików autoryzacji zawierających informacje o grupach oraz użytkownikach. Następnie by nie tylko hasła naszych użytkowników były inne, ale także ich loginy użyjemy mechanizmu aliasów w celu zmiany ich loginów dla serwera FTP:

AuthAliasOnly on
UserAlias wingzero agresor 

Jest to pojedynczy przykład, lecz aliasy należy stworzyć dla wszystkich użytkowników korzystających z serwera FTP (format: alias login). W przypadku, gdy ktoś podsłucha naszą transmisję – login i hasło – będzie on posiadał tylko dostęp poprzez FTP – dość duża izolacja względem systemu zostanie zachowana. Kolejnym krokiem jest stworzenie fizycznych potwierdzeń dokonanej konfiguracji. Do kontynuacji tej czynności będą nam potrzebne źródła ProFTPD rozpakowane do głównego katalogu root (jak tego dokonać opisano wyżej) – ponieważ będziemy wykorzystywali w tych pracach narzędzie dostarczone przez TJ Saunders’a o nazwie ftpasswd (program ten wymaga wsparcia języka Perl).
Zaczynamy od utworzenia podstawowych plików oraz katalogów (komendy wydajemy z macierzystego katalogu root):

mkdir /etc/ftp
chown root:ftp /etc/ftp
chmod 770 /etc/ftp
cp proftpd-(wersja)/contrib/ftpasswd /etc/ftp
cp /etc/group /etc/ftp/ftpd.group
cd /etc/ftp
chown ftp:ftp ftpd.group
chmod 660 ftpd.group

Po przygotowaniu gruntu pod działkę możemy zacząć dodawać użytkowników. By zachować kompatybilność z prawami systemowymi użytkownika, musimy sklonować jego preferencje z wpisu znajdującego się w pliku /etc/passwd. Posłuży nam do tego komenda: cat /etc/passwd|grep login – gdzie login – jest to odpowiedni użytkownik, który ma posiadać konto FTP. Należy pamiętać by dodać wszystkie osoby, które mają mieć możliwość korzystania z usługi FTP – oczywiście z pewnością możemy pominąć tych, którzy posiadają u nas tylko usługę poczty. W powyższych komendach kopiujemy plik z wpisami grup – jeśli zaszły jakieś w oryginalnym pliku systemowym – bezzwłocznie należy go uaktualnić. Po odczytaniu odpowiednich wartości możemy dodać pierwsze konto użytkownika:

echo /bin/false >> /etc/shells
./ftpasswd --passwd --name=agresor --uid=1000 --gid=100 --home=/home/of/agresor --shell=/bin/false

Po wydaniu ostatniej komendy program po prostu spyta się nas o hasło. Hasło jest standardowo szyfrowane poprzez funkcję MD5. Zostanie stworzony plik ftpd.passwd – posiadający taką samą strukturę jak dawny plik passwd – czyli będą w nim przechowywane zaszyfrowane hasła oraz informacje odnośnie kont użytkowników. Dlatego teraz zadbamy by tylko demon ProFTPD miał prawa do jego odczytu i zapisu – tak samo jak takie prawa posiada administrator (root) do pliku shadow (więcej informacji jak usuwać oraz dodawać czy modyfikować za pomocą narzędzia ftpasswd dowiemy się z pliku ftpasswd.html):

chown ftp:ftp ftpd.passwd
chmod 600 ftpd.passwd

Jeśli nasz serwer FTP został uruchomiony z innym identyfikatorem użytkownika niż ftp (lecz jest to także zwykły użytkownik), oczywiście należy podstawić odpowiednie wartości w wiersze komend, gdzie jest używany identyfikator demonstrujący np. jeśli zdecydowaliśmy się na użytkownika “nobody” wtedy zamiast wpisów z użyciem “ftp” używamy swojego “człowieka”. Druga metoda uwierzytelniania poza systemowego wykorzystuje bazę danych SQL (MySQL i PostreSQL). By uzyskać taki efekt wystarczy skompilować demona ProFTPD z modułem mod_sql – uwzględniając poprzednie moduły:

./configure --with-modules=mod_readme:mod_ratio:mod_tls:mod_wrap:mod_sql:mod_sql_mysql --with-includes=/usr/local/mysql/include --with-libraries=/usr/local/mysql/lib

Oczywiście, należy podać ścieżkę do swojej instalacji serwera MySQL, jeśli nie jest to katalog /usr/local/mysql – pomocną tutaj może być komenda: whereis mysql. Następnie kompilujemy i instalujemy kod poprzez komendy: make i make install. Przyszła kolej na utworzenie bazy danych, z której ma korzystać demon proftpd (serwer MySQL musi być już zainstalowany oraz sprawnie działać) – musi ona mieć dostęp w trybie tylko do odczytu z naszego demona FTP:

mysqladmin create proftpd
mysql -e "grant select on proftpd.* to proftpd@localhost identified by 'secret';"

Po dokonaniu tych czynności tworzymy dwie tabele w bazie danych o danych schematach. Zapiszemy je w pliku proftpd.tables: poprzez komendę touch proftpd.tables, a następnie edytujemy go za pomocą ulubionego edytora np. nano proftpd.tables – i wpisujemy do niego dwie następujące tabele:

CREATE TABLE users (
userid varchar(30) NOT NULL default '',
password varchar(30) NOT NULL default '',
uid int(11) default NULL,
gid int(11) default NULL,
homedir varchar(255) default NULL,
shell varchar(255) default NULL,
UNIQUE KEY uid (uid),
UNIQUE KEY userid (userid)
) TYPE=MyISAM;

CREATE TABLE groups (
groupname varchar(30) NOT NULL default '',
gid int(11) NOT NULL default '0',
members varchar(255) default NULL
) TYPE=MyISAM;

Teraz należy dodać te tabele do naszej bazy danych poprzez polecenie: mysql proftpd < proftpd.tables. Teraz tak samo jak w poprzednim przypadku należy poinformować demon ProFTPD, że ma korzystać z bazy danych do uwierzytelniania użytkowników. Tak więc dodajemy następujące wiersze do /etc/proftpd.conf przed sekcją <Directory />:

SQLConnectInfo proftpd proftpd secret
SQLAuthTypes crypt backend
SQLMinUserGID 100
SQLMinUserUID 1000

Wiersz SQLConnectInfo posiada konstrukcję: “nazwa_bazy_danych login hasło”. Jeśli chcemy sobie jeszcze bardziej pobiegać po komputerach możemy użyć bazy danych pochodzącej z innego serwera naszej sieci: SQLConnectInfo proftpd@bazadanych.nfsec.org:port login hasło. Wiersz SQLAuthTypes pozwala utworzyć użytkowników z hasłami zapisanymi w standardowym uniksowym formacie lub w formacie funkcji MysQL: PASSWORD(). Dlatego należy pamiętać, że przy korzystaniu z funkcji logowania modułu MySQL trzeba zabezpieczyć logi, w których mogą pojawić się hasła w postaci tekstu czytelnego. Opcja SQLAuthTypes zabrania używania haseł pustych (empty). Ostatnie dwa wiersze, czyli SQLMinUserGID i SQLMinUserUID określają minimalny identyfikator grupy i użytkownika, który demon ProFTPD ma dopuszczać do logowania. Musimy pamiętać, aby to była wartość większa od zera (aby zapobiec możliwości logowania użytkownika root), lecz powinna być niska, ponieważ potrzebne są właściwe uprawnienia w systemie plików. W systemie Slackware mamy grupę users posiadającą GID = 100 oraz pierwszy dodany użytkownik posiada UID = 1000. Ponieważ użytkownicy ci powinni móc logować się z tymi uprawnieniami, musimy ustalić minimalne wartości jako 100 i 1000. Teraz możemy dodać pierwszego użytkownika do bazy danych. Poniższe polecenie utworzy użytkownika agresor, z prawami użytkownika jego samego i grupy users. Po poprawnym zalogowaniu do systemu, będzie on skierowany do katalogu /home/of/agresor:

mysql -e "insert intro users values ('agresor',PASSWORD('enterFTP'),'100','1000',
'/home/of/agresor','/bin/false');" proftpd

Hasło użytkownika agresor jest szyfrowane funkcją PASSWORD() serwera MySQL przed zapisaniem. Wiersz /bin/false jest przekazywany do demona ProFTPD w celu przesłania dyrektywy RequireValidShell (patrz wyżej) demona FTP. Oczywiście nie ma to żadnego związku z przyznaniem faktycznego dostępu do interpretera poleceń użytkownikowi. Pokazane tutaj możliwości modułu MySQL to tylko mała demonstracja. Moduł ten ma większe horyzonty – może on m.in. łączyć się z istniejącymi bazami danych MySQL z dowolnymi nazwami tabel, rejestrować całą aktywność w bazie danych, modyfikować wyszukania użytkowników dowolną klauzulą WHERE.

Więcej informacji: ProFTPd Docs, Proftpd, Mod_SQL