Wbrew marketingowym pozorom, zapory sieciowe nie rozwijają się generacjami, ani nie przechodzą wielkich rewolucji. Z perspektywy technologicznej ich rozwój to systematyczny postęp, dokonujący się większymi lub mniejszymi krokami. Spośród pojawiających się okresowo trendów, tylko nieliczne zyskują aprobatę klientów i wsparcie wiodących producentów. I lepiej, żeby tak zostało.

Na przestrzeni ostatnich kilku lat systemy zabezpieczeń sieciowych przeszły dużo istotnych zmian. Nawet jeśli niektóre z nich są rzeczywiście ważne, ukute przez marketing producentów i prasę określenie Next Generation Firewall jest nieco przesadzone. Większość nowości polega, w gruncie rzeczy, na zwiększaniu różnymi sposobami granularności polityki bezpieczeństwa odzwierciedlającej obecną rzeczywistość. Zmiany zachodzą też w architekturze zapór, ale i tu trudno mówić o rewolucji. To raczej ewolucyjne wprowadzanie funkcji i opcji oczekiwanych głównie przez dużych klientów, a odzwierciedlających aktualne zagrożenia ze strony Internetu. Aby zrozumieć kierunki rozwoju systemów zabezpieczeń w najbliższej przyszłości, trzeba odrzucić slogany spojrzeć na nie z perspektywy odbiorcy tej technologii.

Od protokołu do aplikacji

Przez długi czas rozwój systemów zabezpieczeń był stymulowany pojawianiem się w sieci coraz to nowych protokołów, głównie w warstwie 4 i wyższych. Kiedy każda aplikacja wykorzystywała specyficzny dla siebie wariant komunikacji, tworzenie reguł i skuteczne filtrowanie ruchu było relatywnie łatwe. W połowie lat 2000. ten długotrwały trend zaczął słabnąć. Aplikacji przybywało, ale liczba aktywnie wykorzystywanych protokołów zaczęła maleć. Wskutek upowszechniania się usług internetowych oraz migracji aplikacji biznesowych na platformę WWW, producenci zaczęli masowo rezygnować z egzotycznych protokołów i zastępować je HTTP(S) jako uniwersalną metodą transportu danych w Internecie, i nie tylko.

Standaryzacja komunikacji była odpowiedzią na oczekiwania użytkowników, ale dla środowiska osób zajmujących się bezpieczeństwem stanowiła poważny problem. Najkrócej rzecz ujmując: gdy 80-90% ruchu w sieci zaczęło opierać się na tym samym protokole aplikacyjnym, wykorzystującym w większości przypadków jeden port sieciowy, odróżnienie ruchu uprawnionego od niedozwolonego stało się bardzo trudne. Producenci systemów zabezpieczeń nie od razu znaleźli dobre rozwiązanie. Ostatecznie rynek przystał na pomysł, by reguły filtrowania opierały się w pierwszym rzędzie na aplikacjach, a na protokołach i innych parametrach jedynie opcjonalnie. Z inżynierskiego punktu widzenia była to zmiana ważna, ale nie rewolucyjna.

„Gdy 80-90% ruchu w sieci zaczęło opierać się na tym samym protokole aplikacyjnym, wykorzystującym w większości przypadków jeden port sieciowy, odróżnienie ruchu uprawnionego od niedozwolonego stało się bardzo trudne. Ostatecznie rynek przystał na pomysł, by reguły filtrowania opierały się w pierwszym rzędzie na aplikacjach, a na protokołach i innych parametrach jedynie opcjonalnie”

Skuteczność automatycznego rozpoznawania aplikacji nie była początkowo bardzo wysoka – rzędu 60, może 70%. Nawet jednak taki poziom był dla wielu klientów atrakcyjny, umożliwiając im odzyskanie poczucia kontroli nad tym, co działo się w ich sieciach. To zachęciło producentów do dalszego rozwijania tej technologii. Z biegiem czasu techniki rozpoznawania aplikacji na podstawie generowanego przez nie ruchu zostały znacznie udoskonalone, a obecnie można je w zasadzie uznać za dojrzałe. Filtrowanie oparte na aplikacjach pozwoliło administratorom odzwierciedlić w regułach systemów zabezpieczeń zawiłości i wyjątki polityk bezpieczeństwa bez potrzeby tworzenia złożonych zestawów tradycyjnych reguł.

Od aplikacji do użytkownika

Szybko okazało się, że myślenie w kategoriach aplikacji to za mało. W dużych organizacjach zakresy uprawnień do funkcji i danych w ramach tych samych systemów są różne – w zależności od stanowiska. Jak to odzwierciedlić w regułach filtrowania? Nawet jeśli zapory posiadają własne repozytoria informacji o kontach użytkowników, to brakuje w nich odzwierciedlenia uprawnień i struktury firmy. Informacje te można jednak znaleźć w systemach domenowych Windows oraz katalogach LDAP. I tak, zapory zaczęły integrować się z pozostałymi elementami środowiska informatycznego, co stanowiło kolejny kamień milowy w rozwoju zapór.

Celem integracji zapór z domenami i katalogami LDAP jest uwierzytelnienie użytkowników na zaporze, a także możliwość dostosowania reguł filtrowania do aktualnego zakresu uprawnień użytkowników. W praktyce, i jedno, i drugie, okazało się trochę problematyczne. Aby nie zmuszać użytkowników do odrębnego logowania się na zaporze, uwierzytelnienie musiało odbywać się przezroczyście. Producenci zaproponowali kilka technik automatyzacji procesu uwierzytelniania. Check Point, na przykład, przechwytuje logowanie domenowe Windows, weryfikuje je z kontrolerem domeny, a dokładnie poprzez protokoły WMI i Kerberos. Na podstawie uzyskanej weryfikacji automatycznie uruchamiane są odpowiednie reguły na zaporze. Dla urządzeń spoza infrastruktury domeny pozostaje możliwość wykorzystania metody captive portal, polegającej na chwilowym przechwyceniu sesji przeglądarki w celu uwierzytelnienia na zaporze.

„Celem integracji zapór z domenami i katalogami LDAP jest uwierzytelnienie użytkowników na zaporze, a także możliwość dostosowania reguł filtrowania do aktualnego zakresu uprawnień użytkowników”

Inni producenci postanowili wykorzystać mniej wyrafinowane metody, polegające na ręcznym uzyskaniu „przepustki” przed próbą wykonania reglamentowanych polityką bezpieczeństwa połączeń sieciowych. Teoretycznie są one równie skuteczne, pozostaje jednak pytanie: przez jak długi czas reguła uruchomiona na zaporze w tym trybie ma pozostać aktywna? W przeciwieństwie do samego systemu Windows, mechanizmy „ręczne” nie sygnalizują domenie, a więc pośrednio zaporze, że użytkownik właśnie zakończył pracę w sieci. Ten mankament można oczywiście zlikwidować, np. za pomocą skryptów działających po stronie stacji roboczej, ale jest to rozwiązanie, delikatnie mówiąc, mało eleganckie.

Wirtualnie, logicznie lub… zobaczymy jak

Upowszechnienie się aplikacji webowych i związane z nimi zmiany w technologiach filtrowania ruchu, zbiegły się w czasie z gwałtownym rozwojem technologii wirtualizacyjnych. W przeciwieństwie do aplikacji biznesowych, umieszczanie zapór w maszynach wirtualnych nie było celowe – przede wszystkim ze względu na ich specjalny status w całej infrastrukturze, choć także z powodów wydajnościowych. Optymalnym miejscem integracji zapór z infrastrukturą wirtualną okazał się kontroler całego środowiska wirtualnego, czyli hypervisor. W przypadku środowiska VMware jest to warstwa vSwitch. Dawało to możliwość zapanowania nad wszelkim ruchem do i z maszyn wirtualnych, a dzięki „bliskości” sprzętu – również odpowiednią wydajność.

Umieszczenie zapory w samym hypervisorze nie wyklucza jej wirtualizacji, a może raczej jej podziału na niezależne od siebie zapory logiczne. Oczekiwania tego rodzaju wyszły w pierwszym rzędzie od dostawców usług internetowych obsługujących wielu klientów, a także grup kapitałowych obejmujących wiele niezależnych od siebie podmiotów. Podział platformy na wiele niezależnych platform logicznych pozwala zapewnić każdemu podmiotowi odrębny zestaw reguł filtrowania ruchu oraz specyficzne dla niego mechanizmy integracji zapory z pozostałymi elementami jego środowiska IT. Umożliwia ponadto zarządzanie nimi przez administratorów poszczególnych klientów czy spółek. Z tego samego powodu wiodący producenci zapór poszli dalej, wprowadzając możliwość partycjonowania również serwerów zarządzających zaporami.

W jaki sposób nowe trendy, w szczególności SDN – Software-Defined Networking, czy też NFV – Network Function Virtualization, wpłyną na architekturę i zakres funkcjonalny zapór? Chyba jeszcze za wcześnie wyrokować, ponieważ cele i założenia dla tych technologii nie zostały finalnie nakreślone. Dopiero gdy z obecnej „ameby” funkcjonalno-architekturalnej wykształci się solidna propozycja, będzie można rozpocząć dyskusję o tym co jest konieczne, potrzebne i możliwe. Dotychczasowy dorobek, a więc elastyczność w dziedzinie definiowania reguł, czy podział logiczny platform bezpieczeństwa z pewnością zostanie utrzymany. Ze względu na dużą zmianę technologiczną związaną z SDN/NFV, implementacje mogą różnić się od tego, z czym mamy do czynienia obecnie.

„W jaki sposób nowe trendy, w szczególności SDN /NFV wpłyną na architekturę i zakres funkcjonalny zapór? Chyba jeszcze za wcześnie wyrokować, ponieważ cele i założenia dla tych technologii nie zostały finalnie nakreślone. Dopiero gdy z obecnej „ameby” funkcjonalno-architekturalnej wykształci się solidna propozycja, będzie można rozpocząć dyskusję o tym co jest konieczne, potrzebne i możliwe”

Miarowym krokiem naprzód

Dotychczasowy rozwój technologii związanych z zaporami sieciowymi każe przyjąć postawę wyczekującą wobec przyszłych zmian. Rewolucji z pewnością nie będzie, bo nie zgodzą się na to klienci. Poza tym, nie wszystkie nowości i koncepcje wytrzymują próbę czasu, a bezpieczeństwo to taka dziedzina, od której od oczekuje się w pierwszym rzędzie skuteczności – bez względu na aktualnie panującą modę czy pogodę. Strategia postępu ewolucyjnego została zweryfikowana w praktyce – i tak już chyba pozostanie, bez względu na ogłaszane raz na jakiś czas marketingowe rewolucje.

Jarosław Bazydło

Autor jest inżynierem wsparcia w dziedzinie systemów bezpieczeństwa sieciowego w COMP S.A. Można się z nim skontaktować pod adresem: jaroslaw kropka bazydlo w domenie comp kropka com kropka pl.

Autorem zdjęcia Jarosława Bazydło jest Monika Dyba.