Web Application Firewall – når trenger du WAF?

En Web Application Firewall (WAF) inspiserer HTTP- og HTTPS-trafikk mellom brukeren og en nettjeneste. Den kan blokkere kjente angrepsmønstre, begrense misbruk av dyre endepunkter og kjøpe tid mens en sårbarhet rettes.

En WAF er ikke grunnleggende nødvendig for alle nettsteder. Verdien avhenger av hva nettstedet faktisk gjør, hvilke angrepsflater det har og om noen kan drifte reglene uten å blokkere legitim trafikk.

Start med arkitekturen

En enkel statisk side kan fortsatt rammes av DDoS, kompromittert byggekjede eller domenekapring. Men en regel mot SQL-injeksjon gir liten verdi når løsningen ikke har database eller dynamiske parametere.

Hva en WAF kan gjøre

Funksjonene varierer mellom produkter og abonnementer. Vanlige kapabiliteter er:

• administrerte regler for kjente mønstre og sårbarheter
• egne regler for ruter, parametere, metoder og størrelser
• ratebegrensning for innlogging, søk, skjema og API
• kontroll av bot- og automatiseringstrafikk
• begrensning etter klientegenskaper, token eller geografi
• logging av matchede regler og forespørsler
• midlertidig blokkering av en kjent sårbar forespørsel
• normalisering av ulike HTTP-kodinger før kontroll

En edge- eller skybasert WAF står vanligvis som reverse proxy foran origin. Andre varianter ligger i lastbalanserer, skyplattform, API-gateway eller som modul nær applikasjonen.

«WAF aktiv» sier lite uten å vite hvilke vertsnavn, protokoller, ruter og regler den faktisk dekker.

WAF er et kompensasjonstiltak, ikke kildekodefiks

En regel som stopper et bestemt sårbarhetsmønster kalles ofte en virtuell patch. Den kan redusere eksponeringen mens utviklerne retter applikasjonen, men den underliggende feilen finnes fortsatt.

En virtuell patch bør ha:

• sårbarhet eller hendelse den dekker
• berørte ruter og parametere
• testtilfeller for angrep og legitim bruk
• regel-ID og eier
• dato for innføring
• kobling til permanent retting
• utløps-/revisjonsdato
• kriterium for fjerning

OWASPs veiledning om virtual patching anbefaler blant annet loggmodus først, retest og sporing i normal patchprosess. En WAF-regel som blir stående etter at ingen husker hvorfor den finnes, er teknisk gjeld og en fremtidig feilkilde.

Dette stopper en WAF ikke pålitelig

En WAF ser trafikken den får og tolker den med tilgjengelige regler. Den kan ikke alene løse:

• stjålne eller svake innloggingsopplysninger
• for brede bruker- og administratorrettigheter
• legitimt formaterte misbruk av forretningslogikk
• feil der en bruker får tilgang til en annen brukers objekt
• sårbar kode som nås utenom WAF-en
• kompromittert CMS-konto eller byggepipelinen
• sårbarheter i e-post, DNS, klient eller interne systemer
• ondsinnet tredjepartsskript som allerede er godkjent
• datalekkasje gjennom funksjoner applikasjonen bevisst tilbyr
• volumangrep som overstiger kapasiteten før WAF-kontrollen

Noen produkter kan oppdage deler av disse scenarioene med tilpassede signaler, men ikke anta dekning fra et generelt «OWASP ruleset».

Den vanligste arkitekturfeilen er en åpen origin

Hvis domenet går gjennom WAF-en, men origin-serverens IP fortsatt kan nås direkte fra internett, kan en angriper hoppe over reglene.

Vurder flere kontroller:

• begrens origin til trafikk fra proxy-/plattformlaget
• bruk autentisert forbindelse eller klientsertifikat der plattformen støtter det
• valider en plattformidentitet, ikke bare et lett kopierbart headerfelt
• fjern gamle DNS-poster som avslører aktiv origin
• hold origin-sertifikat og vertsnavn korrekt
• overvåk direkte treff og avvisninger
• planlegg administrativ nødtilgang uten å åpne tjenesten globalt

En liste over leverandør-IP-er må oppdateres sikkert. Hvis en blokkering blir utdatert, kan den enten åpne for bypass eller stanse all legitim trafikk.

Krypter også fra WAF til origin

HTTPS i nettleseren garanterer ikke at neste etappe er kryptert. Ved TLS-terminering i WAF-en oppstår en ny forbindelse til origin.

Kontroller:

• TLS mellom edge og origin
• sertifikatvalidering og korrekt vertsnavn
• moderne protokollvalg etter plattformens støtte
• hvordan klient-IP og protokoll formidles uten å stole på vilkårlige headere
• om sensitive headere og cookies kan logges

Ikke velg «fleksibel» eller ukryptert origin-forbindelse bare for å få et grønt hengelåsikon foran brukeren.

Kartlegg før regler slås på

Lag en oversikt over:

• alle offentlige vertsnavn
• ruter og HTTP-metoder
• innlogging, passordreset og registrering
• søk, skjema, filopplasting og webhooker
• API-versjoner og klienttyper
• forventet forespørsels- og svarstørrelse
• WebSocket, server-sent events og andre langvarige forbindelser
• administrator- og integrasjonsruter
• normal trafikk, topper og sesongvariasjon
• data som ikke må havne i logger

En regel om at «POST ikke er tillatt» er fin på en ren statisk rute, men bryter skjema, webhooker og API hvis den legges globalt.

En kontrollert utrulling

1. Etabler målinger og testsett

Før WAF-en endrer trafikken, lag tester for:

• innlogging med gyldig og ugyldig input
• søk med tegn brukerne faktisk skriver
• opplasting av tillatte filtyper og størrelser
• API-kall fra alle støttede klientversjoner
• webhooker med gyldig signatur
• tilgjengelighets- og betalingsflyt der det er relevant

Mål statuskoder, responstid, feilrate og forretningsutfall.

2. Start i logg- eller simuleringsmodus

La reglene observere en representativ driftsperiode. «Noen dager» er ikke alltid nok; månedlig fakturering, sjeldne administratorhandlinger og sesongtrafikk må dekkes.

Loggmodus beskytter ikke mot angrepet. Bruk den til kalibrering, og ha andre kontroller på plass under perioden.

3. Aktiver regelgrupper i små trinn

Begynn med regler der forventet falsk-positiv-risiko er lav og konsekvensen er forstått. Følg feilrate og kundereise etter hver endring.

4. Lag smale unntak

Hvis en legitim forespørsel blokkeres, unnta:

• riktig vertsnavn
• nøyaktig rute
• bestemt parameter eller innholdstype
• relevant regel-ID

Ikke slå av en hel angrepskategori globalt fordi én rute trenger et spesialtegn.

5. Test bypass og feilmodus

Kontroller:

• direkte tilgang til origin
• alternative porter og vertsnavn
• IPv4 og IPv6
• store/komprimerte eller uvanlig kodede forespørsler
• hva som skjer når WAF-leverandøren eller loggsystemet er nede
• om feil konfigurasjon kan rulles tilbake uten lang nedetid

6. Sett eier og vakt

Noen må kunne svare på alarm, falsk positiv og leverandørendring. En WAF uten operativt ansvar kan bli enten støy eller et skjult driftskritisk ledd.

Ratebegrens handlingen, ikke bare IP-en

IP-basert ratebegrensning er enkelt, men mange legitime brukere kan dele bedriftsnett eller mobiloperatør. Angripere kan fordele trafikken over mange IP-er.

Kombiner der det er mulig:

• konto eller sesjon
• API-nøkkel eller klientidentitet
• rute og operasjonens kostnad
• enhet-/bot-signal
• IP og nettverk
• tidligere feil og suksess

På innlogging bør begrensning hindre passordangrep uten at en angriper enkelt kan låse alle kontoene. På kontaktskjema bør den kombineres med validering, kø, misbruksvern og kontrollert ressursbruk.

Se rate limiting uten å blokkere brukerne for en avgrenset modell.

WAF og DDoS er ikke det samme

En WAF analyserer applikasjonsforespørsler. DDoS-beskyttelse kan også måtte håndtere nettverks- og transportvolum før forespørselen kan inspiseres.

Spør leverandøren:

• hvilke protokoller og lag som dekkes
• om origin er skjult og beskyttet
• kapasitets- og rategrenser
• hva som skjer ved langvarig angrep
• om kostnader kan løpe på selv om trafikken blokkeres
• hvordan hendelser varsles og dokumenteres

Les DDoS-beskyttelse etter arkitektur før WAF og volumvern behandles som én funksjon.

Logger kan inneholde hemmeligheter

WAF-en ser ofte URL-er, headere, cookies og deler av forespørselskroppen. Uten kontroll kan loggene fange:

• sesjonstokens og API-nøkler
• personopplysninger i skjema
• passord eller reset-token
• filinnhold
• interne vertsnavn og feildetaljer

Definer:

• hvilke felter som maskeres før lagring
• tilgang til loggene
• lagringssted og underleverandører
• oppbevaringstid og sletting
• integritet og eksport
• sammenheng med applikasjons- og origin-logger

OWASPs loggingveiledning understreker at loggdata er utrygge input, må beskyttes mot injeksjon og ikke bør inneholde unødvendige hemmeligheter.

Slik vurderer du et WAF-produkt

Kjør en prøve med egen normaltrafikk og egne misbrukstilfeller. Et markedsført antall «blokkerte angrep» sier ikke om produktet reduserte virksomhetens risiko.

Hendelse og etterarbeid

Ved en mulig webhendelse:

1. bevar WAF-, edge-, origin- og applikasjonslogger
2. identifiser hva som ble blokkert og hva som kan ha passert
3. undersøk applikasjon, data og kontoer—ikke bare regelutslaget
4. begrens angrepet med smal regel eller funksjonsstans
5. rett sårbarheten i kode eller konfigurasjon
6. test både permanent retting og WAF-regel
7. fjern midlertidige regler når kriteriene er oppfylt
8. oppdater tester, overvåking og beredskap

Et stort antall WAF-varsler er ikke i seg selv bevis på kompromittering. Fravær av varsler er heller ikke bevis på at ingenting skjedde.

Hva gjelder for Vymos standardnettside?

Vymos standardtilbud er én enkel bedriftsside som Vymo setter opp og hoster. Kunden får ikke et selvbetjent WAF-panel eller egne WAF-regler som del av det publiserte standardtilbudet, og Vymo lover ikke en bestemt WAF-leverandør.

For en enkel informasjons- eller kontaktside er redusert funksjonsflate, sikker hosting, kontrollert skjemaendepunkt og god domeneadministrasjon ofte viktigere enn at kunden kjøper og forvalter en separat WAF.

Har virksomheten innlogging, API, filopplasting, nettbutikk eller særskilte trafikk-/loggkrav, må dette avklares som en annen leveranse. Beskriv ruter, data, normaltrafikk og trusselkrav før dere bestiller. Ikke anta at slike funksjoner er inkludert i den gratis enkle nettsiden .