Własny i bezpieczny serwer FTP - cz.3 - Zabezpieczenia
20 listopada 2007 16:16
Patryk Królikowski
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:
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 (
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
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 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:
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 (
filezilla-project.org/download.php?type=client). Podczas konfigurowania połączenia z serwerem należy tutaj wskazać tryb FTPES
i powinniśmy otrzymać komunikat z informacjami o wygenerowanym niedawno certyfikacie oraz pytaniem czy możemy mu zaufać:
Jeżeli będziemy próbowali łączyć się z serwerem poprzez niezabezpieczoną sesję FTP operacja ta zakończy się niepowodzeniem:
***
AudioBot - odsłuchaj materiał
wydrukuj
wyślij do znajomego
odpowiada...