Firewall¶

Firewall jest jednym z podstawowych elementów ochrony sieci i najczęściej znajduje się na styku infrastruktury wewnętrznej z Internetem. Współczesne urządzenia mogą realizować routing, translację adresów, terminację tuneli VPN, kontrolę aplikacji, IPS, filtrowanie treści czy inspekcję szyfrowanego ruchu TLS.

W typowej instytucji funkcję tę pełni dedykowana zapora sieciowa jednego z wiodących producentów, takich jak Fortinet, Palo Alto Networks, Check Point, Sophos czy SonicWall. Sam wybór urządzenia nie zapewnia jednak bezpieczeństwa.

Firewall jest szczególnie wrażliwym elementem infrastruktury, który posiada dostęp do wielu segmentów sieci, przetwarza znaczną część ruchu i udostępnia usługi dostępne bezpośrednio z Internetu, w tym często również VPN. Przejęcie kontroli nad urządzeniem jest krytyczne w skutkach i prowadzi często do kompromitacji całej infrastruktury.

Z tego względu firewall należy traktować jako kluczowy element bezpieczeństwa całej infrastruktury.

Architektura i umiejscowienie¶

Sposób umieszczenia zapory w sieci zależy od jej architektury oraz roli, jaką ma pełnić. Najczęściej firewall znajduje się pomiędzy siecią wewnętrzną a Internetem, ale może również filtrować ruch pomiędzy wewnętrznymi segmentami infrastruktury.

Podział sieci na strefy, wydzielanie DMZ oraz warianty architektury wykorzystujące więcej niż jedną zaporę zostały szerzej opisane w artykule Separacja sieci. W tym miejscu warto natomiast zwrócić uwagę na sposób pracy samego urządzenia.

Tryby pracy firewalla¶

Większość współczesnych firewalli może pracować co najmniej w dwóch podstawowych trybach: routowanym oraz transparentnym.

Routed mode¶

W trybie routowanym firewall jest urządzeniem warstwy trzeciej i bierze bezpośredni udział w routingu. Poszczególne interfejsy lub podinterfejsy urządzenia posiadają własne adresy IP i należą do różnych sieci.

Przykładowa architektura może wyglądać następująco:

Firewall jest wtedy najczęściej bramą domyślną dla podłączonych do niego segmentów lub przekazuje ruch do kolejnych routerów znajdujących się wewnątrz infrastruktury.

Tryb routowany upraszcza stosowanie mechanizmów takich jak NAT, routing dynamiczny czy Policy-Based Routing i jest obecnie najczęściej spotykanym sposobem wdrażania zapór brzegowych.

Transparent mode¶

W trybie transparentnym firewall działa jako most warstwy drugiej. Urządzenie jest umieszczane pomiędzy dwoma elementami istniejącej infrastruktury bez konieczności zmiany ich adresacji.

Ruch przechodzący przez urządzenie nadal może być filtrowany i poddawany inspekcji, mimo że sam firewall nie pełni funkcji routera dla tych sieci.

Takie rozwiązanie bywa przydatne podczas wdrażania zapory w istniejącej infrastrukturze, w której zmiana adresacji lub routingu byłaby problematyczna.

Urządzenie w tym trybie (jak sama nazwa wskazuje) jest transparentne dla ruchu, jednak posiada interfejs lub adres przeznaczony do zarządzania, a niektóre funkcje mogą zachowywać się inaczej niż w klasycznym trybie routowanym. Przykładowo tryb transparentny zazwyczaj nie wspiera NAT lub wspiera go w bardzo ograniczonym zakresie, co bywa jednym z głównych powodów wyboru trybu routowanego.

Wysoka dostępność¶

Firewall brzegowy jest często pojedynczym punktem, przez który przechodzi cały ruch pomiędzy instytucją a Internetem. Jego awaria może więc oznaczać utratę dostępu do usług zewnętrznych, systemów opublikowanych w Internecie oraz zdalnego dostępu VPN.

W środowiskach, w których dostępność infrastruktury ma duże znaczenie, zapory powinny być wdrażane w klastrach HA.

Najczęściej stosowane są dwa modele:

• active-backup - jedno urządzenie aktywnie obsługuje ruch, drugie pozostaje gotowe do przejęcia jego funkcji
• active-active - ruch może być obsługiwany równocześnie przez więcej niż jeden element klastra

W praktyce active-backup jest zwykle prostszy operacyjnie i wystarczający w większości wdrożeń.

Klaster powinien synchronizować co najmniej:

• konfigurację
• obiekty i polityki
• stan interfejsów
• informacje wymagane do zachowania aktywnych sesji

Zakres synchronizacji zależy od producenta oraz wykorzystanych funkcji.

Samo utworzenie klastra nie gwarantuje poprawnego działania mechanizmu przełączenia. Failover powinien być okresowo testowany.

Test powinien obejmować nie tylko przejęcie roli przez urządzenie zapasowe, ale również działanie:

• routingu
• NAT
• tuneli VPN
• tras dynamicznych
• aktywnych sesji
• usług publikowanych przez firewall

Funkcje zaawansowane NGFW¶

Tradycyjne firewalle podejmowały decyzję głównie na podstawie adresu źródłowego, adresu docelowego, protokołu oraz numeru portu.

Współczesne zapory klasy Next-Generation Firewall (NGFW) analizują ruch znacznie dokładniej. Potrafią identyfikować aplikacje, użytkowników i protokoły niezależnie od wykorzystywanego portu oraz wykonywać dodatkową inspekcję przesyłanych danych. Używane mechanizmy NGFW powinny wynikać z rzeczywistych potrzeb ochrony danego segmentu.

Filtracja warstwy aplikacji¶

Filtrowanie wyłącznie na podstawie portów coraz częściej okazuje się niewystarczające. Wiele aplikacji wykorzystuje obecnie protokół HTTPS i komunikuje się przez port TCP/443.

Dopuszczenie tego portu nie oznacza więc zgody na jedną konkretną usługę. Tym samym kanałem mogą być realizowane między innymi:

• zwykłe przeglądanie stron WWW
• komunikatory
• usługi przechowywania plików
• narzędzia zdalnego dostępu
• VPN-y działające w warstwie aplikacyjnej
• media społecznościowe

Firewall wyposażony w mechanizm identyfikacji aplikacji może analizować charakterystyczne cechy protokołu i rozpoznawać faktycznie wykorzystywaną usługę.

Pozwala to tworzyć polityki typu:

Użytkownicy -> Internet

HTTPS                 ALLOW
Microsoft 365         ALLOW
SSH                   DENY
Tor                   DENY
Remote Administration DENY

Kontrola aplikacji może być szczególnie przydatna przy wykrywaniu narzędzi omijających standardowe mechanizmy dostępu, w tym szkodliwego oprogramowania i działań atakującego.

Trzeba jednak pamiętać, że identyfikacja aplikacji często wymaga głębszej analizy ruchu, a w przypadku protokołów szyfrowanych jej możliwości mogą być ograniczone bez zastosowania inspekcji TLS.

IPS¶

IPS, czyli Intrusion Prevention System, analizuje ruch przechodzący przez firewall w poszukiwaniu znanych wzorców ataków oraz zachowań mogących świadczyć o próbie wykorzystania podatności.

W przeciwieństwie do klasycznego IDS (Intrusion Detection System), którego głównym zadaniem jest wykrycie i zgłoszenie podejrzanego zdarzenia, IPS pracuje bezpośrednio w ścieżce ruchu i może automatycznie zablokować połączenie.

Mechanizm może wykrywać między innymi:

• próby wykorzystania znanych podatności
• charakterystyczne elementy exploitów
• skanowanie usług
• anomalie protokołów
• komunikację odpowiadającą znanym technikom ataku

Skuteczność IPS w dużej mierze zależy od aktualności sygnatur. Urządzenie musi mieć więc możliwość regularnego pobierania aktualizacji baz wykorzystywanych przez silnik inspekcji.

Nie należy również bezrefleksyjnie włączać wszystkich dostępnych sygnatur dla całego ruchu.

Jeżeli w sieci nie występuje dana technologia, jej kontrolowanie nie zwiększa bezpieczeństwa, natomiast może niepotrzebnie zużywać zasoby urządzenia i zwiększać liczbę fałszywych alarmów.

Dobrym przykładem jest stosowanie rozbudowanego zestawu sygnatur dotyczących serwerów baz danych na ruchu zwykłych stacji roboczych wychodzących do Internetu.

Polityki IPS powinny być więc dopasowane do chronionych systemów.

W zależności od urządzenia IPS może być również powiązany z innymi mechanizmami bezpieczeństwa, między innymi antywirusem sieciowym, filtrowaniem URL lub systemem sandboxingu.

Inspekcja TLS¶

Znaczna część współczesnego ruchu sieciowego jest szyfrowana. Jest to oczywiście korzystne z punktu widzenia ochrony danych, ale równocześnie ogranicza możliwości analizy ruchu przez urządzenia bezpieczeństwa.

Firewall widzący połączenie TLS może bez jego odszyfrowania poznać pewne informacje o komunikacji, ale nie posiada dostępu do pełnej zawartości przesyłanych danych.

Jeżeli konieczna jest dokładniejsza analiza, można zastosować TLS inspection, nazywaną również SSL inspection lub SSL decryption.

Firewall zestawia wtedy dwa niezależne połączenia:

Urządzenie odszyfrowuje ruch, wykonuje jego inspekcję, a następnie ponownie szyfruje komunikację.

W przypadku ruchu wychodzącego wymaga to zazwyczaj zainstalowania na urządzeniach końcowych zaufanego certyfikatu CA wykorzystywanego przez firewall.

Bez tego przeglądarka lub aplikacja będzie zgłaszała błąd certyfikatu.

Inspekcja TLS nie powinna jednak obejmować całego ruchu bez wcześniejszej analizy.

Routing i polityki¶

Firewall bardzo często pełni równocześnie funkcję routera. Sposób umiejscowienia zapory w architekturze sieci - czy pełni rolę bramy domyślnej dla wszystkich segmentów, czy routing wewnętrzny realizowany jest przez dedykowane urządzenia warstwy trzeciej - zależy od przyjętego modelu separacji sieci. Zasady projektowania segmentów, trasowania ruchu między nimi oraz umiejscowienia zapór zostały opisane w artykule Separacja sieci.

Z perspektywy samego firewalla istotne są natomiast specyficzne funkcje routingu, które mogą na nim być realizowane.

Routing statyczny i dynamiczny¶

W prostych środowiskach najczęściej wystarczające są trasy statyczne.

Przy bardziej rozbudowanej topologii firewall może uczestniczyć również w routingu dynamicznym, wykorzystując na przykład:

• OSPF
• BGP

Ma to zastosowanie szczególnie wtedy, gdy urządzenie jest połączone z wieloma routerami lub operatorami albo gdy infrastruktura posiada redundantne ścieżki komunikacyjne.

Uruchomienie routingu dynamicznego na firewallu powinno być jednak świadomą decyzją. Błąd w propagacji tras może mieć znacznie większy wpływ niż pojedyncza niepoprawna reguła zapory.

Sesje protokołów routingu należy ograniczać wyłącznie do zaufanych sąsiadów i zabezpieczać zgodnie z możliwościami wykorzystywanego protokołu.

Policy-Based Routing¶

Standardowy routing wybiera trasę przede wszystkim na podstawie adresu docelowego.

Policy-Based Routing pozwala dodatkowo uwzględnić inne parametry ruchu, na przykład:

• adres źródłowy
• interfejs
• protokół
• port docelowy

Mechanizm ten jest przydatny między innymi przy wykorzystywaniu kilku łączy internetowych.

Przykładowo:

Sieć użytkowników -> WAN1
Sieć serwerowa    -> WAN2

albo:

VoIP -> WAN1
pozostały ruch -> WAN2

Należy jednak pamiętać, że Policy-Based Routing wprowadza dodatkową logikę niezależną od klasycznej tablicy routingu.

Przy analizie problemów może więc dojść do sytuacji, w której trasa widoczna w tablicy routingu wskazuje jedno wyjście, a rzeczywisty ruch jest kierowany przez inne.

W środowiskach wykorzystujących Policy-Based Routing dokumentacja polityk routingu jest więc równie istotna jak dokumentacja samych reguł firewalla.

NAT¶

Translacja adresów (NAT) to jedna z kluczowych funkcji firewalla brzegowego. Pozwala na ukrycie wewnętrznej adresacji przed światem zewnętrznym lub mapowanie ruchu na publiczne adresy IP.

Wyróżnia się dwa podstawowe typy:

• SNAT (Source NAT) - zmiana adresu źródłowego. Najczęściej stosowana dla ruchu wychodzącego, aby cała sieć wewnętrzna „wychodziła” na jeden lub kilka publicznych adresów IP.

• DNAT (Destination NAT) - zmiana adresu docelowego. Wykorzystywana do publikowania usług wewnętrznych (port forwarding), aby ruch przychodzący na publiczny adres IP był przekierowywany do odpowiedniego serwera w sieci wewnętrznej

Konfiguracja NAT nie jest neutralna dla bezpieczeństwa. Błędnie skonfigurowana reguła DNAT może odsłonić wewnętrzny serwer na publiczny ruch, z pominięciem polityk zapory. Z tego powodu reguły NAT powinny być ściśle powiązane z regułami filtrowania i podlegać tej samej kontroli zmian. Kolejną ważną rzeczą jest, że często reguły SNAT są włączane bez potrzeby między lokalnymi segmentami infrastruktury, co znacząco zaciemnia logi (pojawia się tam jedynie adres bramy zamiast właściwego adresu hosta).

W przypadku wielu publicznych adresów IP warto zwrócić uwagę na politykę wyboru adresu źródłowego (Source Address Translation Policy), aby zapobiec nieoczekiwanym zmianom adresu IP.

Reguły DNAT dodatkowo w wielu przypadkach wymagają wymuszenia włączenia logowania ruchu, który przez nie przechodzi, gdyż nie robią tego automatycznie. Brak takiego logowania utrudnia analizę wszelakich incydentów i anomalii związanych z konkretną regułą.

VPN na firewallu¶

Wiele firewalli pełni jednocześnie rolę koncentratora VPN. Urządzenie może terminować zarówno tunele site-to-site łączące różne lokalizacje, jak i połączenia użytkowników zdalnych. Technologie VPN, uwierzytelnianie użytkowników oraz MFA zostały szerzej omówione w artykule Bezpieczny dostęp zdalny. Z punktu widzenia samego firewalla istotne jest przede wszystkim to, że ruch pochodzący z VPN nie powinien automatycznie otrzymywać pełnego dostępu do sieci wewnętrznej. Tunel należy traktować jako kolejne źródło ruchu podlegające standardowym politykom bezpieczeństwa.

Jeżeli użytkownik potrzebuje dostępu wyłącznie do jednego systemu, reguły powinny dopuszczać właśnie ten zakres, zamiast całych segmentów sieci. Sama usługa VPN jest również jednym z elementów firewalla najbardziej narażonych na ataki z Internetu. Jej konfiguracja oraz hardening zostały opisane w sekcji Hardening VPN.

Zarządzanie regułami i utrzymanie¶

Reguły firewalla mają tendencję do narastania wraz z wiekiem infrastruktury. Początkowo niewielka baza może po kilku latach zawierać setki lub tysiące wpisów utworzonych dla projektów, systemów i usług, które dawno przestały istnieć. Problemem nie jest przy tym wyłącznie liczba reguł. Znacznie większym zagrożeniem jest utrata wiedzy o tym, dlaczego konkretna polityka została utworzona i czy nadal jest potrzebna.

Przegląd polityk¶

Baza reguł powinna być okresowo przeglądana.

Dla każdej polityki warto być w stanie określić:

• dlaczego została utworzona
• kto jej potrzebuje
• jakie systemy obejmuje
• czy nadal występuje na niej ruch
• czy zakres dostępu nie jest większy niż wymagany

Reguły powinny posiadać czytelne nazwy lub komentarze. W środowiskach wykorzystujących system obsługi zmian warto również przechowywać identyfikator zgłoszenia, na podstawie którego dostęp został uruchomiony.

Przykładowo zamiast:

ALLOW_Server

bardziej użyteczna będzie nazwa:

ERP_USERS_TO_DB_TCP1433

uzupełniona komentarzem opisującym powód utworzenia reguły.

Przysłonięte polityki¶

Większość firewalli analizuje polityki w określonej kolejności.

Jeżeli wcześniejsza reguła obejmuje ten sam ruch co znajdująca się niżej polityka, druga z nich może nigdy nie zostać wykorzystana.

Przykład:

1. LAN -> Internet ANY ALLOW
2. LAN -> 203.0.113.10 HTTPS DENY

Jeżeli urządzenie kończy analizę po dopasowaniu pierwszej reguły, druga polityka nigdy nie zadziała.

Taką sytuację określa się jako shadowed rule.

Wiele współczesnych systemów zarządzania potrafi automatycznie wskazywać reguły całkowicie lub częściowo przesłonięte przez inne polityki. Mechanizmy te warto wykorzystywać podczas okresowych przeglądów konfiguracji.

Reguły nieużywane¶

Informacja o liczbie trafień w daną politykę jest bardzo pomocna podczas porządkowania konfiguracji. Reguła, która przez wiele miesięcy nie obsłużyła żadnego ruchu, może być kandydatem do usunięcia. Nie należy jednak usuwać jej wyłącznie na podstawie licznika. Niektóre połączenia są wykorzystywane bardzo rzadko, na przykład:

• systemy awaryjne
• rozwiązania Disaster Recovery
• okresowe zadania administracyjne
• usługi uruchamiane wyłącznie podczas prac serwisowych

Przed usunięciem reguły należy więc ustalić jej przeznaczenie. Dobrym rozwiązaniem jest również czasowe wyłączenie polityki przed jej całkowitym skasowaniem. Pozwala to szybko przywrócić dostęp, jeżeli okaże się, że reguła nadal była potrzebna.

Zmiany konfiguracji¶

Zmiany na firewallu powinny podlegać takim samym zasadom kontroli jak zmiany w innych krytycznych elementach infrastruktury.

Przed większą modyfikacją warto posiadać aktualną kopię konfiguracji, a samą zmianę przeprowadzać w sposób umożliwiający odtworzenie poprzedniego stanu.

Szczególnej ostrożności wymagają modyfikacje dotyczące:

• dostępu administracyjnego
• tras domyślnych
• NAT
• konfiguracji interfejsów
• VPN
• reguł obsługujących systemy krytyczne

Zasady wykonywania i przechowywania kopii konfiguracji zostały opisane w sekcji Kopie konfiguracji.

Logowanie i monitorowanie¶

Firewall jest jednym z najcenniejszych źródeł informacji o ruchu sieciowym.

W zależności od urządzenia logi mogą zawierać informacje o:

• źródłowym i docelowym adresie IP
• wykorzystanym porcie i protokole
• regule, która obsłużyła ruch
• wyniku sesji
• ilości przesłanych danych
• rozpoznanej aplikacji
• zdarzeniach IPS
• połączeniach VPN
• zmianach konfiguracji
• logowaniach administracyjnych

Można je ogólnie podzielić na dwie grupy.

Logi ruchu¶

Logi typu Flow, Traffic lub Session opisują komunikację przechodzącą przez urządzenie. Takie dane są szczególnie przydatne podczas analizy incydentów oraz ustalania, z jakimi systemami komunikował się konkretny host.

Logi systemowe¶

Drugą kategorię stanowią zdarzenia dotyczące samego urządzenia - logowania administratorów, zmiany konfiguracji, zmiany stanu klastra HA, zestawienie lub zerwanie tunelu VPN oraz błędy aktualizacji sygnatur bezpieczeństwa.

Z perspektywy firewalla szczególnie istotne są zdarzenia unikalne dla tej klasy urządzeń: zmiana stanu klastra HA, zestawienie lub zerwanie tunelu VPN oraz błędy aktualizacji sygnatur IPS i baz NGFW. Pozwalają one ustalić nie tylko co zmieniło się na urządzeniu, ale również kto dokonał zmiany.

Zdarzenia bezpieczeństwa¶

Jeżeli firewall wykorzystuje funkcje NGFW, rejestrowane powinny być również zdarzenia generowane przez mechanizmy takie jak:

• IPS
• kontrola aplikacji
• antywirus
• filtrowanie URL
• TLS inspection
• wykrywanie nieautoryzowanych tuneli lub proxy

Warto zwrócić szczególną uwagę na sytuacje, w których mechanizm bezpieczeństwa przestaje działać. Przykładowo brak nowych zdarzeń IPS nie musi oznaczać braku ataków. Może być również skutkiem wyłączenia profilu IPS z jednej z polityk.

Częste błędy¶

Firewalle są szczególnie narażone na powtarzalne błędy konfiguracyjne, które potrafią latami pozostawać niezauważone. Poniższe zestawienie obejmuje najczęstsze z nich:

• Reguły typu Any-Any - polityki zezwalające na cały ruch z dowolnego źródła do dowolnego celu omijają ideę filtrowania i stwarzają poważne ryzyko bezpieczeństwa. Każda reguła powinna precyzyjnie określać źródło, cel, port i protokół.
• Publicznie dostępny panel administracyjny - interfejs zarządzania firewallem (HTTPS/SSH) nie powinien być dostępny z Internetu. Dostęp do niego musi odbywać się wyłącznie z sieci wewnętrznej lub dedykowanego segmentu zarządczego.
• Wyłączony IPS „bo powodował false positives” - wyłączenie mechanizmów bezpieczeństwa z powodu fałszywych alarmów, bez wcześniejszego strojenia sygnatur, pozostawia sieć bez ochrony przed znanymi atakami. Zamiast wyłączania całego profilu IPS, należy uszczegółowić reguły lub przejść na tryb wykrywania.
• Brak inspekcji TLS „bo certyfikaty” - rezygnacja z dekodowania ruchu TLS z powodu problemów z certyfikatami CA pozostawia firewalla ślepego na większość współczesnych zagrożeń. Należy poprawnie wdrożyć zaufany certyfikat CA i skonfigurować wykluczenia dla usług, które tego wymagają.
• Brak testów failover HA - utworzenie klastra wysokiej dostępności bez okresowego testowania przełączenia daje fałszywe poczucie redundancji. Urządzenie zapasowe może przez miesiące nie być gotowe do przejęcia ruchu, a problem ujawnia się dopiero podczas awarii.
• Reguły tymczasowe, które zostały na lata - polityki dodane „na czas testów” lub „do końca tygodnia” pozostają w konfiguracji miesiącami lub latami, rozszerzając powierzchnię ataku. Reguły tymczasowe powinny mieć datę automatycznego wygaśnięcia.
• Zarządzanie z dowolnej stacji - logowanie administracyjne do firewalla z dowolnej stacji roboczej w sieci LAN, zamiast z dedykowanego segmentu zarządczego, zwiększa ryzyko przejęcia urządzenia w wyniku kompromitacji stacji roboczej.
• Brak dokumentacji reguł - reguły bez komentarza, bez zgłoszenia zmian i bez uzasadnienia powodują, że po odejściu administratora nikt nie wie, czy dana polityka nadal jest potrzebna.

Zasady bezpiecznego dostępu administracyjnego, ochrony paneli zarządzania oraz dedykowanych stacji roboczych opisano w artykule Konfiguracja bezpiecznego dostępu administratora

Dobre praktyki¶

Bezpieczna konfiguracja firewalla nie jest jednorazowym zadaniem wykonywanym podczas jego wdrożenia. Urządzenie wymaga ciągłego utrzymania wraz ze zmianami zachodzącymi w infrastrukturze.

W szczególności należy:

• regularnie przeglądać bazę reguł
• usuwać nieużywane i przesłonięte polityki
• ograniczać zakres nowych reguł do rzeczywistych potrzeb
• dokumentować powód wprowadzenia reguły
• kontrolować zmiany konfiguracji
• przechowywać kopie konfiguracji poza urządzeniem
• okresowo testować mechanizm HA
• kontrolować stan subskrypcji i aktualizacji sygnatur NGFW
• wyłączać nieużywane interfejsy oraz usługi
• ograniczać dostęp do panelu administracyjnego
• regularnie aktualizować firmware

Szczegółowe zasady ochrony dostępu administracyjnego, wykonywania kopii konfiguracji oraz aktualizacji urządzeń zostały opisane w artykule Hardening kanałów dostępu.

Firewall powinien być traktowany jako jeden z najbardziej uprzywilejowanych elementów infrastruktury. To przez niego przechodzi ruch pomiędzy strefami bezpieczeństwa, na nim często kończą się tunele VPN i to on egzekwuje znaczną część polityki dostępu. Z tego powodu błędna konfiguracja może być źródłem kompromitacji całej infrastruktury.

Ostatnia aktualizacja artykułu: 2026-09-02.