Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

Pora na ostatnią część naszego przewodnika budowy serwera FTP. Na koniec zostawiliśmy wprowadzenie zabezpieczenia w ProFTPD przed podstawową bolączką serwerów FTP - przesyłaniem haseł oraz innych danych otwartym tekstem.

Do tego zadania będziemy potrzebowali pakietu OpenSSL. Bez dodatkowych czynności jest on dostępny wraz z wersją serwerową CentOS. Jeżeli system instalowaliśmy jakiś czas temu, to warto tę paczkę zaktualizować:

# yum update openssl

Mając zainstalowany pakiet OpenSSL musimy przygotować certyfikaty, których później będzie używał ProFTPd do zabezpieczenia komunikacji. Stwórzmy najpierw katalog, w którym certyfikaty te będą przechowywane np. /etc/certy

# mkdir /etc/certy

Wszystkie pozostałe operacje będziemy wykonywali z poziomu tego właśnie katalogu. Najpierw generujemy klucz prywatny RSA szyfrowany algorytmem 3DES:

# openssl genrsa -des3 -out server.key 1024

Będziemy proszeni o wskazanie hasła do klucza prywatnego:

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

Klucz ten nie może być w żaden sposób nikomu udostępniany. Nie zaszkodzi, jeżeli hasło użyte do wygenerowania klucza będzie odpowiednio skomplikowane. Jeżeli mamy problem z wymyślaniem trudnych haseł możemy wesprzeć się darmowymi narzędziami takimi jak PWGen (http://pwgen-win.sourceforge.net). Lepiej też nie zapomnieć tego hasła. W przeciwnym wypadku, kiedy przyjdzie czas odnowienia certyfikatu będziemy musieli cały proces powtarzać od nowa.

Następnym krokiem jest wygenerowanie CSR-a (Certificate Signing Request) czyli niepodpisanej kopii certyfikatu. W CSR zawarte są takie dane jak klucz publiczny, dane występującego z prośbą o podpis

$ openssl req -new -key server.key -out server.csr

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

Mamy już wygenerowanego CSR-a. W normalnej sytuacji np. serwera produkcyjnego wysłalibyśmy taką prośbę do Urzędu Certyfikacji (CA) np. VeriSign czy Thawte. My jednak podpiszemy CRS-a samodzielnie, a nasz nowy certyfikat będzie ważny przez rok:

# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

W katalogu /etc/certy powinny znajdować się teraz trzy pliki: certyfikat serwera (server.crt), CSR (server.csr) i klucz prywatny (server.key). Aby wykorzystać nowy certyfikat w serwerze ProFTPd należy dodać kilka linii w pliku konfiguracyjnych /etc/proftpd.conf. W pierwszej kolejności włączamy silnik TLS:

TLSEngine on

Dalej określamy czy będziemy wymagali połączenia szyfrowanego podczas łączenia z serwerem. Jeżeli dodamy ten parametr globalnie wówczas wszyscy użytkownicy będą musieli (lub też nie) nawiązywać połączenie szyfrowane. Nam zależy na bezpieczeństwie, a serwer nie będzie publicznie dostępny zatem będziemy wymagać szyfrowania:

TLSRequired on

W kolejnych dwóch liniach wskazujemy lokalizację certyfikatu serwera oraz jego klucza prywatnego:

TLSRSACertificateFile /etc/certy/server.crt

TLSRSACertificateKeyFile /etc/certy/server.key

Przyda się też wyłączenie uwierzytelniania klientów:

TLSVerifyClient off

Na koniec włączamy logowanie do pliku:

TLSLog /var/log/proftpd/tls.log

Teraz jeszcze tylko restart usługi i... Proszeni jesteśmy o hasło - hasło, które podaliśmy generując klucz prywatny:

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

Nie da się ukryć, że jest to pewna niedogodność. Możemy zrobić w tej sytuacji dwie rzeczy. Albo zaakceptować ten stan i za każdym razem, kiedy podnoszona jest usługa mozolnie wpisywać hasło (pełne bezpieczeństwo), albo skopiować zabezpieczony hasłem klucz w bezpieczne miejsce, a następnie zdjąć z /etc/certy/server.key hasło.

Decydując się na ten drugi krok koniecznie trzeba jakoś zabezpieczyć klucz prywatny przed modyfikacjami oraz odczytem przez nieuprawnionych użytkowników. Dostęp do tego pliku powinien mieć tylko "root". Cała operacja powinna wyglądać tak:

Najpierw wykonujemy kopię klucza prywatnego:

[root@ftp certy]# cp server.key /kopie/

Następnie zdejmujemy hasło z oryginału:

[root@ftp certy]# openssl rsa -in server.key -out server.key.ftp

I usuwamy plik server.key. Wprowadzamy też małą modyfikację w pliku konfiguracji ProFTPd zamieniając linię:

TLSRSACertificateKeyFile /etc/certy/server.key

Na

TLSRSACertificateKeyFile /etc/certy/server.key.ftp

Wreszcie zmieniamy uprawnienia na pliku "odhasłowanego" klucza prywatnego tak, aby był on możliwy do odczytania tylko z poziomu root-a.

[root@ftp certy]# chmod 400 server.key.ftp

Od tej pory nie będziemy już w momencie restartu usługi proszeni o podanie hasła do klucza prywatnego.

Ostatnim krokiem jest przetestowanie tego, czy faktycznie w momencie łączenia wymuszane jest szyfrowanie. Trzeba też znaleźć klienta FTP, który będzie taki tryb obsługiwał. Bardzo dobrym i sprawdzonym jest FileZilla Client (http://filezilla-project.org/download.php?type=client). Podczas konfigurowania połączenia z serwerem należy tutaj wskazać tryb FTPES

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

i powinniśmy otrzymać komunikat z informacjami o wygenerowanym niedawno certyfikacie oraz pytaniem czy możemy mu zaufać:

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

Jeżeli będziemy próbowali łączyć się z serwerem poprzez niezabezpieczoną sesję FTP operacja ta zakończy się niepowodzeniem:

Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia

***

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200