Ale przecież filtrowanie ruchu tego typu to nic nowego. Od czego rozwiązania klasy Web Security? Problem w tym, że takie narzędzia koncentrują się na ruchu webowym, oczywiście włączając w to komunikatory i typowe narzędzia Web 2.0. NGFW wykraczają dużo dalej poza możliwości nawet najbardziej zaawansowanych narzędzi Web Security. Na razie nie ma więc mowy o pełnym nakładaniu się tych dwóch obszarów. Można jednakże założyć, że wcześniej czy później taka konwergencja nastąpi.

Co jeszcze umieszczono w pudełku NGFW? Podobnie jak w tradycyjnych zaporach, istnieje możliwość sterowania priorytetem ruchu na bazie mechanizmów QoS, tym razem jednak dla konkretnych aplikacji. Niektóre rozwiązania dodają także funkcje kojarzone z UTM, tj. ochronę przed malwarem. W przypadku NGFW, jeżeli już mamy wykorzystywać taką funkcjonalność, to dobrze, żeby stosowane były mechanizmy badania reputacji dla aplikacji, a nie tylko został dołączony zwykły silnik antywirusowy.

Białe listy, ale czy na pewno?

Uwzględniając wymienione już uwarunkowania, można dojść do wniosku, że ogólne założenia funkcjonowania NGFW niewiele różnią się od tradycyjnych firewalli. Nie jest to jednak takie oczywiste. Administrując zaporami, przywykliśmy do powszechnego stosowania zasady whitelistingu, która opiera się na blokowaniu wszystkiego, co nie jest dozwolone. Takie podejście pozwala na zachowanie maksymalnej szczelności. Jest jednak jedno "ale", komplikujące proces ochrony. Wraz z upływem czasu lista reguł bezpieczeństwa rośnie i bardzo często może sięgnąć poziomu kilkuset pozycji. Dobry administrator firewalla wie, że gdy liczba reguł przekracza 100 - trudno mówić o sprawnym zarządzaniu. Wiele reguł to także znaczne obciążenie rozwiązania, ogólny spadek jego wydajności i większa szansa na popełnienie błędu. W przypadku NGFW może być znacznie gorzej. Zamiast jednej reguły "Zezwalaj na HTTP/HTTPS", możemy mieć ich setki, osobne dla każdej aplikacji webowej. Tutaj cała nadzieja w dobrym planowaniu albo… w powrocie do idei blacklistingu. W odniesieniu do aplikacji webowych znacznie łatwiej powiedzieć, co jest dozwolone, a resztę zablokować, niż odwrotnie. Zwrócenie się ku czarnym listom zbliżałoby nas do modelu wykorzystywanego chociażby we wspomnianych platformach Web Security. Ale może nic w tym złego? Wybór podejścia jest zatem jedną z pierwszych decyzji, którą będziemy musieli podjąć, zanim w ogóle zastanowimy się nad wyborem konkretnego rozwiązania NGFW.

O co pytać?

Jeżeli spojrzymy na listę funkcjonalności, którymi chwalą się producenci, to na ich niedobór nie możemy narzekać. Należy jednak pamiętać, że pomysł na NGFW jest stosunkowo świeży, a uzyskanie wydajności wymaganych przez obecne sieci na poziomie kilku gigabitów wymaga umiejętnego połączenia odpowiedniego sprzętu z oprogramowaniem. Na co więc zwracać szczególną uwagę? Można na początek zadać kilka pytań, pamiętając, że nie należy wierzyć ulotkom firmowym, lecz testom przeprowadzonym we własnej sieci, oraz że nie każdy produkt zasługuje na miano NGFW.

Zacznijmy od sprzętu. Rynek idzie w kierunku wykorzystywania standardowych komponentów, co ma swoje zalety (zwłaszcza ekonomiczne). Niemniej jednak w NGFW, gdzie liczy się wydajność, dobrym podejściem jest budowanie urządzeń dedykowanych. Mówiąc o wydajności, sprawdźmy, jaka jest, gdy wszystkie moduły ochronne zostaną włączone, i czy wtedy faktycznie osiągniecie podanych przez producenta 10 Gb/s jest realne? Jak pokazuje doświadczenie z rynku UTM-ów, włączenie IPS-a powoduje spadek wydajności o ok. 60%. Przykładowo, wydajność zapory 10 Gb spada 3-4 Gb/s przy włączonym IPS-ie, a przy dodatkowo uruchomionym module AV - 300-400 Mb/s. Potwierdzają to zresztą testy NSS Labs. Należy się spodziewać, że podobne niedoskonałości występują w rozwiązaniach pracujących na standardowym sprzęcie. Na wydajność ma również wpływ liczba skonfigurowanych reguł, co także warto uwzględnić w testach.