i mikstura prawie gotowa...

Przyjęło się uważać, że w świecie systemów bezpieczeństwa wdrożenie rozwiązania jest stosunkowo proste, natomiast utrzymanie go już nie. Dlaczego? Ponieważ wszystkie zmiany - w naszym przypadku na zaporze - muszą być dokonywane "na wczoraj", bo ktoś gdzieś nie może się dostać. My robimy wszystko, aby ten dostęp zapewnić i tworzy się istny bałagan. Po kilku miesiącach okazuje się np., że jakaś stacja jest kilkukrotnie NATowana bez potrzeby i stąd ciągłe narzekania użytkownika na powolność działania. Ale to tylko jeden z przykładów.

Kolejną przykrą prawdą jest niski poziom znajomości rozwiązań przez administratorów. O ile wdrożeniowcy całkiem nieźle znają "swoje" produkty, o tyle administratorzy nie zawsze. A zatem pierwsza zasada powinna brzmieć - poznaj rozwiązanie, którego używasz.

Kolejnym kluczem do sukcesu jest odpowiednie rozmieszczenie i dobór zapory. Inne parametry będą brane pod uwagę przy bramie brzegowej, a inne przy tej dzielącej strefy sieci LAN. Nie każdy firewall brzegowy poradzi sobie z przepustowościami sieci lokalnej. Koncepcji rozmieszczenia zapór jest tyle, ilu projektantów. Na szczęcie istnieje kilka układów odniesienia, które w zależności od potrzeb mogą być odpowiednio modyfikowane. Mamy więc do dyspozycji instalację typu bastion, która jest niepraktyczna w dzisiejszych sieciach rozległych. Nadaje się tylko tam, gdzie nie przewiduje się udostępniania jakichkolwiek usług na zewnątrz.

Następna w kolejności jest instalacja z wydzieloną strefą DMZ w ramach jednego firewalla (screened subnet). Przeważnie sprowadza się to do trzech kart sieciowych - jedna dla każdej ze stref (Internet, LAN, DMZ). Architektura popularna w mniejszych instalacjach, gdzie kluczowe jest ograniczenie kosztów wdrożenia zabezpieczeń, a chronione informacje nie mają znaczenia strategicznego. Dobrze skonfigurowana zapora zapewnia tutaj dość wysoki poziom bezpieczeństwa.

Mamy jeszcze architekturę podwójnie zabezpieczonej strefy zdemilitaryzowanej. W tym rozwiązaniu usługi stosuje się dwie zapory. Jedna oddziela Internet od strefy DMZ, druga strefę DMZ od sieci LAN. Jest to rozwiązanie o wysokim stopniu bezpieczeństwa.

W tym miejscu dochodzimy do kolejnej decyzji, którą musimy podjąć. Projektanci systemów zabezpieczeń radzą, aby stosować dywersyfikację rozwiązań. Brzmi skomplikowanie, ale jest w gruncie rzeczy proste. Chodzi o to, aby używać produktów różnych firm. Problem polega na tym, że nie istnieje uniwersalna platforma centralnego zarządzania rozwiązaniami pochodzącymi od różnych dostawców. A zatem dokonujemy wyboru pomiędzy komfortem wynikającym z prostoty zarządzania, a utrudnieniami, za którymi kryje się zwiększony poziom bezpieczeństwa. Obecnie, gdy liczba interfejsów sieciowych w każdym w zasadzie firewallu jest większa niż trzy, możemy dodawać kolejne strefy, np. administracyjną (gdzie posadowimy moduły zarządzające), usług wewnętrznych, zasobów kluczowych itd. Pamiętajmy jednak, że im bardziej skomplikowana architektura, tym trudniej nad nią później zapanować i dużo łatwiej o nieświadomy błąd. A zatem, jak mówią Amerykanie, keep it simple - proste rozwiązania się sprawdzają.

Jeszcze tylko wymieszać...

Mamy schemat, mamy firewalle. Czas zająć się regułami dostępowymi. Są one niczym innym, jak odwzorowaniem zasad ujętych w korporacyjnej polityce bezpieczeństwa. Do nas należy przełożenie słowa pisanego na język pakietów. Liczba i stopień skomplikowania reguł będzie zależał od kilku czynników - od "zagmatwania" polityki bezpieczeństwa, architektury sieci i naszej wiedzy. Często zdarza się, że bardzo skomplikowana polityka bezpieczeństwa po odpowiednim przeanalizowaniu zaowocuje 25 regułami i to wszystko.

A skoro jesteśmy przy liczbach. Tak jak mówiliśmy wcześniej, prostota jest naszym sprzymierzeńcem. Dobrze skonstruowana tablica reguł (rulebase) będzie zawierała maksymalnie 50 reguł. Oczywiście, zdarzają się przypadki, gdzie jest tych reguł znacznie więcej, ale taka sytuacja jest dość niebezpieczna. Po pierwsze, skomplikowaną tablicą ciężko się zarządza. Po drugie, mało kto ogarnia tak złożony układ, a po trzecie duża liczba reguł to zwiększone obciążenie systemu, a wtedy łatwo o przeoczenie.

Zasady konstruowania reguł są dla każdego z produktów podobne. Różnica może polegać na sposobie ich przetwarzania. W większości obecnie stosowanych rozwiązań reguły w tablicy reguł przetwarzane są kolejno, tj. od góry do dołu. Pierwsza napotkana reguła, która odpowiada płynącemu ruchowi, jest wykonywana, a dalsze sprawdzanie tablicy przerywane. Dlatego tak ważna jest kolejność budowania reguł. Zasada jest taka, że bardziej szczegółowe umieszczamy na górze tablicy, a ogólne na dole. Przy odwrotnym postępowaniu zezwolimy na więcej niż byśmy chcieli, a reguła szczegółowa nigdy nie zostanie wykonana i stanie się martwa.

W niektórych produktach zasada zachowania kolejności nie obowiązuje. Zapora sama podejmuje decyzję, która reguła powinna mieć zastosowanie. Technologię tę często nazywa się best match. Jest ona jednak jak miecz obosieczny. Łatwość administrowania okupujemy niejednoznacznym i nie do końca czytelnym przetwarzaniem reguł. W pierwszym podejściu w razie problemów łatwo zdiagnozować przyczynę.

inna sprawa to dobór obiektów, z którymi przyjdzie nam pracować. Obecnie rzadko posługuje się produktami niedającymi możliwości zarządzania obiektami, tj. odwzorowania elementów sieci. Mamy zatem bramy, hosty, podsieci, użytkowników, serwery, protokoły itp. - słowem wszystko, z czego można ułożyć regułę. Podczas budowania tablicy, pamiętając o prostocie, starajmy się tworzyć grupy, zamiast posługiwać się pojedynczymi obiektami. Wpłynie to korzystnie na przejrzystość.

Posłużmy się przykładem: dział projektowy to 30 stacji. Zamiast więc do każdej reguły, która odnosi się do działu projektowego, żmudnie przyporządkowywać jedna po drugiej 30 stacji, możemy śmiało stworzyć grupę i operować tylko na niej. Podobnie rzecz ma się z protokołami. Klasycznym przypadkiem jest ICMP. Jak wiemy, za pomocą ICMP możemy wygenerować kilkadziesiąt zapytań. Zamiast używać echo-request, echo-reply, address mask request itp. pojedynczo, łatwiej jest stworzyć grupę. Kolejna ważna sprawa to monitorowanie tego, co stworzymy. W każdym firewallu istnieje możliwość ustawienia rejestrowania reguły, a ściślej mówiąc sytuacji, w której dana reguła została wykonana.

Z obserwacji wynika, że administratorzy mają tendencję do rejestrowania wszystkiego. Pytanie tylko, po co?

Jeżeli zezwalamy na jakąś komunikację, to w większości przypadków nie ma potrzeby rejestrowania jej przebiegu. Chyba że jesteśmy paranoikami i zależy nam na śledzeniu wszystkiego. Wtedy jednak będziemy mieli log tworzący się szybciej, niż będziemy go w stanie przejrzeć i jest duża szansa, że przeoczymy najważniejsze wpisy.

Nas, jako osoby odpowiedzialne za bezpieczeństwo, nie interesuje to, co jest dozwolone. Znacznie ciekawsze jest to, co zakazane. A zatem wszędzie tam, gdzie zakazujemy dostępu, warto rejestrować, włączać alarmy i powiadomienia. Z rejestrowaniem ściśle wiąże się także problem wydajności. Zdarza się, że mając kilkadziesiąt reguł, z których każda jest zapisywana w logu, i dużą intensywność ruchu, zapora nie radzi sobie z ciągłym przetwarzaniem wszystkich tych informacji i gubi pakiety. A to już nie przelewki. Warto jeszcze wspomnieć o jednej sytuacji, kiedy rejestrowanie wszystkiego jest wskazane, tzn. podczas testowania poprawności reguł i wykrywania błędów. Testy wykonujemy przeważnie poza "godzinami szczytu", a wtedy analiza staje się prostsza.

Wniosek: pomyślmy czy i co rejestrować. Inną rzeczą jest zadbanie o odpowiednie opisanie tworzonej tablicy reguł. Każda z reguł powinna być opatrzona krótkim komentarzem pozwalającym w razie konieczności szybko zorientować się, czemu miała służyć. Często jest tak, że po zbudowaniu tablica wydaje się perfekcyjna. Czytamy ją raz, drugi, trzeci i uznajemy, że lepiej być nie może. Robimy opis, a tydzień później, gdy patrzymy na reguły świeżym okiem, dostrzegamy ich ułomności. Jeżeli pozostawimy reguły bez oznaczeń, to za każdym razem, kiedy po dłuższej przerwie spojrzymy na ich układ, nie będziemy w stanie dojść do rozsądnych wniosków.

Warto także prowadzić zapiski kiedy, dlaczego i kto wprowadzał zmiany w tablicy. Część produktów na rynku zwalnia nas z tego obowiązku, gdyż posiada wbudowane mechanizmy audytu. Oczywiście, nie bylibyśmy dobrymi administratorami bez sprawdzenia poprawności działania stworzonej tablicy.

By nie poprzestać tylko i wyłącznie na teorii, zbudujmy przykładową tablicę reguł dla Fikcyjnej Firmy SA. Postępując zgodnie z zasadami, tablicę stworzymy w oparciu o prostą politykę bezpieczeństwa. W Fikcyjnej Firmie SA polityka ta wygląda następująco:

1. Pracownicy firmy, przebywając na jej terenie, mogą korzystać z serwisów WWW w dowolnym zakresie.

2. Pracownicy firmy, przebywając na jej terenie, mają dostęp do korporacyjnej poczty elektronicznej.

3. Pracownicy firmy przebywając na jej terenie nie mogą korzystać z prywatnej poczty elektronicznej

4. Pracownicy firmy, przebywając na jej terenie, mogą do celów służbowych korzystać z komunikatora Gadu Ggadu; używanie innych komunikatorów jest zabronione.

5. Użytkownicy Internetu mają dostęp do serwisu WWW Fikcyjnej Firmy SA.

6. Administratorzy mogą z każdego miejsca zarządzać usługami znajdującymi się pod ich opieką, pod warunkiem że zapewniono odpowiedni poziom bezpieczeństwa.