5. ZABEZPIECZANIE USŁUG SIECIOWYCH Na ogół przez zabezpieczenie usługi sieciowej rozumiane jest zabezpieczenie działania serwera jednego z protokołów warstwy.

Prezentacja na temat: "5. ZABEZPIECZANIE USŁUG SIECIOWYCH Na ogół przez zabezpieczenie usługi sieciowej rozumiane jest zabezpieczenie działania serwera jednego z protokołów warstwy."— Zapis prezentacji:

1 5. ZABEZPIECZANIE USŁUG SIECIOWYCH Na ogół przez zabezpieczenie usługi sieciowej rozumiane jest zabezpieczenie działania serwera jednego z protokołów warstwy zastosowań (na przykład HTTP, SMTP, DNS). Nie należy jednakże zapominać, że: - ważne jest zabezpieczanie nie tylko serwerów, ale i klientów usług (na przykład przeglądarek internetowych, które mogą być nakłonione przez obcy serwer do wykonania przekazanego programu lub ujawnienia danych); - nie wszystkie usługi opierają się w swoim działaniu bezpośrednio na protokołach warstwy transportowej (TCP lub UDP) – niektóre opierają się na protokołach pośrednich, które również należy zabezpieczyć; - oddzielnym zagadnieniem jest zabezpieczanie usług przeznaczonych dla sieci lokalnych, które oparte są na innych, niż IP, protokołach warstwy trzeciej (na przykład dawne rodzime protokoły Microsoft lub Novell Netware).

2 Poniżej zostanie przedstawiona problematyka zabezpieczania kilku najbardziej typowych usług dostarczanych przez serwery umieszczone w hoście bastionowym. Usługi te powinny być w miarę możności odseparowane od siebie. Możliwości: a) umieszczenie serwerów oddzielnych usług na oddzielnych maszynach fizycznych (najdroższe, a jednocześnie najbezpieczniejsze i najbardziej zalecane rozwiązanie w warunkach dużego natężenia ruchu w sieci); b) umieszczenie serwerów oddzielnych usług na oddzielnych maszynach wirtualnych osadzonych na wspólnym hoście bastionowym (rozwiązanie bardziej oszczędne, ostatnio coraz bardziej popularne wskutek rozwoju technologii maszyn wirtualnych); c) uruchomienie oddzielnych serwerów we wspólnym systemie operacyjnym hosta bastionowego, ale w możliwie odseparowanych środowiskach (typowy sposób: użycie polecenia chroot w systemach uniksowych w celu odseparowania od siebie fragmentów systemu plików używanych przez poszczególne usługi).

3 Zabezpieczanie usługi HTTP W najprostszym przypadku, kiedy serwer HTTP służy jedynie do udostępniania statycznych stron domowych, jego zagrożenie jest nieduże (głównie związane z atakami typu DoS, którym trudno jest zapobiegać). Należy tylko uważać, aby serwer nie udostępniał żadnych innych informacji poza tymi, które zostały do tego przeznaczone. Na podstawie [E. Zwicky i in.] można podać zestaw reguł, które powinny być przestrzegane przy konfiguracji serwera HTTP: - uruchamiaj proces serwera z prawami zwykłego użytkownika, nie administratora systemu (zwykle w tym celu stwarzany jest fikcyjny użytkownik o nazwie www, nobody itp. – postaraj się zastosować nazwę trudniejszą do odgadnięcia); - maksymalnie ogranicz (przy użyciu odpowiedniego zastosowania praw dostępu do plików, polecenia chroot w Uniksie i ustawień w plikach konfiguracyjnych serwera) możliwości dostępu serwera do systemu plików. W szczególności unikaj (jeśli nie jest to niezbędne) prawa do wyświetlania zawartości katalogów. W przypadku systemu uniksowego przeanalizuj potrzebę umożliwienia serwerowi korzystania z dowiązań symbolicznych do plików i katalogów; - unikaj umieszczania poufnych informacji w systemie plików, w którym porusza się serwer HTTP (najlepiej nie umieszczaj ich wcale na danej maszynie fizycznej);

4 - ogranicz liczbę osób, które mają prawo publikować informacje przy użyciu serwera HTTP. Dla tych, którym przyznasz takie prawo, przeprowadź odpowiednie szkolenie; - w przypadku dużych ilości publikowanych materiałów wprowadź podział na serwery operacyjne i projektowe. Wdróż procedurę kontroli materiałów przed przenoszeniem ich z serwerów projektowych na operacyjne. Zagrożenie związane z używaniem protokołu HTTP znacznie rośnie, gdy używane są rozszerzenia tego protokołu. Rozszerzenia HTTP, służące do tworzenia dynamicznych (zależnych od bieżących danych) stron domowych, mogą być związane z: - wykonywaniem programów po stronie serwera (co może stanowić zagrożenie dla serwera); - wykonywaniem programów po stronie klienta (co może stanowić zagrożenie dla klienta). Przykłady technologii powodujących wykonywanie programów po stronie serwera: - SSI (Server-Side Includes – obecnie już prawie nie używana); - CGI (Common Gateway Interface – umożliwia wykonywanie po stronie serwera programu zewnętrznego będącego programem binarnym lub skryptem wymagającym zewnętrznego interpretera); - ASP (Active Server Pages – technologia opracowana przez Microsoft dla serwerów Windows);

5 - PHP (Personal Home Page – język skryptowy, który może służyć do tworzenia skryptów CGI, ale częściej jest zintegrowany z serwerem jako język programów wewnętrznych, aby zwiększyć wydajność wykonywania skryptów). Przykłady technologii powodujących wykonywanie programów po stronie klienta: - JavaScript (język skryptowy, nie spokrewniony z językiem Java, przeznaczony w dużym stopniu do obsługi interfejsu użytkownika w programach sieciowych korzystających z przeglądarki internetowej); - Java (język ogólnego użytku, kompilowany do kodu pośredniego, przeznaczonego do wykonywania przez maszynę wirtualną Javy działającą w środowisku izolowanym); - ActiveX (technologia opracowana przez Microsoft, służąca do przekazywania do przeglądarek internetowych binarnych obiektów wykonywalnych, przeznaczonych dla danego rodzaju procesora). Wśród czynników zwiększających zagrożenie klientów HTTP należy również wymienić cookies (ciasteczka) – nieduże porcje informacji (zwykle służące do identyfikacji klienta) umieszczane przez serwery HTTP w komputerze klienta w postaci małego pliku lub fragmentu pliku (w zależności od rodzaju przeglądarki).

6 Reguły postępowania w przypadku uruchamiania serwera HTTP udostępniającego dynamiczne strony domowe [E. Zwicky i in.]: - pamiętaj, że każdy program zewnętrzny uruchamiany przez serwer HTTP stanowi potencjalne zagrożenie dla systemu operacyjnego. Przejrzyj go starannie pod kątem: a) bezpieczeństwa operacji wprowadzania danych (aby nie groziło przepełnienie bufora); b) bezpieczeństwa wywołań funkcji bibliotecznych (aby nie groziło przejęcie praw użytkownika uprzywilejowanego). Przetestuj najpierw działanie programu w bezpiecznym środowisku projektowym; - używaj tylko tych programów zewnętrznych, które są rzeczywiście niezbędne. Uruchamiaj je z minimalnymi przywilejami; - na wszelki wypadek nie zakładaj, że programy te będą uruchamiane na użytek tylko tych stron domowych, które aktualnie przewidujesz; - starannie sprawdź położenie i prawa dostępu wszystkich plików, z którymi program może kontaktować się. Usuń wszystkie zbędne pliki. Oddzielne zagadnienie stanowi zabezpieczanie danych poufnych przekazywanych przez protokół HTTP (uwierzytelnienie, szyfrowanie, zabezpieczanie integralności – protokoły HTTPS i SHTTP).

7 Zabezpieczanie klientów protokołu HTTP również stanowi ważny problem. Główne źródła zagrożenia klientów (przeglądarek i komputerów, na których są wykonywane): - brak wymogu zabezpieczenia informacji poufnych wysyłanych przez klienta do serwera (powinien być stosowany bezpieczny protokół, zapewniający szyfrowanie, sprawdzanie integralności i uwierzytelnianie zarówno klienta wobec serwera, jak i serwera wobec klienta); - naiwne pobieranie przez użytkowników i instalowanie programów zewnętrznych rozszerzających funkcjonalność przeglądarki (wtyczek, ang. plug-in) pochodzących z niepewnych źródeł (należy uniemożliwić to zwykłym użytkownikom w sieci wewnętrznej); - naiwne pobieranie i uruchamianie plików zawierających skrypty wykonywane po stronie klienta (przeciwdziałanie: filtrowanie protokołu HTTP, ograniczanie możliwości przeglądarek); - odczytywanie ciasteczek (cookies) przez serwery HTTP, które nie są do tego upoważnione (nie są tymi serwerami, które zakładały ciasteczka) – jeśli to możliwe, przeglądarki powinny być skonfigurowane tak, żeby uniemożliwiały to. Zalecane jest przeprowadzenie szkolenia dla pracowników, które uświadomi im rodzaje zagrożeń związanych z używaniem przeglądarek i uzasadni ewentualne ograniczenia ich możliwości.

8 Zabezpieczanie usługi FTP Protokół FTP służy do przesyłania plików pomiędzy systemem plików klienta i systemem plików serwera (w obu kierunkach). Jest oparty na TCP i wykorzystuje dwa równoległe połączenia: do przesyłania poleceń i do przesyłania danych. Umożliwia uwierzytelnianie klienta, ale nie stosuje szyfrowania. Standardowym portem nasłuchu serwera jest port 21. Serwer FTP umożliwia dostęp w trybie użytkownika (związany z uwierzytelnieniem się klienta) oraz dostęp anonimowy (anonymous) do plików publikowanych (podobnie, jak serwer HTTP). Ze względu na brak szyfrowania (nazwa użytkownika i hasło również są przesyłane tekstem jawnym), dostęp w trybie użytkownika w ostatnich latach jest już bardzo rzadko stosowany i serwery FTP służą głównie do publikowania plików (na przykład aktualizacji oprogramowania). Przeglądarki internetowe mają prawie zawsze wbudowane klienty FTP i używanie ich jest zalecane (oprogramowanie przeglądarek jest zwykle częściej aktualizowane, niż oddzielnych klientów FTP, i jest przez to bardziej bezpieczne w użytkowaniu).

9 Protokół FTP może otwierać połączenie w jednym z dwóch trybów: zwykłym i pasywnym (passive). W trybie zwykłym (mniej zalecanym) klient otwiera dwa porty TCP po swojej stronie, z jednego z nich zgłasza się do portu TCP 21 po stronie serwera i informuje go o drugim z numerów. Serwer potwierdza zgłoszenie z portu 21 do pierwszego z portów klienta, a następnie otwiera połączenie ze swojego portu 20 do drugiego z portów po stronie klienta: Serwer FTP Klient FTP 20 (dane) 21 (polecenia) port1 (polecenia) port2 (dane) port2 OK TCP SYN TCP ACK (na podstawie [E. Zwicky i in.] ).

10 W trybie pasywnym (bardziej zalecanym) klient również otwiera dwa porty TCP po swojej stronie, z jednego z nich zgłasza się do portu 21 po stronie serwera i informuje serwer o zamiarze użycia trybu pasywnego. Serwer przysyła potwierdzenie wraz z informacją o numerze przydzielonego portu doraźnego po swojej stronie. Klient następnie inicjuje połączenie z drugiego ze swoich portów do podanego portu doraźnego po stronie serwera: Serwer FTP Klient FTP port s (dane) 21 (polecenia) port1 (polecenia) port2 (dane) PASV port s TCP SYN TCP ACK (na podstawie [E. Zwicky i in.] ).

11 Podstawowym problemem związanym z używaniem zwykłego trybu transmisji jest fakt inicjowania dodatkowego połączenia TCP przez serwer, a nie przez klienta: 1) filtr pakietów na wejściu do sieci klienta może (i powinien) być ustawiony tak, aby uniemożliwiać inicjowanie przychodzących połączeń TCP; 2) jeśli na wejściu do sieci klienta działa NAT, również uniemożliwia to nawiązywanie połączenia TCP z zewnątrz. Problem ten nie występuje w przypadku stosowania trybu pasywnego. Jeśli jego użycie jest z jakichś technicznych powodów niemożliwe, wyjściem może być: a) zainstalowanie pośrednika (proxy) FTP w hoście bastionowym; b) zastosowanie inteligentnego, stanowego filtru pakietów i / lub odpowiedniego NAT na wejściu do sieci klienta, aby był w stanie rozpoznawać (i uwzględniać) osadzone numery portów TCP w poleceniach klientów. Serwer anonimowego FTP należy zainstalować w hoście bastionowym i zabezpieczyć podobnie, jak sewer HTTP udostępniający statyczne strony domowe. Jeśli serwer FTP ma również służyć do przyjmowania plików („wrzutnia przesyłek”) od uprawnionych użytkowników z sieci zewnętrznej, dobrym sposobem może być utworzenie ukrytego katalogu (o nazwie „hasłowej”, niewidocznej z zewnątrz) i poinformowanie o niej jedynie upoważnionych do korzystania.

12 Zabezpieczanie usługi SMTP Protokół SMTP służy do dostarczania poczty elektronicznej do serwera pocztowego odbiorcy. Jest oparty na TCP i wykorzystuje port o numerze 25. Nie zapewnia uwierzytelniania ani szyfrowania. Jeśli użytkownik chce zapewnić poufność przesyłanych informacji, może stosować: - szyfrowanie poszczególnych przesyłek i załączników do nich (nadawca i odbiorca muszą mieć uzgodniony wcześniej sposób szyfrowania i wymienione klucze do szyfru); - w przypadku poczty wewnętrznej (na przykład wymienianej pomiędzy główną siedzibą firmy i jej filią) wymienianie jej przez zaszyfrowane łącze VPN (Virtual Private Network). Nie jest zalecane pozwolenie użytkownikom z sieci wewnętrznej na bezpośrednie tworzenie połączeń wychodzących SMTP (bez pośrednictwa hosta bastionowego). Przyczyny: - większe prawdopodobieństwo wysyłania poczty z nieprawidłowo uformowanymi nagłówkami; - możliwość ułatwienia działania „koniom trojańskim” starającym się przekazać na zewnątrz informacje przez wychodzące połączenia TCP kierowane do portu 25; - brak możliwości dzielenia poczty wychodzącej na pocztę wewnętrzną i pocztę zewnętrzną.

13 Zalecenia dotyczące konfiguracji serwera poczty elektronicznej: - przy użyciu odpowiednich wpisów w bazie danych DNS (rekordy MX – Mail Exchange) wymuś kierowanie całej poczty przychodzącej do serwera poczty w hoście bastionowym; - spowoduj, aby serwer poczty w hoście bastionowym: a) przekazywał w zwykły sposób przesyłki od hostów wewnętrznych do hostów zewnętrznych; b) przesyłki dla hostów wewnętrznych kierował nie do nich bezpośrednio, ale za pośrednictwem wewnętrznego serwera poczty; c) odrzucał przesyłki od hostów zewnętrznych do hostów zewnętrznych (nie pośredniczył w zewnętrznym przekazywaniu poczty); - spowoduj, żeby cała poczta wychodząca była wysyłana za pośrednictwem serwera w hoście bastionowym. Ponieważ zabezpieczenia hostów wewnętrznych (i świadomość ich użytkowników) mogą być niewystarczające, ważną rzeczą jest filtrowanie poczty w hoście bastionowym: - poczty przychodzącej (pod kątem wirusów i innego złośliwego oprogramowania oraz niechcianych treści – spam); - poczty wychodzącej (aby móc w porę wykryć problemy zaistniałe w sieci wewnętrznej).

14 Zabezpieczanie usługi DNS Głównym zadaniem usługi DNS jest zamiana nazw internetowych na adresy IP (usługa ta udostępnia również informacje o serwerach pocztowych oraz, opcjonalnie, inne informacje o obsługiwanej strefie). Zasadniczo serwery DNS przyjmują zapytania przez port UDP 53 (jest też możliwe wysyłanie zapytań do portu TCP 53, choć port ten głównie służy do przyjmowania żądań transferu strefy od wtórnych serwerów DNS). Informacja udzielana przez serwer DNS może mieć różnoraki charakter: - odpowiedź autorytatywna (na podstawie własnych danych zapisanych przez administratora strefy); - odpowiedź nieautorytatywna (na podstawie danych uzyskanych od serwera innej strefy w ramach wyszukiwań rekurencyjnych i przechowywanych w granicach czasu ich ważności); - przekierowanie do serwera innej strefy (w ramach wyszukiwań nierekurencyjnych); - transfer strefy (przekazanie kompletu przechowywanej informacji przez główny serwer DNS strefy serwerowi wtórnemu).

15 Podstawowe zagrożenia działania usługi DNS: - atak typu DoS (w celu czasowego uniemożliwienia dostępu do serwera DNS lub jego zawieszenia); - przepełnianie bufora (wysyłanie zbyt długich zapytań do serwera DNS); - dostarczanie serwerowi fałszywych informacji (niektóre starsze serwery mogą przyjmować rzekome odpowiedzi na nie zadane wcześniej zapytania rekurencyjne); - nieuprawnione spowodowanie transferu strefy (podszycie się pod serwer wtórny); - wyłudzanie przez hosty zewnętrzne od serwera DNS informacji, która powinna być dostępna jedynie dla hostów w sieci wewnętrznej. Zalecenia dotyczące konfiguracji serwera DNS: - używaj tylko nowych wersji serwerów DNS, nie zawierających wykrytych błędów; - uruchom serwer DNS w hoście bastionowym tak, aby hostom zewnętrznym udzielał jedynie informacji o hostach świadczących usługi na zewnątrz; - ustaw reguły filtrowania w ruterze zewnętrznym tak, aby uniemożliwić transfer strefy na zewnątrz; - sprawdzaj odpowiedzi na zapytania rekurencyjne DNS metodą podwójnych zapytań odwrotnych; - sprawdź zawartość swojej bazy danych DNS, czy nie zawiera informacji nadmiarowych.