Hvad er en WAF, og har dit websted virkelig brug for en?
En webapplikations firewall lyder som enterprise overkill, indtil den dag det stille blokerer det angreb, der ville have ødelagt din uge. Hvad en WAF gør, hvad det ikke kan gøre, og hvem har faktisk brug for en.
En WAF eller webapplikationsfirewall inspicerer indholdet af indgående 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 mål. ansøgning. 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ørmanden ved døren, der kontrollerer hver anmodning og vender væk dem, 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, bloker det undernet, gjort. Det har ingen idé om, hvad der er inde i den trafik, det tillader, og det kan ikke alt, hvad der ankommer på port 443, ser identisk ud fra, hvor det står.
En webapplikations firewall virker et lag op, 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 er den samme anmodning til den samme havn. Til en WAF er de meget tydeligvis 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 rasende.
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ænkelig, men ikke entydigt dårlig. Klienten bliver bedt om at bevise, at det er en rigtig browser - et proof-of-work-puslespil eller lignende - og fortsætter, hvis det passerer. Sådan håndterer du trafik, 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 let at komme bagud. 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 fungerende perfekt hele tiden.
Hvis din WAF "ikke blokerer", skal du kontrollere regelrækkefølgen før noget andet. En bred tilladelsesregel over dine blokregler er langt den mest almindelige årsag til, at et angreb passerer gennem en firewall, der er teknisk slået til.
Den del 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 iboende - du er mønster-matching 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-indsprøjtning, og gemmer den, udløber SQL-indsprøjtningsreglen. En formular, hvor en persons efternavn indeholder en apostrof. En udvikler indsætter et stakspor i en supportbillet. En marketing URL med en usædvanlig kodet parameter.
Derfor bør alle WAF-implementeringer starte på samme måde: Kør det i overvågningstilstand først. Log hvad det ville have blokeret, lad det stå i en uge eller to af reel trafik, og læs derefter logfilen. 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.
Edge WAF eller oprindelse WAF
| Ved din oprindelse | På kanten | |
|---|---|---|
| Hvor angrebene stopper | Efter at have nået din server | Før du når din server |
| Belastning fra dårlig trafik | Du betaler for det hele | Kommer aldrig |
| Adfærd under en oversvømmelse | Kan blive overvældet | Absorberet på tværs af netværket |
| Ser dekrypteret anmodningstekst | Ja. | Ja TLS slutter ved kanten |
| Gælder for alle dine websteder på én gang | Per server | Per zone, centralt |
En oprindelse WAF har allerede mistet båndbredde og CPU ved den tid, det beslutter at afvise noget. Under en alvorlig automatiseret angreb, der er forskellen mellem en filtreret log linje 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 udnyttelse sværere, køber dig tid til at patche. 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 login forsøg med en rigtig stjålet adgangskode ligner nøjagtigt et legitimt login. Det er satsbegrænsende og MFA territorium.
- Det erstatter ikke patching. En virtuel patch på 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 brugerindtastning, kører et login, tager betalinger eller gemmer noget, du ville hade at lække, stopper 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 indkommende HTTP-anmodninger – URL-adresser, overskrifter, cookies og kropsdata – og blokerer de tilsvarende kendte angrebsmønstre, 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 applikationslaget.
Hvad er forskellen mellem en firewall og en WAF?
En netværksfirewall filtrerer trafik efter port, protokol og IP-adresse og kan ikke se, hvad der er inde i de anmodninger, den tillader. En webapplikations firewall fungerer 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 ikke.
Er en WAF bremse min hjemmeside?
Knap nok. Regelevaluering på en moderne kant WAF tilføjer typisk under et millisekund pr. Forespørgsel, hvilket ikke er mærkbart ved siden af netværksforsinkelse. 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, hvis de anvendes skødesløst. Falske positiver involverer typisk indhold, der ligner angrebssyntaks – en artikel om SQL-indsprøjtning, et efternavn, der indeholder en apostrof, et indsat stakspor. Den standard afbødning 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?
Helt sikkert. En WAF er et filter foran din ansøgning, ikke en løsning på, hvad der er inde i den. 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 brugerinput - et login, en kontaktformular, et søgefelt, et kommentarfelt - så ja. Angreb mod små websteder er næsten helt automatiseret og umålrettet: scannere feje hele internettet sondering for kendte sårbarheder og er ligeglad med, hvor meget trafik du får. Et rent statisk websted uden formularer og ingen admin panel er det ene tilfælde, hvor det med rimelighed kan vente.
En WAF læser indgående anmodninger og blokerer de ondsindede, før de når din ansøgning. 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 i IT - for det meste hosting - 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, sikker infrastruktur enkel at bruge.
