Pierwsza sprawa to forma, w jakiej możemy otrzymać WAF-a. Obecnie spotyka się trzy modele. Najbardziej typowy to appliance (także soft appliance) budowany bądź na ogólnodostępnym sprzęcie, bądź oparty na dedykowanym urządzeniu producenta. Drugi, rzadszy model, to oprogramowanie instalowane na serwerze aplikacyjnym lub pluginy - przykładem jest tutaj opensource’owy ModSecurity czy dodatkowe moduły instalowane jako dodatek do istniejących rozwiązań bezpieczeństwa. Wreszcie na fali popularności cloud computingu mamy również od pewnego czasu WAF-a z chmury. Wykorzystanie tego ostatniego wymaga rekonfiguracji naszych DNS-ów.
Kolejna kwestia to sposób implementacji rozwiązania. W zależności od producenta możemy mieć do dyspozycji kilka trybów. Łatwo zauważyć, że WAF-y implementowane są w sposób zbliżony do IPS-ów. Najczęściej spotykane są tutaj dwa modele - inline (w tym proxy) i monitoringu/offline (sniffing). Powiedzmy więc parę słów o każdym z nich.
Model Reverse Proxy
Wpięcie inline może być realizowane zarówno w L2 (często), jak i w L3 (rzadko). W przypadku wpięcia w L2 warto zwrócić uwagę czy rozwiązanie potrafi obsługiwać STP (Spanning-Tree Protocol). Wpięcie inline ma jedną niezaprzeczalną zaletę - nie jest wymagane wprowadzanie zmian w infrastrukturze. W tym trybie pewne funkcjonalności mogą nie być dostępne, np. podpisywanie cookie, terminowanie sesji SSL. Tryb inline to także konieczność ostrożnego doboru sprzętu tak, aby wpięcie dodatkowego rozwiązania nie powodowało nieakceptowalnego spadku wydajności. Ciągle jeszcze można spotkać się z obawami, co do tego modelu implementacji, dotyczącymi niezamierzonego blokowania prawidłowego ruchu. Dlatego też, jeżeli wybrano wdrożenie w trybie inline, poprzedza się je uruchomieniem rozwiązania w trybie monitoringu.
Drugim modelem jest stosowanie trybu reverse proxy. Ma on zauważalną na pierwszy rzut oka wadę, a mianowicie wymaga zmian adresacji. Standardowym przypadkiem wykorzystania rev-proxy jest konieczność zastosowania zaawansowanych mechanizmów, np. przepisywanie URL-i, podpisywanie (np. ciasteczek) czy terminowanie ruchu SSL. A skoro o terminowaniu ruchu mowa, to warto zwrócić uwagę, w jaki sposób zadanie to jest realizowane. Czy dane rozwiązanie wspiera inspekcję ruchu SSL w trybie inline? Czy deszyfrowanie jest realizowane programowo, czy za pomocą dedykowanej karty akcelerującej ten proces?
Model Monitor/Sniffer
Wreszcie zdarzają się przypadki, kiedy WAF jest wykorzystywany jako typowy mechanizm monitorujący, gdzie nie ma konieczności blokowania czegokolwiek (inaczej, niż we wcześniej opisanych przypadkach). Wtedy idealnie sprawdzi się wpięcie rozwiązania w trybie sniffingu. WAF otrzymuje wtedy ruch ze SPAN portu na przełączniku lub z TAP-a sieciowego. Jest to tryb, który nie wprowadza w zasadzie żadnego zamieszania w sieci.
Mówiąc o modelach wdrożenia, warto również zastanowić się, w jaki sposób zapewniona zostanie wysoka dostępność, co jest przy przypadku WAF-ów wpiętych inline krytyczne. Czy wystarczy wykorzystanie trybów fail-open/close interfejsów? Czy należy uwzględnić zastosowanie dodatkowych load-balancerów?
Bez względu na tryb nie zaszkodzi sprawdzić, czy rozwiązanie jest centralnie zarządzane w przypadku instalacji rozproszonych - tzw. distributed WAF (dWAF) i jak w takim przypadku elastyczne jest stosowanie reguł bezpieczeństwa.
