W świecie zabezpieczeń systemów informatycznych wcześniej czy później (raczej wcześniej) każdy administrator lub oficer bezpieczeństwa musi stawić czoła wyzwaniu o imieniu firewall. Jak to stawić czoła? Przecież firewall to rzecz banalna. Każdy używa zapór, nawet na zwykłych pecetach, więc w czym problem?

Wszyscy wiedzą, czym jest firewall i wszyscy go używają, a jednak kiedy przychodzi moment projektowania i konfiguracji okazuje się, że zaczynają się schody. Dzieje się tak, ponieważ znakomita większość użytkowników ma do czynienia z automatami - produktami, które same decydują, co i jak przepuszczać, a co blokować. Nam pozostaje jedynie kliknięcie dymku i wyrażenie zgody lub nie na to co zaproponował firewall. O ile jednak rozwiązania takie dobrze sprawdzają się w przypadku domowego komputera, to w przedsiębiorstwie nie mają racji bytu. Tutaj konieczna jest kontrola każdego aspektu ruchu krążącego zarówno wewnątrz sieci, jak i na jej brzegu. Z tym wiąże się kolejny problem - zaprojektowania i doboru odpowiednich rodzajów zabezpieczeń.

Obecnie niezaprzeczalne jest, że "ogniomurki" nie są i nie mogą być jedynymi zasiekami broniącymi dostępu do zasobów korporacji. Oprócz tego stosowane są zabezpieczenia na routerach brzegowych, systemy zapobiegania włamaniom (IPS), dedykowane rozwiązania chroniące poszczególne rodzaje aplikacji lub protokołów sieciowych, akceleratory VPN, filtry treści itp.

Dlatego właściwe dobranie i rozmieszczenie zapór ogniowych oraz ułożenie reguł polityki w ten sposób, aby nie wchodziły w konflikt z innymi zabezpieczeniami, nie jest zadaniem trywialnym. Do tego dochodzi zapewnienie odpowiedniej wydajności tych rozwiązań i utrzymanie równowagi pomiędzy poufnością i bezpieczeństwem a dostępnością. Trzeba bowiem pamiętać, że wszystkie systemy ochronne nie są celem samym w sobie, a służą zapewnieniu ciągłości biznesu. Samemu tematowi doboru firewalli można poświęcić całą książkę - tekst ten nie próbuje jednak wyczerpać zagadnienia, a jedynie wskazać na kilka istotnych spraw.

Garść teorii, szczypta rozsądku, łyk kawy...

Jaki jest więc najlepszy przepis na zaporę? Zacznijmy od początku. Załóżmy, że zajmujemy się tylko i wyłącznie firewallami. Sprawa nie jest prosta, bo ich typów i używanych przez nie technik jest co najmniej kilka, przy czym każdy z nich odpowiada innym potrzebom. Dlatego przed wyborem rozwiązania warto zastanowić się, jaki cel i w jakim miejscu infrastruktury chcemy osiągnąć. W zależności od tego dobierzemy odpowiednie technologie. Czym dysponujemy? Generalnie możemy wyróżnić trzy typy bram ogniowych: filtry pakietów, zapory przechowujące informacje o stanach (stateful inspection) oraz proxy aplikacyjne. Każda z tych technologii ma swoje zalety i wady, każdą też warto rozważyć.

Najprostszym typem firewalla są bezstanowe filtry pakietów. Monitorują one ruch zarówno przychodzący, jak i wychodzący biorąc pod uwagę podstawowe informacje, które znajdują się w nagłówku pakietu IP bądź pakietu transportowego - źródłowy adres IP, docelowy adres IP, port źródłowy i port docelowy. Operują zatem w warstwie 3 i 4 modelu OSI/ISO. Jest to absolutne minimum. O ile wydaje się, że więcej do szczęścia nie potrzeba, to filtr pakietów ma kilka poważnych wad.

Po pierwsze, obecnie większość zagrożeń czyha powyżej warstwy 4, zwłaszcza w warstwie aplikacyjnej, a filtry pakietów nie mają tak daleko sięgającej "świadomości". Zatem większość współczesnych ataków zwyczajnie ominie naszą zaporę. Z tym wiąże się druga wada - bardzo ograniczone możliwości złożonego filtrowania ruchu. Na przykład w przypadku ruchu SMTP decyzja może polegać tylko na zaakceptowaniu pakietów przychodzących na port 25 lub ich odrzuceniu oraz ewentualnie wskazaniu adresów źródłowych i docelowych. Po trzecie, filtry pakietów podejmują decyzje w oparciu o pojedyncze pakiety. Nie zwracają uwagi, czy dany pakiet jest fragmentem nawiązanego już połączenia, czy pojawił się zupełnie przypadkowo. Stąd m.in. podatność na skanowania, np. FIN scan (gdzie po wysłaniu pojedynczego pakietu FIN sprawdzamy powracający pakiet - standardowo brak odpowiedzi oznacza, że port jest otwarty, a odpowiedź w postaci pakietu z flagą RST/ACK, że zamknięty). Ponadto prostota filtrów pakietów powoduje, że mają one problemy z obsługą skomplikowanych protokołów. Sztandarowym przykładem może być protokół FTP, zwłaszcza w wydaniu "active", gdzie musielibyśmy zezwolić na wszystkie połączenia przychodzące z portu 20 na wszystkie porty powyżej 1023. To, rzecz jasna, niedopuszczalne.

Wygląda zatem na to, że bezstanowe filtry pakietów są bezużyteczne. Ale czy na pewno? Mają one swoje niezaprzeczalne zalety - są bardzo szybkie, łatwe we wdrożeniu i przeźroczyste dla użytkownika. Doskonale nadają się do zgrubnej obróbki ruchu. Możemy chociażby odciąć wszystkie pakiety z adresami prywatnymi od wypłynięcia na wody Internetu, a z drugiej strony - przed wpłynięciem do naszej sieci. To już coś! Takie kategoryczne decyzje charakterystyczne są obecnie dla urządzeń, których wiele osób nie zauważa, a już na pewno nie widzi w nich firewalli - zwykłych routerów, urządzeń będących pierwszą, prostą linią obrony. Im nowszy router, tym bardziej zaawansowanych technologii używa włącznie z elementami charakterystycznymi dla pakietów stanowych, o których za chwilę. Nigdy jednak router nie będzie w stanie zastąpić firewalla, bo też i nie do tego został stworzony (szczególnie w rozwiązaniach korporacyjnych).

Dużo bardziej zaawansowanymi rozwiązaniami są tzw. stanowe filtry pakietów, inaczej zwane filtrami dynamicznymi. Technologia ta - mimo dość sędziwego wieku (wymyślił ją CheckPoint w 1993 r.) - jest stale rozwijana i ma się nadzwyczaj dobrze. Słowem kluczowym dla odróżnienia filtrów stanowych od bezstanowych jest "kontekst". Wszystko co przesiewa firewall nie dotyczy pojedynczych pakietów, a całości połączenia. Zapora zatem "wie", czy otrzymany właśnie datagram jest częścią nawiązanego już połączenia, czy rozpoczyna kolejne, a może jest zupełnie "z księżyca" i można go śmiało wyrzucić.

Ponadto, dzięki utrzymywaniu informacji o stanach, firewall zakłada, że jeżeli np. łączymy się do strony WWW, to oczekujemy odpowiedzi. Zatem zezwala na ruch powracający w odpowiedzi na nasze zapytanie. Takiej możliwości nie dają filtry bezstanowe. To z kolei ułatwia życie administratorowi, gdyż tworząc reguły nie musi on pamiętać o zezwoleniu na ruch w obydwu kierunkach.

Skoro jesteśmy przy regułach. W dynamicznych filtrach pakietów istnieje pewien porządek przetwarzania reguł - od góry do dołu. A zatem, jeżeli przychodzi pakiet niebędący częścią nawiązanego już połączenia, to jest on sprawdzany pod kątem dopasowania do listy reguł. Jeżeli natrafi na regułę, której warunki wypełnia, przerywane jest dalsze sprawdzanie i wykonywane zostaje opisane w niej zadanie.

Idźmy zatem dalej. Filtry bezstanowe potrafiły wykorzystać tylko proste informacje nagłówkowe. Filtry stanowe dodały do tego numery sekwencyjne i aktualny stan flag. Ale nie tylko. W zależności od producenta i stopnia zaawansowania, możliwości analizy protokołów sięgają do warstwy 7, co pozwala dokładniej kontrolować przepływające bity.

No i wreszcie trzecia grupa firewalli - proxy aplikacyjne. Filozofia ich działania jest zupełnie odmienna od przestawionych wcześniej filtrów pakietów. Ten typ zapory charakteryzuje się tym, że zbudowany jest z zestawu aplikacji przeznaczonych do obsługi poszczególnych rodzajów ruchu. Tworzy to swoistego rodzaju poduszkę powietrzną pomiędzy jedną a drugą strefą bezpieczeństwa. Co to oznacza? - że każde proxy rozumie protokół, do którego zostało przeznaczone. A zatem unikamy sytuacji, która byłaby charakterystyczna dla zwykłego filtra pakietów.

Dla lepszego zobrazowania posłużmy się przykładem: załóżmy, że przychodzi połączenie na port 25, co sugeruje SMTP, a więc zgodnie z napisaną regułą ruch taki jest przekazywany do serwera pocztowego. A jeśli na porcie 25 pojawi się np. SSH to filtr pakietów w dalszym ciągu uzna, że jest to ruch SMTP. Natomiast proxy analizując zawartość pakietu rozpozna, że tak nie jest i nie potraktuje tego ruchu jako SMTP.

Jest tylko jeden mały problem. Wspomnieliśmy wcześniej, że proxy firewall to zestaw aplikacji. Zatem dla każdego protokołu potrzebna jest osobna aplikacja. Uruchomienie takiej aplikacji i utrzymywanie jej pracy odbija się niekorzystnie na wydajności systemu. Dodatkowo mnogość protokołów używanych w dzisiejszych sieciach uniemożliwia stworzenie takiego proxy aplikacyjnego, który zdolny byłby obsłużyć wszystkie te protokoły (zwłaszcza że powstają one w szybkim tempie). Proxy nieźle sprawuje się w przypadku popularnych protokołów, np. HTTP czy DNS. Z tego też powodu wielu producentów stara się łączyć technologie stateful inspection z technikami proxy aplikacyjnego, czego rezultatem jest coś, co można nazwać rozwiązaniem "deep inspection", czyli możliwością skanowania protokołów wraz z ich zawartością do 7 warstwy modelu OSI.

Warto jeszcze krótko wspomnieć, że możliwości firewalla zależą nie tylko od rodzaju użytej technologii, ale również platformy sprzętowej. Dedykowane rozwiązania typu appliance (gotowa skrzynka) są odpowiednio dobrane przez producentów pod kątem osiągnięcia maksymalnej wydajności. Nie zawsze więc produkty typu software i appliance będą równoznaczne wydajnościowo. Dobrym przykładem są tutaj urządzenia oparte na procesorach ASIC (Application Specific Integrated Circuit), gdzie całość przetwarzania odbywa się w pojedynczym układzie scalonym. Dzięki temu wydajność takich rozwiązań jest bardzo wysoka.