Hvad er en WAF, og har dit websted virkelig brug for en?
En firewall til webapplikationer lyder som en overdrivelse af virksomheden, indtil den stille og roligt blokerer det angreb, der ville have ødelagt din uge. Hvad en WAF gør, hvad den ikke kan gøre, og hvem der faktisk har brug for en.
En WAF- eller webapplikationsfirewall inspicerer indholdet af indkommende HTTP-anmodninger og blokerer dem, der matcher kendte angrebsmønstre – SQL-indsprøjtning, cross-site scripting, sti-gennemløb – før de når dit anvendelse. Kør på kanten, det stopper skadelig trafik, før det koster dig noget. Det er ikke en erstatning for at skrive sikker kode; det er et lag foran det.
De fleste mennesker mødes en WAF den måde, de opfylder deres hjem forsikring: efter noget er allerede gået galt, og normalt ønsker de havde sat det op før. Det er ikke et glamourøst træk. Det er dørklokken ved døren, der kontrollerer alle anmodninger og vender dem væk, der bærer noget skarpt.
Hvad adskiller en WAF fra en almindelig firewall?
En netværksfirewall tænker i porte og IP-adresser: Tillad 443, blokér det pågældende undernet, færdigt. Det har ingen idé om, hvad der er inde i den trafik, det tillader, og det kan det ikke - alt, hvad der ankommer på port 443, ser identisk ud fra, hvor det står.
En firewall til webapplikationer fungerer et lag opad, ved HTTP. Den læser URL'en, forespørgselsstrengen, overskrifterne, cookies og anmodningskroppen og ser efter de mønstre, angribere bruger. Til en netværksfirewall, GET /products?id=5 og GET /products?id=5' OR '1'='1 Det er den samme anmodning til den samme havn. For en WAF er de helt klart ikke.
Hvad en WAF gør med en anmodning
Tre mulige domme, og den tredje er den, der gør en WAF brugbar snarere end irriterende.
Tillad
Intet matchede. Anmodningen fortsætter til din ansøgning som normalt, uden målbar forsinkelse.
Blokér
Matchede et kendt angrebsmønster, eller kom fra en forbudt adresse. Afvist med en 403, før din ansøgning nogensinde er involveret.
Udfordring
Mistænkeligt, men ikke entydigt dårligt. Klienten bliver bedt om at bevise, at det er en rigtig browser – et proof-of-work-puslespil eller lignende – og fortsætter, hvis det går igennem. Sådan håndterer du trafik, som du ikke er sikker på, uden at blokere rigtige kunder.
Regelorden bestemmer alt
En WAF evaluerer reglerne efter prioritet, og den første kamp vinder. Det er kraftfuldt og meget nemt at komme baglæns. En tilladelsesregel, der sidder over dine blokregler, vil med glæde vinke gennem den nøjagtige trafik, du skrev blokreglerne for at stoppe, og WAF vil rapportere sig selv som at fungere perfekt hele tiden.
Hvis din WAF ikke blokerer, skal du kontrollere regelrækkefølgen før alt andet. En bred tilladelsesregel over dine blokregler er langt den mest almindelige årsag til, at et angreb passerer gennem en firewall, der teknisk er tændt.
Den del, som ingen nævner: falske positive
En WAF, der aldrig har blokeret en legitim anmodning, er en WAF med sine regler slået ned for langt. Spændingen er indbygget – du matcher mønstre på tekst, og ægte tekst ligner nogle gange et angreb.
De klassiske eksempler er værd at vide på forhånd, fordi de vil ske for dig. Et CMS, hvor en editor skriver en artikel om SQL-injektion, og gemme det ture SQL-injektion regel. En formular, hvor en persons efternavn indeholder en apostrof. En udvikler, der indsætter et stakspor i en supportsag. En marketingwebadresse med en usædvanlig kodet parameter.
Derfor bkøre det i overvågningstilstand først. Log hvad det ville have blokeret, lad det stå i en uge eller to af ægte trafik, og læs derefter loggen. Du vil finde to eller tre regler, der har brug for en undtagelse for din specifikke ansøgning, og du vil finde dem uden at have brugt den fjorten dage afvise kunder.
Kant WAF eller oprindelse WAF
| Ved din oprindelse | På kanten | |
|---|---|---|
| Hvor angrebene stopper | Når du har nået din server | Før du når frem til din server |
| Lastning fra dårlig trafik | Du betaler for det hele | Kommer aldrig |
| Opførsel under en oversvømmelse | Kan blive overvældet | Absorberet på tværs af netværket |
| Ser dekrypteret anmodningstekst | Ja, ja | Ja TLS slutter ved kanten |
| Gælder for alle dine websteder på én gang | Pr. server | Pr. zone, centralt |
En oprindelse WAF har allerede mistet båndbredde og CPU ved den tid, det beslutter at afvise noget. Under et alvorligt automatiseret angreb er det forskellen mellem en filtreret loglinje og en server, der holder op med at reagere.
Hvad en WAF ikke vil gøre for dig
Værd at være stump, fordi WAF'er bliver solgt som en sikkerhedsstrategi, og de er ikke en.
- Det løser ikke sårbar kode. Det gør udnyttelsen sværere og giver dig tid til at reparere. Sårbarheden er der stadig.
- Det stopper ikke logiske fejl. Hvis din checkout accepterer en negativ mængde, er hver anmodning, der gør det, perfekt velformet HTTP.
- Det stopper ikke legitimation udfyldning af sig selv. Et loginforsøg med en rigtig stjålet adgangskode ligner nøjagtigt et legitimt login. Det er satsbegrænsende og MFA område.
- Den erstatter ikke lappemateriale. En virtuel programrettelse ved kanten er et nyttigt mellemrum for dagene mellem afsløring og din implementering – ikke et permanent svar.
Har du brug for en?
Hvis dit websted er en statisk brochure uden formularer, ingen logins og intet at stjæle, kan du med rimelighed vente. I det øjeblik du accepterer brugerinput, kører et login, tager imod betalinger eller gemmer noget, du ville hade at lække, ophører en WAF med at være valgfri. De angreb, det blokerer, er automatiserede og konstante - scannere undersøger dit websted lige nu for WordPress sårbarheder i 2023, uanset om du kører WordPress eller ej.
Ofte stillede spørgsmål
Hvad er en WAF?
En WAF eller webapplikationsfirewall er et sikkerhedslag, der inspicerer indholdet af indgående HTTP-anmodninger – URL-adresser, overskrifter, cookies og kropsdata – og blokerer de tilsvarende kendte angrebsmønstre som f.eks. SQL-indsprøjtning. cross-site scripting og path traversal. I modsætning til en netværksfirewall, som kun ser porte og IP-adresser, forstår en WAF programlaget.
Hvad er forskellen mellem en firewall og en WAF?
En netværksfirewall filtrerer trafikken efter port, protokol og IP-adresse og kan ikke se, hvad der er inden for de anmodninger, den tillader. En webapplikations firewall opererer på HTTP-laget og inspicerer det faktiske indhold af hver anmodning. En netværksfirewall ser to anmodninger til port 443 som identiske, selv når en indeholder en SQL-indsprøjtning nyttelast; en WAF gør det ikke.
Gør en WAF min hjemmeside langsommere?
Knap nok. Regelevaluering på en moderne WAF tilføjer typisk under et millisekund pr. anmodning, hvilket ikke er mærkbart ud for netværkets ventetid. En WAF, der kører på CDN-kanten, forbedrer normalt den samlede ydeevne i praksis, fordi ondsindet og automatiseret trafik afvises, før den bruger nogen oprindelseskapacitet.
Kan en WAF blokere legitime besøgende?
Ja, og det vil det gøre, hvis det bliver anvendt uforsigtigt. Falske positiver involverer typisk indhold, der ligner angrebssyntaks – en artikel om SQL-indsprøjtning, et efternavn, der indeholder en apostrof, et indsat stakspor. Standarden modvirkning er at køre WAF i overvågningstilstand i en uge eller to først, gennemgå, hvad det ville have blokeret, og tilføje undtagelser, før håndhæve.
Har jeg stadig brug for sikker kode, hvis jeg har en WAF?
Bestemt. En WAF er et filter foran din applikation, ikke en løsning på, hvad der er indeni. Det gør kendte sårbarhedsklasser sværere at udnytte og køber tid mellem en afsløring og din patch, men den underliggende fejl forbliver udnyttes af enhver anmodning, som reglerne ikke matcher. Behandl det som et forsvar i dybden, aldrig som en erstatning.
Har en lille hjemmeside brug for en WAF?
Hvis den accepterer input fra brugeren – et login, en kontaktformular, et søgefelt, et kommentarfelt – så ja. Angreb mod små websteder er næsten helt automatiseret og uden målretning: scannere fejer hele internettet for kendte sårbarheder og er ligeglad med, hvor meget trafik du får. Et rent statisk websted uden formularer og uden administrationspanel er det eneste tilfælde, hvor det med rimelighed kan vente.
En WAF læser indgående anmodninger og blokerer de skadelige anmodninger, før de når dit program. Sæt det på kanten, så dårlig trafik aldrig koster dig, start i overvågningstilstand, så du finder dine falske positiver sikkert, pas på din regelordre, så tillad regler ikke underminerer blokregler - og hold patching, fordi en WAF Tid i stedet for immunitet.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
