Rozwój technologii zapór zdąża w kierunku integracji zaawansowanych funkcji filtrowania i analizy ruchu sieciowego.

Do niedawna zapory firewall nie potrafiły sprawdzać dogłębnie ruchu SSL i jego zabezpieczanie wymagało stosowania innych metod. Nie ulega wątpliwości, że najlepszym rozwiązaniem w systemach bezpieczeństwa jest jednak analiza całego ruchu, bez sztywnego podziału na protokoły, hosty i porty. Ostatnio zaczynają się pojawiać urządzenia, które mają taką funkcjonalność i potrafią m.in. analizować również ruch SSL. Można oczekiwać, że już wkrótce ich oferta zacznie się znacząco poszerzać.

Tradycyjne zapory sieciowe, spotykane do dziś w ofercie takich firm jak Check Point, Cisco czy Juniper, identyfikują ruch na podstawie protokołów oraz portów, na których odbywa się ruch. Z tego powodu nie potrafią do końca zidentyfikować ruchu generowanego przez aplikacje na portach 80 i 443. W szczególności dotyczy to właśnie ruchu SSL.

Pomocny pośrednik

Historycznie pierwszym, do dziś stosowanym rozwiązaniem zabezpieczającym jest użycie serwera pośredniczącego (proxy). W tym modelu ruch od aplikacji klienckiej jest kierowany przez serwer pośredniczący, który może dokonać autoryzacji użytkownika, analizować ruch i filtrować niepożądaną zawartość. Aby uniemożliwić ominięcie pośrednika, stosuje się blokowanie ruchu bezpośrednio kierowanego do maszyny docelowej. W niektórych instalacjach nie ma nawet ustawionych tras wiodących na zewnątrz sieci lokalnej - do Internetu. Jedynymi maszynami, które mają dostęp, są lokalne serwery DNS oraz maszyna sieciowego pośrednika proxy.

Na rynku jest wiele gotowych rozwiązań pracujących w tym modelu zabezpieczenia. Najpopularniejszym serwerem pośredniczącym jest squid, obecny w niemal każdej dystrybucji systemu Linux czy BSD. Warto podkreślić, że zastosowanie dobrze skonfigurowanego proxy znacząco podwyższa bezpieczeństwo sieci, bowiem aplikacja, która nie została skonfigurowana do obsługi połączenia przez proxy, nie będzie mogła wysłać ani pobrać z Internetu żadnych danych. Wyjątkiem są te programy, które potrafią wykraść konfigurację proxy z przeglądarki - potrafi to np. Skype.

Serwery pośredniczące szczególnie dobrze sprawdzają się do filtrowania treści - zatrzymywania powodzi reklam, blokowania dostępu do niepożądanych stron, blokowania obiektów takich jak aplety Java, obiekty Flash i skrypty Javascript. Przy prawidłowej konfiguracji potrafią oddzielić typowe połączenia przeglądarki od prób dostępu niepożądanych aplikacji (takich jak komunikatory czy Skype), zaś dołączenie ochrony antywirusowej jest stosunkowo proste i zwykle stosowane.

Znaleźć intruza

Milowym krokiem w dziedzinie zabezpieczeń sieci było pojawienie się systemów detekcji intruzów i prewencji. Obecnie wiele liczących się producentów oferuje swoje rozwiązania w tej dziedzinie. Można je podzielić na następujące grupy:

1. Systemy wykrywające intruzów na podstawie sygnatur lub statycznych reguł host-port-protokół.
2. Systemy, które dokonują dogłębnej analizy ruchu na konkretnych portach.
3. Systemy, które analizują szczegółowo ruch niezależnie od portu.
4. Systemy, które oprócz zaawansowanej analizy potrafią deszyfrować i kontrolować ruch SSL.

Narzędzia detekcji intruzów w najprostszych i najtańszych rozwiązaniach bazują na pierwszym z tych modeli. Oprócz rozwiązań czysto programowych, takich jak zapora w systemie Linux bazująca na iptables, której reguły są modyfikowane za pomocą skryptów i programu snort, systemy takie są obecne również w niektórych tanich urządzeniach klasy UTM. Rozwiązania takie sprawdzają się bardzo dobrze w małych firmach, gdzie prawdopodobieństwo zagrożenia jest równie niewielkie jak budżet przeznaczony na system bezpieczeństwa.

W wielu przypadkach ruch kierowany na ustalone porty należy do łatwych do analizowania klas i ma łatwo uchwytne cechy. W ten sposób można łatwo oddzielić normalny ruch HTTP od pozostałej aktywności na porcie 80. Wiele zapór wyposażonych w analizatory ruchu potrafi dokonać inspekcji ruchu HTTP pod warunkiem ustawienia reguł kierujących właściwy ruch z portu 80 na moduł analizatora wewnątrz urządzenia. Można to spotkać nawet w tanich zaporach, będących de facto komputerem z "zaszytym" systemem operacyjnym typu UNIX (takim jak Linux, BSD lub aplikacja napisana w VxWorks). Wadą takiej metody jest analiza wyłącznie ruchu kierowanego przez reguły wprost na port analizatora urządzenia. Ponieważ analizator obsługuje tylko znane mu protokoły na ustalonych portach, można w ten sposób analizować tylko niektóre kategorie ruchu.

Znacznie lepszą metodą jest analiza przy użyciu zestawu kryteriów i regułek, które są stosowane jedna po drugiej. Analizie podlega wtedy cały ruch przechodzący przez system i jest to wielka zaleta tego typu urządzeń. Dzięki odpowiednim zestawom reguł w konfiguracji urządzenia można łatwo wykryć ruch szyfrowany inaczej niż za pomocą SSL, a kierowany na standardowy port 443 a także ruch kierowany na inne porty. Niektóre urządzenia potrafią z powodzeniem kategoryzować ruch wewnątrz danego protokołu, oddzielając np. typowe przeglądanie stron od ruchu komunikatorów, apletów Java, pobierania muzyki czy wideo - wszystko po HTTP. Dzięki temu można skutecznie wyłączyć w firmie wszelkie komunikatory lub strumieniowanie audio pobieranego wewnątrz sesji HTTP. Ruch generowany przez spyware również można względnie łatwo wykryć. Tego typu inspekcje potrafią wykonać niemalże wszystkie nowoczesne zapory w mniej lub bardziej zaawansowanej formie.

Wadą tego rozwiązania jest bardzo duże zapotrzebowanie na moc obliczeniową, gdyż trzeba sprawdzić wiele pakietów, a każdy z nich (a nieraz wiele sąsiednich także) trzeba przetestować pod kątem wielu reguł.

Zapory bywają ślepe

Nawet zaawansowane analizatory ruchu HTTP mają jedną poważną wadę - nie sprawdzają dogłębnie ruchu SSL. Do niedawna żadne urządzenie nie potrafiło tego robić. Aby chronić serwer WWW SSL przed atakami, trzeba było stosować akceleratory SSL, zaś zapory chroniące serwer WWW przez analizę zapytań trzeba było umiejscowić między akceleratorami a tym serwerem. Taka konfiguracja jest często stosowana w dużych systemach, gdzie ważne jest także odciążenie serwera aplikacyjnego od obliczeń kryptograficznych związanych z SSL. Jeśli nie jest stosowany akcelerator SSL, ruch kierowany od klienta do serwera nie podlega analizie. Z tego powodu ochrona serwera obsługującego natywnie SSL była dotąd trudna.

Obecnie ulega to zmianie - na rynku jest już coraz więcej rozwiązań, które potrafią z powodzeniem rozpinać sesję SSL kierowaną np. do firmowego serwera. Typowym zastosowaniem jest ochrona ważnego serwera obsługującego SSL (np. sklepu internetowego).

Ze względu na duże zapotrzebowanie na moc obliczeniową w bardzo krótkim czasie, w modułach detekcji dedykowanych do większych przepustowości, stosuje się niemal wyłącznie specjalizowane mikroprocesory. Podnosi to cenę urządzenia, ale zwiększa funkcjonalność.