Linux - usługi - niepotrzebne demony...

Usługi - niepotrzebne demony, bezpieczne połączenia

Usługi - ich udostępnianie to zasadnicze zadanie serwera, lecz nie należy oferować zbyt wiele :-), im skromniej, tym bezpieczniej.
Większość usług jest uruchamiana przez demona inetd, wywołanie niektórych znajduje się w skryptach startowych znajdujących się zazwyczaj w katalogu /etc/rc.d (sam demon inetd - w systemie Red Hat - jest uruchamiany przez skrypt /etc/rc.d/init.d/inet). Każdy ze sposobów uruchamiania usług ma swoje zalety, jak i wady. Usługi uruchamiane poprzez demona inetd (czyli uruchamiane na żądanie) są wykorzystywane tylko wtedy, kiedy są potrzebne. Z drugiej jednak strony system może zostać obciążony ciągłym uruchamianiem usługi, która jest często potrzebna. Uruchomienie demona danej usługi podczas startu systemu zmniejsza obciążenie serwera związane z ciągłym uruchamianiem potrzebnej usługi, jednak jeśli usługa nie jest w danej chwili wykorzystywana, to i tak ciągle demon zajmuje zasoby komputera.
Uruchomiony podczas startu demon inetd pracuje w tle oczekując na sygnały z portów sieciowych. Gdy taki sygnał pojawi się na porcie związanym z daną usługą, inetd uruchamia żądaną usługę. Chcąc wyłączyć usługi, które są uruchamianie przez inetd, wystarczy w pliku /etc/inetd.conf postawić znaczek # na początku linii zaczynającej się nazwą niepotrzebnej usługi, np.:

# shell stream tcp nowait root /usr/sbin/tcpd in.rshd
# login stream tcp nowait root /usr/sbin/tcpd in.rlogind
# telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

Następnie należy zrestartować demona inetd:

/etc/rc.d/init.d/inet restart

O tym, czy wprowadzone zmiany odniosły skutek, możesz się dowiedzieć wydając polecenie:

netstat -l

Program netstat wyświetli wówczas listę usług aktualnie udostępnianych przez Twoją maszynę.

No tak, ale które usługi są niepotrzebne? Oczywiście te, z których nie korzystasz, lub te, które są na tyle niebezpieczne, że nie warto z nich korzystać. Do najbardziej niebezpiecznych należą wszystkie usługi zaczynające się od literki r (rsh, rexec, rcp, rlogin...). Wspomnę tylko, że generalnie wszystkie te usługi można zastąpić programem ssh, więc nie ma chyba czego żałować.
W następnej kolejności powinieneś wyłączyć: finger (udostępnia informacje o użytkownikach systemu), echo, daytime, discard, chargen, tftp (umożliwia pobieranie plików bez autoryzacji), nntp (serwer news), smpt (zdalne zarządzanie serwerem), telnet (koniecznie zainstaluj ssh!), systat oraz netstat (informacje o systemie i sieci), talk, ntalk, printer... Oczywiście niektóre z tych usług będziesz chciał udostępniać, lecz zwróć wtedy szczególną uwagę na aktualizację poszczególnych programów lub spróbuj zastosować inne rozwiązania wspomagające bezpieczeństwo podczas korzystania z tych usług.

Jeżeli dany program nie jest uruchamiany poprzez inetd, lecz jest wywoływany podczas startu systemu ze skryptu startowego w katalogu /etc/rc.d/, to aby go wyłączyć musisz po prostu usunąć jego wywołanie. Możesz to zrobić albo poprzez usunięcie odpowiedniego pliku (zazwyczaj będzie to link symboliczny do właściwego skryptu uruchamiającego) lub poprzez postawienie znaczka # we wszystkich liniach odpowiedzialnych za start danego programu w konkretnym pliku. W systemie Red Hat możesz to także uczynić korzystając z programu ntsysv lub linuxconf, co znacznie ułatwia tą czynność.

I jeszcze kilka słów o samych usługach od strony bezpieczeństwa.
W przypadku ftp, www, smtp, pop3, czyli standardowych usług, bez których nie można się wprost obejść, połączenia nie jest kodowane tak, jak ma to miejsce przy wykorzystaniu programu ssh - wszystkie komendy wysyłane są jawnym tekstem! Istnieje więc prawdopodobieństwo przechwycenia poleceń wydawanych podczas transmisji (nie jest to łatwe, ale możliwe!). Problem ten można rozwiązać m.in. poprzez "postawienie" tzw. tunelu wykorzystując bezpieczne połączenie, które oferuje program ssh. Rzecz polega na tym, iż dany program zamiast nawiązywać połączenie z konkretnym hostem, nawiązuje je z lokalnym serwerem na jakimś porcie, na którym czuwa ssh. Ssh przekazuje dane z tego połączenia do demona ssh na serwerze, z którym chcemy się połączyć, a na nim z kolei demon ssh przekazuje otrzymane połączenie na żądany przez nas port. Proste, prawda? W praktyce jednak nie zawsze jest to takie łatwe do zrobienia...

Www (http) nie należy do najbezpieczniejszych i to zarówno pod kątem jawności przesyłanych danych, jak też możliwości uruchamiania np. skryptów CGI, jak i SSI. Należy zadbać o to, aby serwer www nie był uruchamiany pod UID roota - na ogół nie jest to potrzebne! Również należy ograniczyć możliwość korzystania z programów CGI, zezwalając jedynie na wykonywanie określonych skryptów lub określonym użytkownikom. Jeśli serwer nie jest uruchamiany z prawami roota, nie jest już wymagane tak restrykcyjne podejście w stosunku do skryptów uruchamianych przez użytkowników, choć nadal należy zachować ostrożność - trzeba wykluczyć możliwość ustawienia bitu SUID na uruchamianych programach!. Bezpieczną alternatywą podczas wykorzystywania połączeń http jest użycie shttp, czyli połączenia realizowanego przy wykorzystaniu SSL (Secure Socket Layer). SSL jest protokołem bezpiecznej komunikacji opracowanym przez Netscape i zapewniającym prywatność, autoryzację i integralność przesyłanych danych. Jest oparty o grupę instytucji certyfikujących (CA), a korzystając z serwera legitymującego się certyfikatem jednego ze znanych CA możemy mieć pewność, że serwer jest właśnie tym, za który się podaje. Obecnie wszystkie już przeglądarki mają możliwość korzystania z shttp.

Jak już wcześniej mogłeś przeczytać, proponuję, by zastąpić sendmaila (najpopularniejszego programu do realizacji usługi smtp) innym programem do obsługi poczty (Postfix, qmail, ZMailer... - możliwości jest naprawdę wiele. Zajrzyj chociażby na Freshmeat i wybierz coś dla siebie!) Należy także zadbać o to, by nasz serwer nie był źródłem spamu; usługa rozsyłania listów nie może być dostępna dla każdego! Musisz wyłączyć funkcję "open-relaying" w Twoim programie obsługi poczty.

Pop3 również oferuje transmisję nie kodowaną, lecz możesz temu zaradzić używając tunelu przez ssh lub serwera i klienta pop3 wykorzystującego SSL.
Ftp może zostać również poprowadzone przez tunel przy wykorzystaniu ssh (trochę trzeba się jednak przy tym napracować: tryb passive, dwa porty do tunelowania... :-)) lub można po prostu wykorzystywać sftp - czyli bezpieczne ftp oferowane przez ssh, czy też program scp, który ma zastosowanie przy przesyłaniu plików do, czy też ze swojego konta na zdalnej maszynie, np.:

scp plik/na/Twoim/dysku user@serwer:/katalog/na/zdalnym/serwerze

spowoduje skopiowanie pliku z Twojego dysku do katalogu na serwerze, przy czym cała transmisja jest szyfrowana!
Jeśli na swojej maszynie udostępniasz usługę ftp i masz zainstalowany pakiet ssh2, to godnym polecenia klientem na platformę Windows jest Secure FX - naprawdę bardzo przyjemnie korzysta się z tego narzędzia (pomijając wrażenia związane z używaniem samego systemu Windows :-)), albowiem nie ma potrzeby "zabawy" w tworzenie tuneli dla ftp - odbywa się to automatycznie!
Ponadto w przypadku ftp także istnieje możliwość wykorzystania SSL, jednak tak jak w przypadku pop3 wymaga to odpowiedniego wsparcia zarówno po stronie klienta, jak i odpowiedniego serwera ftp.
Jeśli na swoim serwerze wykorzystujesz popularnego wu-ftpd, to proponuję Ci, byś zamienił go na np. Proftpd - jest bezpieczniejszy i to nie tylko dlatego, że jest mniej powszechny. Jednak idealne pod tym względem programy i tak nie istnieją...

Na koniec kilka słów prawdy: możliwość wykorzystania tunelu przez ssh dla połączeń usług, których komendy standardowo przesyłane są w sposób jawny a oferowanych użytkownikom często staje się nierealna ze względu na brak odpowiedniego oprogramowania po stronie klienta lub innych czynników, jak np. łatwość obsługi.
Jednak jeśli łączą się ze sobą dwie maszyny unixowe, gdy pracujesz zdalnie na serwerze, który jest pod Twoją opieką - wykorzystanie tunelu nie stanowi tak wielkiego problemu, a z całą pewnością wpłynie na poprawę bezpieczeństwa.

<<< powrót do strony głównej