zapora nowej generacji

Zapora nowej generacji (next-generation firewall, NGFW) to zapora sieciowa, która oprócz filtrowania adresów i portów rozpoznaje aplikacje, użytkowników i protokoły oraz dokładniej analizuje przesyłane dane. CERT Polska opisuje to tak: tradycyjne zapory decydowały głównie na podstawie adresu źródłowego, docelowego, protokołu i portu, a zapory klasy NGFW potrafią identyfikować aplikacje, użytkowników i protokoły niezależnie od używanego portu ^[1]. W jednym urządzeniu łączą zwykle filtrowanie stanowe, kontrolę aplikacji, IPS i inspekcję ruchu szyfrowanego ^[1].

Jak działa

Punktem wyjścia jest obserwacja, że port przestał wystarczać do opisu usługi. CERT Polska zauważa, że wiele aplikacji komunikuje się przez HTTPS na porcie TCP 443, więc dopuszczenie tego portu nie oznacza zgody na jedną konkretną usługę ^[1]. Tym samym kanałem idą przeglądanie stron, komunikatory, przechowywanie plików, narzędzia zdalnego dostępu i VPN-y działające w warstwie aplikacji ^[1]. Zapora z identyfikacją aplikacji analizuje cechy protokołu i rozpoznaje faktycznie używaną usługę ^[1].

Kolejne mechanizmy działają jeden po drugim na tym samym połączeniu, co pokazuje schemat poniżej.

RYS. 1Ścieżka połączenia przez NGFW

Inspekcja TLS jest potrzebna, bo bez odszyfrowania zapora widzi tylko część informacji o połączeniu, a nie jego treść ^[1]. Urządzenie zestawia wtedy dwa niezależne połączenia: odszyfrowuje ruch, analizuje go i szyfruje ponownie ^[1]. Dla ruchu wychodzącego wymaga to zwykle zainstalowania na komputerach zaufanego certyfikatu urzędu certyfikacji zapory; bez niego przeglądarka zgłosi błąd certyfikatu ^[1]. Technicznie jest to kontrolowany man-in-the-middle (MITM).

Składniki

Pojęcie NGFW nie ma jednej normy; to raczej zestaw funkcji, które rozwijały się osobno. NIST w wytycznych z 2009 roku opisywał już zapory aplikacyjne, czyli zapory stanowe z analizą protokołów, przez część producentów nazywaną głęboką inspekcją pakietów ^[2]. Opisywał też systemy UTM, łączące zaporę, wykrywanie złośliwego oprogramowania i blokowanie podejrzanych skanów ^[2], oraz polityki oparte na tożsamości użytkownika ^[2].

IPS różni się od klasycznego IDS tym, że pracuje bezpośrednio w ścieżce ruchu i może sam zablokować połączenie ^[1]. Jego skuteczność zależy od aktualności sygnatur ^[1]. NIST zastrzegał, że zapora z analizą protokołów nie jest pełnym systemem wykrywania i zapobiegania włamaniom ^[2].

W WordPressie

NGFW chroni sieć, a nie konkretną aplikację. Strona WordPress styka się z nią w dwóch miejscach. Pierwsze to brzeg sieci firmy hostingowej albo własnej serwerowni, gdzie zapora filtruje ruch do serwera WWW i może blokować sygnaturami IPS znane exploity. Drugie to sieć firmowa redaktorów: jeśli firma stosuje inspekcję TLS ruchu wychodzącego, połączenia z panelem wp-admin też są odszyfrowywane na zaporze.

Do ochrony samej aplikacji dokumentacja WordPressa wskazuje co innego: wtyczki działające jak zapora, WAF na serwerze, na przykład ModSecurity, oraz usługi zapory działające jako reverse proxy przed serwerem ^[7]. WAF rozumie żądania HTTP i parametry formularzy, a IPS w NGFW szuka głównie wzorców ataków w ruchu sieciowym ^[1]. Te warstwy uzupełniają się, ale jedna nie zastępuje drugiej.

Przy inspekcji TLS przychodzącego ruchu na stronę trzeba pamiętać, że zapora widzi wtedy hasła logowania i tokeny sesyjne w postaci jawnej. CERT Polska przypomina też, że deszyfrowanie niektórych kategorii ruchu, na przykład bankowości elektronicznej, może być niezgodne z prawem lub przepisami wewnętrznymi ^[1].

Zagrożenia i skutki

Zapora brzegowa jest sama celem ataku. CERT Polska wskazuje, że ma dostęp do wielu segmentów sieci, przetwarza znaczną część ruchu i udostępnia usługi bezpośrednio z internetu, często także VPN; jej przejęcie prowadzi często do kompromitacji całej infrastruktury ^[1]. Dlatego panele administracyjne zapór nie powinny być dostępne publicznie ^[6].

Rozbudowa funkcji zwiększa powierzchnię ataku samego urządzenia. Brama VPN, portal logowania i parsery protokołów to kod, w którym bywają błędy. Część z nich to podatności wykorzystywane bez uwierzytelnienia, prowadzące do zdalnego wykonania kodu.

Wydajność to drugi problem. Inspekcja TLS należy do najbardziej obciążających funkcji; przepustowość podawana dla zwykłego filtrowania może być wielokrotnie wyższa niż przy jednoczesnym użyciu inspekcji TLS, IPS i kontroli aplikacji ^[1].

Dobre praktyki

• Włączaj tylko te mechanizmy, które wynikają z rzeczywistych potrzeb danego segmentu ^[1].
• Nowe profile IPS obserwuj najpierw w trybie wykrywania, a do blokowania przełączaj po analizie wyników; zmniejsza to liczbę fałszywych alarmów ^[1].
• Nie włączaj wszystkich sygnatur dla całego ruchu: kontrola technologii, której w sieci nie ma, nie zwiększa bezpieczeństwa ^[1].
• Inspekcję TLS planuj z wyłączeniami, między innymi dla aplikacji z przypinaniem certyfikatów ^[1].
• Aktualizuj oprogramowanie urządzenia i nie wystawiaj panelu zarządzania do internetu ^{[1] [6]}.

Historia i przykłady

Zapory brzegowe wielokrotnie padały ofiarą krytycznych podatności. 12 kwietnia 2024 roku Palo Alto Networks opublikowało komunikat o CVE-2024-3400 w funkcji GlobalProtect systemu PAN-OS, z oceną 10 w skali istotności ^[3]. Błąd pozwalał nieuwierzytelnionemu napastnikowi wykonać dowolny kod z uprawnieniami roota na zaporze ^[3]. Dotyczył wersji 10.2, 11.0 i 11.1 z włączoną bramą lub portalem GlobalProtect ^[3]. Był to przypadek wstrzyknięcia poleceń systemu operacyjnego ^[3].

13 grudnia 2022 roku CERT Polska ostrzegał przed CVE-2022-42475 w module SSL-VPN systemu FortiOS firmy Fortinet ^[4]. Podatność pozwalała na zdalne wykonanie kodu bez uwierzytelniania i była aktywnie wykorzystywana, zanim ją ujawniono ^[4], co czyni ją przykładem podatności zero-day.

Problemem bywa też sprzęt. Sekurak 3 lutego 2025 roku opisał badanie firmy Eclypsium, która w trzech modelach zapór Palo Alto znalazła znane od lat podatności w oprogramowaniu rozruchowym i UEFI, między innymi BootHole (CVE-2020-10713) ^[5]. To przypomnienie, że aktualizacje firmware dotyczą także urządzeń bezpieczeństwa.