Kiedy w latach 70-tych projektowany był protokół IP, globalna sieć Internet nie istniała. Nie funkcjonowała powszechna obecnie bankowość elektroniczna, zakupy on-line, czy wiele innych form aktywności, z którymi spotykamy się współcześnie. Jednak w miarę rozwoju sieci i wprowadzania usług komercyjnych, bardzo szybko pojawiła się potrzeba zabezpieczenia przesyłanych danych. Stworzono do tego celu m.in. protokół IPSec.
Aby dobrze zrozumieć, po co tak właściwie zajmować się protokołem IPSec, konieczne jest wprowadzenie i wyjaśnienie podstawowych pojęć związanych z bezpieczeństwem sieci komputerowych. Mowa tu o:
- autentykacji (uwierzytelnieniu) – jest to potwierdzenie tożsamości użytkownika. To tak, jakbyśmy przyszli do hotelu, pokazali nasz dowód osobisty, a portier na podstawie zdjęcia stwierdził że my, to faktycznie osoba, za którą się podajemy. W systemach informatycznych autentykacja może mieć bardzo różną postać. Od najbardziej popularnego zabezpieczenia parą użytkownik/hasło, poprzez karty smart card z certyfikatem cyfrowym, na zabezpieczeniach biometrycznych kończąc. W procesie tym używanych jest kilka protokołów, z których w kontekście systemów Windows wymienić należy Lan Manager, NTLMv1(56 bit), NTLMv2(128bit) oraz Kerberos.
- autoryzacji – czyli procesie sprawdzania, czy dany, uwierzytelniony już, użytkownik ma prawo do zasobów, do których próbuje się dostać. W procesie tym brane są pod uwagę np. w odniesieniu do systemu plików listy ACL. Opisują one, którzy użytkownicy posiadają jakie uprawnienia do konkretnych plików czy folderów.
Dlaczego powstał IPSec ?
Kiedy w latach 70-tych projektowany był protokół IP, globalna sieć Internet nie istniała. Połączenie chociażby kilku niewielkich sieci na dużą odległość było nie lada wyzwaniem. Nie funkcjonowała powszechna obecnie bankowość elektroniczna, zakupy on-line, czy wiele innych form aktywności, z którymi spotykamy się współcześnie. Nietrudno więc się domyślić, iż protokół IP był projektowany przede wszystkim pod kątem zapewnienia szybkości i niezawodności przesyłu danych. Ma on między innymi wbudowane mechanizmy pozwalające na sprawdzanie poprawności dostarczania danych i automatyczne inicjowanie procesu retransmisji. Przez wiele lat protokół IP był zupełnie wystarczający. Jednak w miarę rozwoju sieci Internet i wprowadzania usług komercyjnych, bardzo szybko pojawiła się potrzeba zabezpieczenia przesyłanych danych. Usługi bankowe, sprzedaż, aukcje internetowe - jakikolwiek przepływ pieniędzy w sieci, bardzo szybko motywował osoby postronne do prób łamania zabezpieczeń. Nie można było dłużej tolerować przesyłania przez globalną pajęczynę danych w czystym formacie tekstowym. Pojawiła się konieczność zabezpieczenia transferów zarówno pomiędzy serwerami firmowymi, jak i komputerami klientów do nich się podłączających. Był jednak pewien problem. Co z wszystkimi systemami czy aplikacjami, które zostały napisane wcześniej i doskonale nadal wypełniają swoje zadanie? Wiele firm nie było by w stanie ponieść dodatkowych kosztów związanych z przebudową zakupionego wcześniej oprogramowania. Czy zatem musiały się one godzić na straty finansowe związane z podsłuchem informacji ? Czy jedynym wyjściem była całkowita przebudowa posiadanej infrastruktury? Na szczęście nie. Stworzono bowiem protokół IPSec. Działa on w warstwach trzeciej lub czwartej modelu ISO/OSI. Oznacza to, iż dla wszystkich wcześniej stworzonych aplikacji jest on przezroczysty. Programy te nie są świadome, że ruch w niższych warstwach jest szyfrowany. To głównie ten fakt spowodował, że protokół IPSec stał się tak popularny w dzisiejszych środowiskach biznesowych.
1.3 Czym jest protokół IPSec ?

Przede wszystkim należy powiedzieć, że nie jest to produkt firmy Microsoft. To, co potocznie określamy mianem IPSec, to tak naprawdę zbiór kilku protokołów, opartych o otwarte standardy. Istnieją więc narzędzia obsługi tego protokołu w innych systemach operacyjnych, takich jak na przykład Linux. Otwiera to możliwość bezpiecznego łączenia sieci opartych o różne architektury i różne systemy operacyjne. Pozwala na tworzenie sieci VPN, dzięki którym pracownicy mogą w dowolnej chwili, bezpiecznie korzystać z zasobów firmowych. Umożliwia to nie tylko zdalne pobieranie dokumentów, ale także nadzór nad serwerami czy ich konfigurację. Jako że połączenia VPN są zestawiane poprzez sieć Internet, nie ma już mowy o dodatkowych kosztach utrzymania dedykowanych linii. Protokół IPSec pozwala zapobiegać atakom DOS, poprzez odpowiednie blokowanie niechcianego ruchu. Windows XP i Windows 2003 Server posiadają wbudowaną ścianę ogniową (firewall), ale w starszych systemach jedyną metodą stworzenia firewall’a było właśnie użycie IPSec’a. Protokół ten pozwala na zabezpieczanie ruchu zarówno pomiędzy pojedynczymi komputerami jak i całymi sieciami. Możliwe jest na przykład stworzenie bezpiecznego kanału komunikacyjnego pomiędzy dwoma oddziałami firmowymi. Chroniona jest poufność danych, ich integralność a także autentyczność. Mamy więc gwarancję, że nikt informacji tych nie przeczytał, że nie zostały one zmienione i pochodzą od zaufanego nadawcy. Rysują się więc dwa główne scenariusze użycia IPSec’a. Jeden, gdy zabezpieczamy ruch pomiędzy zdalnym, pojedynczym użytkownikiem i drugi, gdzie komunikacja odbywa się pomiędzy całymi sieciami. Warto prześledzić jak protokół IPSec dostosowuje się do obu tych sytuacji.
Zabezpieczanie komunikacji stacja – stacja
Bardzo łatwo wymyślić scenariusz, w którym zabezpieczenie takie będzie miało sens. Weźmy za przykład tak pospolitą już dzisiaj czynność jak sprawdzanie poczty. W tradycyjnym ujęciu, użytkownik uruchamia na komputerze domowym program pocztowy, lub korzystając z przeglądarki łączy się z nim poprzez interfejs WWW. Jedną z pierwszych czynności jakie będzie musiał wykonać, to podanie nazwy użytkownika i hasła. W momencie tym, dane te zostaną przesłane w sposób jawny. Każdy, komu uda się podsłuchać na trasie użytkownik – serwer, hasło i nazwę użytkownika bardzo łatwo odczyta z przechwyconych pakietów. Aby temu zapobiec, pomijając oczywiście możliwość użycia certyfikatów i protokołu SSL, można ruch ten zabezpieczyć protokołem IPSec. Wówczas, przed nawiązaniem komunikacji, komputer kliencki oraz serwer wynegocjują bezpieczny kanał, a protokół IPSec przechwyci cały ruch i przed wysłaniem odpowiednio go zaszyfruje. Dla użytkownika cały ten proces będzie niezauważalny. Jako że komunikacja dotyczy tylko dwóch komputerów, protokół IPSec działać powinien w tzw. Trybie transportowym. W praktyce oznacza to funkcjonowanie w warstwie czwartej modelu ISO/OSI. Wygląd pakietu IP dla tego trybu przedstawia się następująco (zakładając użycie protokołu ESP, o którym będzie później):

Jak widać oryginalne dane podczas przechodzenia przez warstwę czwartą (transportową) mają dodawany, oprócz nagłówka TCP/UDP, także nagłówek ESP. Oznacza to, że oryginalny nagłówek TCP/UDP jest zaszyty wewnątrz pakietu ESP. Nie jest zatem możliwe, bez znajomości klucza, przeczytanie danych oraz tego, co zawierał nagłówek TCP. Oryginalny nagłówek IP nie jest szyfrowany, więc atakujący mógłby odczytać jego zawartość i na tej podstawie próbować ewentualnie wywnioskować coś na temat zawartości pakietu. Co jednak, gdybyśmy i tą informację chcieli ukryć? Mając na przykład dwie sieci, nie chcieli poprzez Internet ujawniać używanych adresów IP? Wtedy musimy użyć IPSec’a w trybie tunelowym.
IPSec w trybie tunelowym
Tryb tunelowy koncepcyjnie różni się tylko tym, że szyfrowanie odbywa się warstwę niżej – czyli już w warstwie trzeciej (sieciowej). Oznacza to, że oryginalny nagłówek IP będzie zaszyty pod nagłówkiem ESP. Pojawia się zatem konieczność dodania nowego nagłówka IP. Adres nowego odbiorcy ma się więc nijak do oryginalnego miejsca przeznaczenia.
Skutkuje to koniecznością posiadania dodatkowego komputera, mogącego pełnić rolę tzw. bramy, która usuwałby zewnętrzny nagłówek, odszyfrowywała dane i kierowała je dalej do docelowego odbiorcy. Konfigurujemy więc dwa dedykowane komputery w obu zdalnych lokalizacjach tak, aby potrafiły między sobą szyfrować ruch, a później odszyfrowywać i rozsyłać w ramach lokalnej, zaufanej już sieci. Między tymi bramami powstaje więc bezpieczny tunel. Stąd właśnie nazwa tego trybu – tryb tunelowy.
Negocjacje zabezpieczeń
Gdy wiemy już, jak koncepcyjnie wygląda funkcjonowanie protokołu IPSec, możemy przeanalizować, jak jest to technicznie zorganizowane. Skoro dane mają być szyfrowane, oba zdalne systemy muszą używać wspólnych mechanizmów szyfrowania. Powinien też istnieć bezpieczny sposób wymiany kluczy szyfrujących. Problemy te są rozwiązane właśnie poprzez proces nazywany negocjacją zabezpieczeń. Tworzone są wówczas tzw. skojarzenia zabezpieczeń, które opisują używane algorytmy szyfrujące i inne parametry połączenia. Negocjacja składa się z dwóch etapów:
- tryb główny (main mode) – wykonywany stosunkowo rzadko, ze względu na znaczne obciążenie obliczeniowe (domyślnie co 8h). Zestaw zabezpieczeń ustala klient. Uzgadniane są algorytmy szyfrujące, algorytmy haszujące, metody autentykacji oraz grupa Diffie – Hellmana. Z zestawu zabezpieczeń przedstawionych przez klienta serwer wybiera pierwszy zgodny, pozwalający na udane stworzenie kanału komunikacji. W tym trybie są ponadto generowane klucze prywatny i publiczny na podstawie grupy D-H, oraz tzw. materiał klucza, służący później do generowania kluczy w trybie szybkim. Dodatkowo, komputery są uwierzytelniane.
- tryb szybki – wykonywany częściej (domyślnie co 1h lub 100MB danych). To właśnie w tym trybie tworzony jest bezpieczny kanał komunikacji. Możliwe jest to dzięki 2 skojarzeniom zabezpieczeń : jednemu dla danych przychodzących oraz drugiemu dla wychodzących. Co ważne, skojarzenia te mogą wygasnąć wcześniej, gdyż każda ze stron, zarówno klient jak i serwer, może wymusić renegocjację. Może się to zdarzyć na przykład w przypadku podejrzenia wycieku klucza.
Osoby zainteresowane szczegółami działania procesu wymiany kluczy odsyłam do stosownej literatury w sieci – ewentualne źródła mogę podać drogą poczty elektronicznej po kontakcie ze mną.
Wiemy już, że przed rozpoczęciem komunikacji protokół IPSec negocjuje używane zestawy algorytmów. A co dzieje się dalej, kiedy komputery zostały względem siebie uwierzytelnione i mogą już wymieniać informacje? Napisałem wcześniej, że dane są enkapsulowane protokołem ESP. Podam teraz nieco więcej informacji na temat protokołów używanych do transmisji.
Protokoły używane podczas transmisji
Podczas transmisji z użyciem protokołu IPSec możliwe jest wykorzystanie dwóch protokołów:
- AH (Authentication Header) – zapewnia on oryginalność i integralność danych. Pozwala zabezpieczyć się przed atakiem powtórzeniowym. Ważną cechą AH jest to, iż nie zapewnia on poufności danych. Nie ma bowiem możliwości zaszyfrowania danych przy pomocy tego protokołu. Podczas tworzenia specyfikacji IPSec’a wielokrotnie postulowano usunięcie z niej protokołu AH dlatego, że wszystkie jego funkcje a także wiele innych udostępnia opisany poniżej ESP. Brak szyfrowania danych może być nam jednak pomocny w sytuacji, gdy chcemy mieć kontrolę nad ruchem w sieci (kontrola na firewallu). Jeżeli dane nie są poufne i wystarczy nam tylko kontrola ich autentyczności, stosując AH cel ten możemy osiągnąć.
- ESP (Encapsulated Security Payload) – protokół zapewniający, oprócz funkcji oferowanych przez AH, także możliwość szyfrowania danych. Należy jednak pamiętać, że dane zaszyfrowane nie mogą być poddane inspekcji.
Znając zasady działania protokołu IPSec możemy przejść do planowania jego wdrożenia.
Jak dobrze zaplanować użycie protokołu IPSec
Protokół IPSec w systemach Windows

Żeby dobrze wykorzystać i wdrożyć protokół IPSec, musimy przede wszystkim wiedzieć, jakie możliwości oferują nam pod tym względem poszczególne systemy operacyjne firmy Microsoft. Protokół ten jest natywnie dostępny w takich systemach, jak Windows 2000, Windows XP oraz Windows 2003 Server. W tym ostatnim wprowadzono ponadto szereg usprawnień, takich jak chociażby filtry uruchamiane już podczas startu systemu, pozwalające chronić się już na wstępnym etapie przed atakami typu DOS (Denial of Sernice). W przypadku starszych systemów, aby móc korzystać z IPSec’a konieczne jest zainstalowanie dodatkowego oprogramowania. Aktualizacje takie są dostępne dla systemów Windows 98, Windows NT 4.0 oraz Windows Millenium. Podobnie jak z innymi aspektami konfiguracyjnymi systemu, tak i tutaj dostęp do konfiguracji działania protokołu IPSec mamy zarówno z poziomu interfejsu graficznego – poprzez konsolę mmc, jak i wiersza poleceń. O ile w przypadku GUI na wszystkich systemach konfiguracja jest niemal identyczna, o tyle zarządzanie z wiersza poleceń jest nieco utrudnione. Z nieznanych mi powodów firma Microsoft dostarczyła bowiem narzędzia niezbędne do konfiguracji IPSec’a z wiersza poleceń różne w każdym z trzech systemów : Windows 2000, Windows XP i Windows 2003 Server. Choć funkcjonalnie programy te są bardzo zbliżone, to ich składnia jest zupełnie inna. I tak, w Windows 2000 mamy narzędzie o nazwie ipsecpol, w Windows XP ipseccmd a w Windows 2003 Server netsh. Co ciekawe netsh występuje także w Windows XP, ale z jakiegoś powodu została z niego usunięta funkcjonalność dotycząca IPSec’a. Nietrudno się zatem domyślić, iż napisanie skryptu mogącego działać na wszystkich trzech systemach będzie stanowiło kłopot.
Od czego zacząć planowanie?
Kluczem do sukcesu jest przede wszystkim dokładne przemyślenie planowanej konfiguracji. Zbadanie, jakich aspektów codziennej pracy użytkowników zmiany te mogą dotknąć oraz w jaki sposób wdrożenie IPSec’a może wpłynąć na działanie krytycznych dla środowiska aplikacji. Należy przemyśleć jak ewentualne negatywne skutki zminimalizować. Trzeba mieć bowiem na uwadze, że zła konfiguracja spowoduje w najlepszym wypadku wolniejsze działanie usług a w najgorszym nawet ich całkowitą niedostępność. Na tym etapie należy zdecydować między innymi jakich metod autentykacji będziemy używali. Trzeba mieć więc na uwadze możliwości systemów operacyjnych oraz poziom wymaganego bezpieczeństwa danych.
Integracja z Active Directory
Osobie bez większego doświadczenia administracyjnego to wszystko, o czym pisałem wcześniej może wydać się bardzo skomplikowane. Nic bardziej mylnego. Wdrożenie protokołu IPSec w środowisku Active Directory jest naprawdę bardzo proste. Konfigurację stacji klienckich, czy nawet serwerów członkowskich możemy bowiem przeprowadzić z użyciem GPO. Konfigurujemy więc odpowiednie ustawienia w edytorze GPO, a później usługa Active Directory propaguje je do wskazanych komputerów. Konfiguracja ręczna byłaby dużo bardziej czasochłonna. Dzięki zintegrowanemu środowisku i usłudze katalogowej, możemy ponadto skorzystać z metody uwierzytelniania protokołem kerberos. Dzięki temu, także problem uwierzytelniania jest za nas rozwiązywany w tle. To nie koniec korzyści z używania Active Directory. Usługa ta pozwala bowiem dodatkowo na automatyczne generowanie certyfikatów czy delegację uprawnień, co może być przydatne gdy posiadamy cały zespół administratorów. Jaką rolę pełnią w IPSec’u kerberos oraz certyfikaty? Dowiemy się o tym omawiając metody autentykacji.
Testowanie
Nie trzeba chyba nikogo przekonywać jak ważnym elementem każdego planu jest dobre zaplanowanie etapu testowania. Jeżeli w firmie istnieją już przetestowane procedury wdrożeniowe, sytuacja jest prostsza. W przypadku ich braku, należy postępowanie takie wypracować. Jest to czynność wręcz niezbędna w środowiskach produkcyjnych. Zasięg i czas trwania tego etapu zależą oczywiście od rozmiaru sieci i posiadanych środków finansowych. W ogólności jednak etap ten jest wieloczęściowy. Po pierwsze należy stworzyć laboratorium testowe, możliwie najwierniej odzwierciedlające sieć produkcyjną. Powinniśmy umieścić w nim komputery różnych architektur sprzętowych, pracujących pod kontrolą wszystkich systemów używanych przez użytkowników. Konieczne byłoby także zainstalowanie aplikacji krytycznych dla działania firmy. W środowisku takim staramy się zasymulować zwykłą, codzienną pracę użytkowników. Trudno jednak osobom bardziej wprawnym, jak na przykład administratorzy, przewidzieć jakie problemy mogą dotknąć przeciętnego użytkownika. Dlatego kolejnym etapem powinno być testowanie z uczestnictwem małej grupy pracowników. Wykonując swoje codzienne obowiązki, będą nieocenioną pomocą przy wykrywaniu niedociągnięć. Co bardzo ważne, po każdym etapie należy wszelkie problemy i ich rozwiązania udokumentować. Może to znacznie ułatwić późniejszą analizę. Kolejnym krokiem, który należy podjąć, jest wdrożenie pilotażowe. Konfigurujemy część prawdziwej sieci do korzystania z IPSec’a. W tym momencie za wszelką cenę powinniśmy unikać wymuszania szyfrowania ruchu. Jeżeli bowiem komputery, z jakiegoś powodu, nie będą potrafiły się wzajemnie uwierzytelnić, całkowite zablokowanie działania sieci jest bardzo prawdopodobne. Po udanym wdrożeniu pilotażowym, mając komplet dokumentacji z wcześniejszych etapów, możemy przystąpić do wdrożenia pełnego.
Uwierzytelnianie w IPSec’u
Ze wstępu wiemy już, że proces uwierzytelniania polega na potwierdzeniu tożsamości. W przypadku protokołu IPSec można mówić jedynie o tożsamości komputerów, gdyż w żaden sposób nie jest on przystosowany do autentykowania użytkowników. Dostępne są trzy metody uwierzytelniania : kerberos, certyfikaty oraz klucz współdzielony. Możliwe jest oczywiście mieszanie kilku z nich jednocześnie. Rozsądne jest na przykład stworzenie infrastruktury działającej w oparciu o kerberos w sieci lokalnej i o certyfikaty w odniesieniu do połączeń z klientami zewnętrznej sieci partnerskiej. O zaletach i wadach każdej z metod napisałem krótko poniżej.
Kerberos
Jest to domyślny sposób uwierzytelniania w środowisku Active Directory. Jego olbrzymią zaletą jest właściwie brak konieczności jakiejkolwiek konfiguracji. Kerberos działa w oparciu o tak zwane bilety. Podczas uwierzytelniania generowany jest bilet, na podstawie którego później potwierdzania jest tożsamość komputera. Co ważne, kerberos działa tylko w środowisku Active Directory. Oznacza to, że jeżeli nie posiadamy i nie planujemy wdrożenia usługi katalogowej, skorzystać możemy już tylko z dwóch pozostałych metod: certyfikatów lub dzielonego klucza.
Certyfikaty
Mają one dosyć szerokie spektrum zastosowań. Mogą służyć zarówno do szyfrowania ruchu IPSec, jak i, co dużo bardziej popularne, do szyfrowania komunikacji z serwerami WWW z użyciem SSL’a. Może się więc zdarzyć, że firma posiada już infrastrukturę klucza publicznego i obsługa certyfikatów jest w sieci dobrze usadowiona. Certyfikaty, generalnie biorąc, są wykorzystywane w środowiskach, w których nie jest możliwe użycie kerberosa. Czyli na przykład tam gdzie nie ma w ogóle Active Directory. Często certyfikaty służą do zestawiania połączenia w oparciu o IPSec pomiędzy dwoma firmami partnerskimi. To jest właśnie główne pole ich zastosowań. Należy pamiętać, że łączące się komputery muszą ufać nawzajem posiadanym certyfikatom. W środowisku usługi katalogowej oprócz tego, że same certyfikaty wygenerowane zostaną automatycznie, to będą one miały wspólny zaufany serwer główny. W przypadku braku urzędu certyfikacji w firmie, konieczne będzie ręczne dodanie odpowiednich wpisów. Bardzo ważne jest, aby do konfiguracji protokołu IPSec nie używać certyfikatów z silną ochroną klucza. Wymagają one bowiem wpisania hasła przy próbie ich użycia. Interfejs konfiguracyjny IPSec’a nie pozwala jednak na interakcję z użytkownikiem. Można przez to stracić wiele godzin na szukanie przyczyny nieudanych negocjacji w oparciu o takie certyfikaty.
Klucz współdzielony
Jest to najmniej bezpieczna metoda uwierzytelniania. Ze względu na swoje słabości nie powinna być używana w środowisku produkcyjnym, a jedynie podczas testów. Dane są bowiem szyfrowane w sposób symetryczny kluczem, który w postaci jawnej zapisywany jest w rejestrze systemu Windows. Zalecane jest zatem używanie po pierwsze, kluczy dosyć długich ( powyżej 25 znaków), a po drugie różnych dla każdej pary komputerów. Kompromitacja pojedynczego serwera, skutkuje wtedy tylko wyciekiem kluczy do transmisji z tą konkretną maszyną. Reszta danych w sieci ma poufność zapewnioną. Prostota działania metody klucza dzielonego pozwala na szybkie wykrywanie usterek w konfiguracji IPSec’a, nie powiązanych z uwierzytelnianiem. Diagnostyka taka byłaby trudniejsza w przypadku certyfikatów czy Kerberosa.
Wdrażanie protokołu IPSec
Elementy konfiguracyjne
Mając podstawy teoretyczne działania protokołu i pogląd na planowanie jego zastosowań, najwyższa pora przejść do wdrożenia. W tym paragrafie prześledzimy krótko podstawowe składniki konfiguracyjne. Przedstawię ich rolę i powiem jakie dają możliwości. Zaczniemy od samego dołu, czyli od najmniejszych elementów, a są nimi…
Filtry

Filtry, jak nietrudno się domyślić, opisują ruch sieciowy. Mogą analizować ruch ze względu na wiele aspektów, takich jak na przykład port źródłowy, port docelowy, adres IP źródłowy czy docelowy. Co ciekawe, możliwe jest skonfigurowanie dynamicznych wpisów. Funkcja ta jest bardzo przydatna w sytuacji, gdy chcemy zaszyfrować ruch w kilku sieciach, gdzie dla każdej z nich inny jest adres serwera, z którym ruch chcemy szyfrować (np. serwer dns, brama domyślna). Filtry umożliwiają dodanie dynamicznego wpisu, pod który później podstawiane są odpowiednie adresy IP. Ale uwaga! Jest tutaj pewna pułapka. Dodanie mianowicie wpisu dotyczącego nazwy DNS, wpisuje tak naprawdę nie nazwę do filtra, ale adres IP jej odpowiadający w momencie dodawania. Należy o tym pamiętać, aby nie być zaskoczonym, gdy po jakimś czasie nazwa pozostanie ta sama, adres IP serwera ulegnie zmianie, a nasz ruch przestanie być zabezpieczony. Filtry służą systemowi do wybrania odpowiedniej reguły. Jedynym przeznaczeniem filtrów jest ich dodanie do listy filtrów. Z pojedynczymi filtrami niewiele można zrobić – zawsze muszą być najpierw dodane do listy.
Listy filtrów
Listy filtrów grupują poszczególne filtry razem i przypisują do określonych reguł. Domyślnie w systemie istnieją dwie takie listy : Cały ruch IP oraz Cały ruch ICMP.
Akcje

Określają one sposób postępowania z dopasowanymi pakietami. Istnieją trzy typy akcji : Zezwalaj, Zablokuj i Negocjuj. Co ciekawe, z jakiegoś powodu nie jest domyślnie dostępna w systemie akcja Zablokuj i trzeba ją ręcznie zdefiniować. Jest to o tyle dziwne, że przecież jest to jedna z częściej używanych akcji. Działanie pierwszych dwóch typów można intuicyjnie wywnioskować z ich nazwy. Dlatego przyjrzyjmy się trzeciej akcji, Negocjowaniu. Wymusza ona negocjację zabezpieczeń pomiędzy komputerami. Możliwe jest zdefiniowanie kilku zestawów zabezpieczeń, ale należy wtedy pamiętać, żeby ułożyć je w kolejności od najlepszych do najgorszych. Bowiem to klient wybiera który zestaw zostanie użyty przeglądając listę z góry na dół. Definiujemy w tej akcji, czy ruch ma być szyfrowany, czy może zapewniana tylko jego integralność. Określamy jakie algorytmy mają zostać użyte podczas komunikacji. Choć z pozoru konfiguracja może się wydać skomplikowana, to jest ona ułatwiona dzięki kreatorom zawartym w systemie.
Reguły filtrowania
Są elementami składającymi się z list filtrów, akcji i typu połączenia. W każdej z reguł może znaleźć się tylko jedna akcja i jedna lista filtrów. W systemie istnieje ponadto reguła domyślna, która jest stosowana w przypadku nie dopasowania ruchu do żadnej innej. Reguły sterują zachowaniem odnośnie pewnej dopasowanej do filtra grupy pakietów. Możemy na przykład stworzyć regułę zabraniającą ruchu z określonej sieci do portu 80 na naszym serwerze.
Zasady
Zasada jest, najprościej mówiąc, zbiorem reguł. W danym momencie, na każdym z komputerów może być zastosowana tylko jedna zasada IPSec. Określa ona kompleksowo zachowanie filtra IPSec w odniesieniu do ruchu. W systemach Windows istnieją trzy predefiniowane zasady. Server (request security), która, jak wskazuje nazwa, powoduje, że serwer przy próbie nawiązania z nim komunikacji będzie wysyłał żądanie szyfrowania ruchu. W przypadku nieudanej negocjacji, dalszy transfer będzie możliwy, ale już bez udziału IPSec’a. Inaczej działa zasada Secure Server (Require security), która powoduje natychmiastowe zerwanie łączności w przypadku niemożności zaszyfrowania pakietów. Ostatnia zasada, Client (respond only) jest używana głównie w odniesieniu do stacji klienckich i zmusza je do odpowiedzi na żądania serwerów dotyczące negocjacji ruchu szyfrowanego.

Podsumowując : mamy najmniejsze elementy, jakimi są pojedyncze filtry. Grupowane są one następnie w listy filtrów. Z drugiej strony, tworzymy akcje, które określają różne sposoby traktowania pakietów. Spinamy następnie listy filtrów z akcjami, za pomocą reguł. Reguły te wkładamy do zasady IPSec, która stanowi ostateczny element konfiguracyjny.
IPSec w środowisku Active Directory

Każdy, kto kiedykolwiek korzystał z usługi katalogowej systemu Windows wie, jak dużą niesie ona pomoc w zarządzaniu środowiskiem sieciowym. Jednym z mechanizmów wspomagających jest tutaj bowiem GPO, czyli Polisy Grupowe. Co ciekawe, można ich użyć także do dystrybucji zasad IPSec’a. Wystarczy więc stworzyć odpowiednią polisę GPO, a później podpiąć do konkretnej lokacji, domeny czy jednostki organizacyjnej. Bardzo ważna jest w tym przypadku znajomość kolejności aplikowania GPO, ponieważ, jak wspomniałem wcześniej, w danej chwili aktywna może być tylko jedna zasada IPSec. Oznacza to, że w przypadku wielopoziomowej struktury polis GPO, zasady IPSec w nich zawarte nie będą w żaden sposób łączone, a tylko zastępowane w całości. Warto zatem zadbać, aby struktura polis GPO była możliwie najprostsza. Bardzo ważne jest też to, iż nie powinno się szyfrować komunikacji pomiędzy kontrolerem domeny a komputerami członkowskimi. Dlaczego? Z bardzo prostego powodu. Wyobraźmy sobie scenariusz, w którym wymuszamy ruch szyfrowany pomiędzy kontrolerem domeny a stacją kliencką. Ustawiamy odpowiednią zasadę w polisie GPO, odświeżamy ustawienia i nasz kontroler od tej chwili będzie wymagał szyfrowania. A co ze stacją kliencką? Próbuje ona odświeżyć ustawienia GPO i … już nigdy nie połączy się z kontrolerem, bo nie wie, że ruch ma być szyfrowany. Starajmy się więc przypisywać odpowiednie polisy tylko komputerom, które ich naprawdę potrzebują. Dodatkowo należy wspomnieć, iż IPSec w Windows nie wspiera rozwiązań klastrowych. A precyzyjnie, wspiera, ale tylko w systemach Windows 2003. W związku z czym taka konfiguracja uniemożliwia komunikację ze stacjami klienckimi, działającymi pod kontrolą Windows XP czy Windows 2000.
Dołączone do tego artykułu prezentacje wideo pokażą krok po kroku konfigurowanie protokołu IPSec, zarówno w oparciu o kerberosa, jak i certyfikaty.
Monitorowanie działania protokołu
Etap kontroli działania protokołu jest ważny z dwóch powodów. Po pierwsze, pozwala upewnić się, że wszystko działa zgodnie z naszymi intencjami. Po drugie, umożliwia diagnozowanie problemów w sytuacji, gdy testujemy nasze rozwiązanie, lub z jakiegoś powodu przestało ono spełniać postawione wymagania. Do dyspozycji mamy kilka narzędzi, które krótko zostały scharakteryzowane poniżej.
Przystawka Monitorowanie zabezpieczeń IP
Podstawowe narzędzie graficzne do kontroli działania protokołu IPSec. Umożliwia podejrzenie szeregu statystyk, dotyczących zarówno trybu głównego negocjacji jak i szybkiego. Możliwe jest między innymi sprawdzenie utworzonych asocjacji oraz protokołów szyfrowania przez nich używanych. Przystawka ta pozwala ponadto wyświetlić nazwę aktualnie obowiązującej zasady IPSec wraz z nazwą polisy GPO, przez którą zasada ta została przypisana.
Podgląd zdarzeń
Myślę, że jest to narzędzie skąd inąd wszystkim doskonale znane, a co więcej przydatne przy monitorowaniu działania IPSec’a. Warto czasami zajrzeć do dzienników, ponieważ są tam widoczne zdarzenia związane z protokołem IPSec (figurują jako zdarzenia logowania). Opisują one takie sytuacje, jak utworzenie i usunięcie nowych asocjacji zabezpieczeń czy zmiany aktywnych zasad IPSec. Możliwe jest jednak włączenie bardzo szczegółowego poziomu logowania, włącznie z rejestrowaniem wszystkich porzuconych pakietów. Nietrudno się domyślić, iż ustawienie takie bardzo szybko zapełni log systemowy, dlatego powinno być włączane na krótki czas i tylko wówczas, gdy przeprowadzamy dokładną analizę problemu. Nie ma narzędzia graficznego w systemie, które poziom logowania pozwalałoby włączyć. Jest to możliwe natomiast korzystając z wiersza poleceń i narzędzia netsh. Robi się to w następujący sposób:
netsh ipsec dynamic set config ipsecdiagnostics 7
netsh ipsec dynamic set config ipsecloginterval 60
Pierwsza opcja odpowiada za stopień szczegółowości logowania ( 7 – maksymalny), a druga za częstotliwość dokonywania wpisów, podaną w sekundach (60 to minimum).
Logowanie negocjacji IKE
Jest to funkcja wykorzystywana podczas naprawdę poważnych problemów, ponieważ po jej włączeniu są logowane wszystkie najmniejsze szczegóły związane z negocjacjami. IKE (Internet Key Exchange) to właśnie mechanizm używany przez IPSec do wymiany kluczy. Włączenie dokładnego śledzenia negocjacji umożliwia netsh:
netsh ipsec dynamic set config ikelogging 1
Po takiej konfiguracji tworzony jest specjalny log: %systemroot%\Debug\Oakley.log. Mieści on maksymalnie 50000 linii, a zdarzenia w nim zawarte mogą nie być od razu zrozumiałe. Aby odczytać postać tego logu konieczne może okazać się zajrzenie do dwóch RFC : ISAKMP RFC 2408, IKE RFC 2409. Opisane są w nich dokładnie komunikaty wymieniane podczas negocjacji.
Narzędzie netsh
Wspomniane już wcześniej netsh, oprócz możliwości konfiguracyjnych posiada także mechanizmy śledzenia działania IPSec’a. Co ważne, informacje wyświetlane przez netsh są równie szczegółowe jak z poziomu przystawki mmc. Aby wyświetlić informacje o działaniu IPSec’a w wierszu poleceń należy wpisać:
netsh ipsec dynamic show all
Konsola wydajności
To kolejne bardzo popularne narzędzie systemu Windows. Na co dzień, używana do monitorowania wydajności serwerów. Może być także wykorzystana do badania działania protokołu IPSec i to nie tylko w czasie rzeczywistym. Pozwala nam ona bowiem na prowadzenie długofalowego monitoringu i skonfigurowanie alertów. Dzięki temu możliwe będzie rozwiązanie problemów pojawiających się w nietypowych lub wręcz losowych momentach. Możliwe jest to dzięki takim obiektom jak IPSec v4 Driver oraz IPsec v4 IKE.
Monitor sieciowy
Pozwala na monitorowanie całego ruchu sieciowego, w tym w szczególności na sprawdzanie działania protokołu IPSec. Monitor sieciowy mogą zobaczyć Państwo w działaniu podczas prezentacji wideo. Pokazuję tam, że ruch faktycznie został zaszyfrowany i nie mamy możliwości jego podejrzenia. Narzędzie to pozwala odczytywać zawartość pakietów na bardzo niskim poziomie, dzięki czemu świetnie nadaje się do diagnostyki.
Netdiag.exe
Przypomnijmy, że narzędzie netsh zostało z jakiegoś powodu pozbawione funkcjonalności dotyczącej IPSec’a w systemie Windows XP. Musi więc istnieć alternatywny sposób badania działania tego protokołu. Jest nim właśnie netdiag.exe. Z pomocą tego programu możliwe jest badanie działania IPSec’a w systemach Windows 2000 i Windows XP. Jako że narzędzie to służy do diagnostyki sieci jako takiej, gdy badac chcemy tylko IPSec, należy wywołać je następująco:
netdiag /test:ipsec
Podsumowanie
Artykuł ten miał na celu przybliżenie działania protokołu IPSec, który to bardzo zyskał na znaczeniu w ciągu ostatnich kilku lat. Coraz większa rola Internetu w naszym codziennym życiu pociąga wzrost przestępczości elektronicznej. To zmusza do wprowadzania bardziej skutecznych mechanizmów ochrony. Wiele osób nie jest nawet świadomych korzystania na co dzień z IPSec’a. A przecież podczas połączenia VPN, każdy naciśnięty klawisz, każdy bajt informacji wędrującej przez sieć globalną mógłby być łatwo podejrzany. Mógłby, gdyby nie był chroniony odpowiednim protokołem. Dzięki skutecznemu szyfrowaniu zapewnianemu przez IPSec’a, wielu administratorów może spać spokojnie - nie bojąc się o swoje dane, podczas gdy wędrują one w tym czasie przez globalną pajęczynę na setki czy tysiące kilometrów.
Dodatki - prezentacje wideo
- Szybka konfiguracja IPSec
Jest to prezentacja pokazująca, jak bardzo szybko w oparciu o predefiniowane zasady dostępne w systemie skonfigurować systemy do szyfrowania ruchu
- Filtrowanie ruchu poprzez IPSec
Prezentacja w której pokazane zostało w jaki sposób tworzyć filtry, listy filtrów, akcje i zasady na przykładzie blokowania dostępu do serwera WWW.
- IPSec w oparciu o certyfikaty
Prezentacja podobna do pierwszej, z tą jednak różnicą że tym razem wykorzystywane są certyfikaty.
Autor: Paweł Damian (MCSA)
Spis treści
Artykuł autorstwa Czytelnika portalu opublikowany w ramach akcji Popisz się. Nie odpowiadamy za prezentowane treści.