Wiadomości
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 (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
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 (http://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:
***
# 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 (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
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 (http://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:
***
Komentarze (1)
hej, Jeśli bezpieczny serwer FTP wynika tylko i wyłącznie z używania bądź nie używania SSL''a to nie mam pytań... Nie wspomnieliście nic o pozostałych aspektach pracy proftpd - ograniczanie dostępu.... limity transferów... limity zasobów systemowych... itp... Pozdrawiam, m.
- Skanery WiFi na platformę Android
- Prawo Moore’a zagrożone?
- Bezpieczeństwo WiFi - bezprzewodowe testy penetracyjne
- Wirtualizacja: obsługa SMB na czterech U
- Prawdziwe powody powstania Microsoft Open Technologies
- MDT 2012: Microsoft aktualizuje Deployment Toolkit
- Open source: zmierzch ery GPL? Nie do końca...
- ROVER - prosty sposób na słabość BGP?
- Zaawansowane stacje Wi-Fi Ruckus Wireless
- Rozstanie z Javą nie będzie proste
Reklama
Huawei celuje w rynek biznesowy
Huawei nieustannie rozwija się jako dostawca infrastruktury dla branży telekomunikacyjnej. W tym roku chiński koncern zamierza umocnić swoją pozycję również na rynku rozwiązań Enterprise.
Polecane
Koniec Windows XP początkiem problemów?
Microsoft oficjalnie potwierdził, że za dwa lata definitywnie zakończy się era Windows XP - systemu operacyjnego,...
Spokój i luz administratora
Wymagania wobec pracowników działów IT rosną proporcjonalnie do stopnia rozwoju teleinformatyki. Oczekuje się, że...