W sieciach komputerowych przesyła się coraz większe ilości danych – plików tekstowych, binarnych, wiadomości e-mail, stron www czy też danych audio/video. Jednocześnie coraz większą wagę przypisujemy odpowiedniemu zabezpieczeniu tychże danych nie tylko podczas ich przechowywania na dyskach serwerów (uprawnienia NTFS, szyfrowanie EFS itp.), ale właśnie podczas ich transmitowania przez różnego rodzaju sieci – prywatne i publiczne, charakteryzujące się różnym poziomem zaufania i możliwością wystąpienia zagrożeń dla przesyłanych informacji.

Najczęściej spotykane zagrożenia związane z transmitowaniem danych w sieciach obejmują:

• możliwość przechwycenia przesyłanych pakietów sieciowych i zapoznania się z ich zawartością – a więc np. nieautoryzowana osoba może uzyskać dostęp do zawartości dokumentu, którego ze względu na brak uprawnień nie może otworzyć na serwerze;
• rzechwytywanie i dekodowanie haseł użytkowników – w przypadku protokołów takich jak POP3, IMAP lub TELNET hasło jest przesyłane w postaci jawnego tekstu, w wielu innych przypadkach (np. mechanizm uwierzytelniania NTLM) – hasło może zostać stosunkowo łatwo zdekodowane przez narzędzia opierające się o ataki słownikowe lub tzw. „brute-force”;
• podszycie się pod legalnego nadawcę lub odbiorcę – np. wyobraźmy sobie, że potencjalny intruz modyfikuje rekord A w usłudze DNS tak, aby wskazywał na inny niż autoryzowany serwer pocztowy – wówczas użytkownicy będą próbowali podłączać się do takiego fałszywego serwera i dokonując autoryzacji – pozostawiali na nim swoje hasła;
• celowa modyfikacja danych w trakcie ich przesyłu – jeśli pomiędzy nadawcą a odbiorcą danych pojawi się intruz – będzie mógł zmieniać zawartość transmitowanych pakietów i w ten sposób realizować ataki typu „DOS” lub kierować nadawcę pod inne, fałszywe adresy.

Zagrożeń podobnych do wymienionych powyżej jest wiele i trudno byłoby je wszystkie wymienić. Warto natomiast pomyśleć jak zabezpieczyć sieć przed tego rodzaju atakami przy pomocy narzędzi i technologii wbudowanych w Small Business Server.

Wykorzystamy tutaj protokół IPSec, który może być tak skonfigurowany, aby zapewnić realizację jednego z poniższych celów:

• szyfrowanie wszystkich transmitowanych pakietów pomiędzy dowolnymi dwoma węzłami w sieci – może to być połączenie pomiędzy stacją roboczą a serwerem lub też tunel tworzony pomiędzy dwoma urządzeniami typu „router”;
• szyfrowanie tylko wybranych protokołów lub konkretnych pakietów;
• podpisywanie cyfrowe i sprawdzanie integralności przesyłanych pakietów (aby nie mogły zostać zmodyfikowane w trakcie transmisji);
• uwierzytelnianie stron komunikujących się poprzez sieć (np. daje pewność, że do serwera podłączy się tylko autoryzowany klient);
• blokowanie wybranych protokołów lub pakietów.

IPSec jest protokołem całkowicie przezroczystym dla aplikacji, co pozwala nam wykorzystać go do zabezpieczenia dowolnych danych przesyłanych po sieci, niezależnie od tego, jaka aplikacja informacje wysyła a jaka odbiera. Założenia protokołu i ogólne zasady jego konfigurowania zostały opisane w dokumencie RFC nr 3585, który można znaleźć na stronie Internet Engineering Task Force.

Niezależnie od zakresu, w jakim będziemy chcieli wykorzystać IPSec musimy wybrać jeden z trzech dostępnych mechanizmów uwierzytelniania stron biorących udział w zabezpieczonej transmisji:

• KERBEROS
• CERTYFIKATY
• PRE-SHARED KEY (współdzielony klucz)

Domyślna konfiguracja IPSec w Small Business Server zakłada wykorzystanie mechanizmu uwierzytelniania KERBEROS – w takim przypadku każda ze stron dysponuje tzw. biletem uzyskanym od usługi KDC (Key Distribution Center), zawierającym klucz sesyjny dla obu stron, używany w fazie negocjacji (IKE) do zabezpieczenia głównego klucza kodującego (MASTER KEY). Wnikliwych czytelników zachęcam do lektury dokumentów dostępnych na stronie: Internet Authentication Service.

Administratorzy SBS powinni jednak wiedzieć, że IPSec może wykorzystywać mechanizm Kerberos tylko, jeśli zostaną spełnione poniższe warunki:

• wymagana jest synchronizacja zegarów systemowych klienta i serwera – rozbieżność czasu nie może przekroczyć 5 minut (dopuszczalny zakres tolerancji może być modyfikowany poprzez polityki zabezpieczeń);
• w systemie operacyjnym (na serwerze i stacji roboczej) musi być obecny tzw. IPSec AGENT – domyślnie jest on instalowany w systemach od Windows 2000 – dla wcześniejszych wersji (np. Windows 98) można pobrać odpowiedniego klienta ze strony: Microsoft L2TP/IPSec VPN Client;
• wszystkie strony negocjujące zabezpieczenia IPSec muszą mieć poprawnie skonfigurowany adres DNS – dodatkowo serwer DNS musi zwracać poprawną odpowiedź na zapytania o rekordy typu SRV dla usług _LDAP oraz _KERBEROS;
• zarówno klient jak i serwer muszą być członkami domeny i posiadać poprawne konto komputera w tejże domenie – jeśli nie jest to ta sama domena, to pomiędzy domenami klienta i serwera musi istnieć relacja zaufania, tzw. TRUST.

Jak widzimy, w wielu sytuacjach może okazać się, że IPSec oparty o technologię KERBEROS nie działa w ogóle lub też działa niestabilnie. W takich przypadkach zdecydowanie lepszym rozwiązaniem jest wykorzystanie drugiej z omówionych możliwości a więc infrastruktury PKI i certyfikatów.

Zakładamy, że administrator zainstalował, skonfigurował i zweryfikował działanie serwera certyfikatów (CA). Kolejnym krokiem jest uzyskanie certyfikatów dla komputerów (nie – użytkowników!!!) dla których chcemy wykorzystać IPSec. Przy pobieraniu certyfikatu z poziomu przeglądarki internetowej należy zaznaczyć opcję „Advanced Request” a później wybrać szablon certyfikatu „IPSec” oraz zaznaczyć pole „Use local machine store”.
Jeśli do pobrania certyfikatu użyjemy konsoli MMC „Certyfikaty” to przy dołączaniu przystawki trzeba zaznaczyć, że chcemy zarządzać certyfikatami dla konta komputera a później wybrać szablon „IPSec”.

Warto pamiętać, że jeśli dwie strony, pomiędzy którymi chcemy konfigurować IPSec uzyskują certyfikaty od różnych CA – to urzędy te muszą być wzajemnie zaufane, np., jeśli klient A uzyskuje certyfikat od urzędu CA_A a klient B – od urzędu CA_B to urząd CA_A musi znajdować się na liście zaufanych urzędów klienta B i odwrotnie. Oczywiście, jeżeli oba te urzędy mają ponad sobą jeden i ten sam urząd typu „root” to zaufanie jest realizowane automatycznie.

Kolejnym etapem konfigurowania IPSec będzie modyfikacja domyślnych polityk w systemie, które tak jak zaznaczyłem wcześniej – standardowo wykorzystują jedynie KERBEROS. Dla pojedynczego komputera najwygodniejszą metodą będzie użycie konsoli „Local Security Policy” – natomiast dla większej grupy maszyn bardziej efektywne jest utworzenie obiektu GPO i przypisanie go na poziomie bądź całej domeny lub też wybranych jednostek organizacyjnych.

Jak widzimy na powyższym zrzucie – mamy do dyspozycji trzy predefiniowane polityki IPSec, z których każda działa nieco inaczej:

• Client (Respond Only) – oznacza pasywną zgodę na warunki kodowania lub podpisywania narzucane przez druga stronę (przy założeniu że ustawienia polityk pozwalają na wynegocjowanie akceptowalnych przez obie strony warunków transmisji). Taką politykę włączamy w większości przypadków na stacjach roboczych i nie precyzujemy wówczas żadnych szczegółowych ustawień dotyczących kodowania (wymusza je serwer);
• Server (Request Security) – wbrew temu co sugeruje nazwa - polityka może być włączona zarówno na stacji roboczej jak i serwerze – komputer objęty takim ustawieniem próbuje kodować każda transmisję sieciową ( z wyłączeniem ICMP) a jeśli druga strona nie może używać IPSec lub nie ma przypisanej żadnej polityki – oba komputery przechodzą na transmisję niekodowaną;
• Secure Server (Require Security) – w przypadku włączenia tej polityki nie może być nowy o żadnej transmisji niekodowanej (poza ICMP) – jeśli druga strona nie ma włączonej polityki IPSec lub polityka jest niezgodna – połączenie jest odrzucane.

Zanim jednak włączymy dowolną z trzech ww. polityk musimy zmienić jej konfigurację tak, aby wykorzystywała certyfikaty komputerów w początkowej fazie negocjacji IPSec (tzw. IKE).
Po wybraniu właściwości polityki modyfikujemy właściwości filtrów „ALL IP TRAFFIC” oraz „DYNAMIC”. Dla każdego z wymienionych filtrów usuwamy na zakładce „Authentication Methods” pozycję „Kerberos” i dodajemy opcję „Use a certificate from this CA” jak na rysunku poniżej. Pamiętamy, aby wybrać odpowiedni urząd, od którego wcześniej uzyskaliśmy certyfikat IPSEC dla komputera.

Teraz już możemy sprawdzić działanie protokołu IPSec – w najprostszym wariancie będzie to polegało na włączeniu polityki „Server – require security” na serwerze (nasz SBS) oraz polityki „Client” na wybranej stacji roboczej zgodnej z IPSec – po podświetleniu wybranej polityki prawym klawiszem myszki wybieramy akcję „Assign” (Przydziel).

Jak przekonać się czy IPSec rzeczywiście działa i koduje dane przesyłane w sieci? Możemy tu wykorzystać dwa dodatkowe narzędzia:

• dodajemy (z poziomu panelu sterowania) narzędzie „NETWORK MONITOR” pozwalające na przechwytywanie i wyświetlanie pakietów sieciowych. Następnie realizujemy dowolne podłączenie do serwera ze stacji roboczej (np. przy użyciu przeglądarki internetowej podłączamy się do głównej strony serwera WWW). Po przechwyceniu danych monitorem powinniśmy widzieć wyłącznie warstwy ETHERNET oraz IP – wszystkie protokoły wyższego poziomu są ukryte (zakodowane) i wyświetlane tak jak na zrzucie poniżej (jako ESP);
  
• druga metoda polega na wykorzystaniu specjalnej konsoli zaprojektowanej do monitorowania protokołu IPSec – konsolę uruchamiamy startując pustą powłokę MMC.EXE i dodając do niej przystawkę „IP Security Monitor” . Jeżeli pomiędzy klientem a serwerem zostały wynegocjowane warunki kodowania IPSec to w konsoli pojawi się odpowiedni wpis z adresem IP i wyszczególnionymi algorytmami kodowania i podpisywania (jak poniżej).
  

Jak widać powyżej – stosunkowo łatwo zabezpieczyliśmy komunikację pomiędzy klientem a serwerem, aczkolwiek edytując polityki IPSec można tworzyć dużo bardziej zaawansowane konfiguracje. O tym jak tworzyć rozbudowane filtry i wykorzystywać inne możliwości IPSec (np. blokowanie czy tryby tunelowe) przeczytają czytelnicy w kolejnych artykułach.

Opracowanie własne dla portalu SBS-Forum.pl

Autor: Paweł Ratajczak