Vad är en WAF, och behöver din webbplats verkligen en?
En webbapplikationsbrandvägg låter som företagsöverdrift tills den dagen det tyst blockerar attacken som skulle ha förstört din vecka. Vad en WAF gör, vad den inte kan göra och vem behöver faktiskt en.
En WAF, eller webbapplikationsbrandvägg, inspekterar innehållet i inkommande HTTP-förfrågningar och blockerar de som matchar kända attackmönster – SQL-injektion, cross-site scripting, sökväg – innan de når din ansökan. Kör på kanten, det stoppar skadlig trafik innan det kostar dig något. Det är inte en ersättning för att skriva säker kod; det är ett lager framför den.
De flesta människor möter en WAF hur de möter sin hemförsäkring: efter att något redan har gått fel och vanligtvis önskar att de hade ställt upp det tidigare. Det är inte en glamorös egenskap. Det är dörrvakten vid dörren, kontrollerar varje begäran och vänder bort de som bär något skarpt.
Vad som skiljer en WAF från en vanlig brandvägg
En nätverksbrandvägg tänker i portar och IP-adresser: Tillåt 443, blockera det undernätet, gjort. Den har ingen aning om vad som finns inuti den trafik den tillåter, och den kan inte allt som kommer på port 443 ser identiskt ut från där den står.
En webbapplikationsbrandvägg fungerar ett lager upp, vid HTTP. Den läser webbadressen, frågesträngen, rubrikerna, cookies och begäran kroppen, och letar efter mönster angripare använder. Till ett nätverk brandvägg, GET /products?id=5 och GET /products?id=5' OR '1'='1 är samma begäran till samma port. Till en WAF de är mycket uppenbarligen inte.
Vad en WAF gör med en förfrågan
Tre möjliga domar, och den tredje är den som gör en WAF användbar snarare än irriterande.
Tillåt
Inget matchade. Begäran fortsätter till din ansökan som vanligt, utan mätbar fördröjning.
Blockera
Matchade ett känt attackmönster, eller kom från en förbjuden adress. Avslogs med en 403 innan din ansökan någonsin är inblandad.
Utmaning
Misstänkt men inte slutgiltigt dålig. Klienten uppmanas att bevisa att det är en riktig webbläsare - ett proof-of-work-pussel eller liknande - och fortsätter om det passerar. Så här hanterar du trafik du inte är säker på utan att blockera riktiga kunder.
Regeln bestämmer allt
En WAF utvärderar reglerna efter prioritet, och den första matchen vinner. Det är kraftfullt och mycket lätt att komma bakåt. En tillåta regel som sitter ovanför dina blockregler kommer gärna att vinka genom den exakta trafiken du skrev blockreglerna för att stoppa, och WAF kommer att rapportera sig som att fungera perfekt hela tiden.
Om din WAF "inte blockerar", kontrollera regelordning före något annat. En bred tillåt regel över dina blockregler är långt den vanligaste orsaken till att en attack passerar genom en brandvägg som är tekniskt påslagen.
Delen som ingen nämner: falska positiva
En WAF som aldrig har blockerat en legitim begäran är en WAF med dess regler nedåt. Spänningen är inneboende - du är mönstermatchande på text, och riktig text ser ibland ut som en attack.
De klassiska exemplen är värda att veta i förväg eftersom de kommer att hända dig. Ett CMS där en redaktör skriver en artikel om SQL-injektion, och spara den utlöser SQL-injektionsregeln. En form där någons efternamn innehåller en apostrof. En utvecklare klistrar in ett stackspår i en supportbiljett. En marknadsförings-URL med en ovanlig kodad parameter.
Därför bör alla WAF-installationer börja på samma sätt: Kör den i övervakningsläge först. Logga vad det skulle ha blockerat, lämna det i en vecka eller två av verklig trafik, läs sedan loggen. Du hittar två eller tre regler som behöver ett undantag för din specifika ansökan, och du hittar dem utan att ha spenderat den fjorton dagar avvisande kunder.
Edge WAF eller ursprung WAF
| Vid ditt ursprung | Vid kanten | |
|---|---|---|
| Där attackerna upphör | Efter att ha nått din server | Innan du når din server |
| Lastning från dålig trafik | Du betalar för allt | Kommer aldrig |
| Beteende under en översvämning | Kan vara överväldigad | Absorberas över hela nätverket |
| Ser dekrypterad begäran kropp | Ja. | Ja TLS slutar vid kanten |
| Gäller alla dina webbplatser på en gång | Per server | Per zon, centralt |
Ett ursprung WAF har redan förlorat bandbredd och CPU när det bestämmer sig för att avvisa något. Under en allvarlig automatiserad attack är det skillnaden mellan en filtrerad logglinje och en server som slutar svara.
Vad en WAF inte kommer att göra för dig
Värt att vara trubbig, eftersom WAF säljs som en säkerhetsstrategi och de är inte en.
- Det fixar inte sårbar kod. Det gör exploatering svårare, köper dig tid att lappa. Sårbarheten är fortfarande där.
- Det stoppar inte logiska brister. Om din kassa accepterar en negativ mängd, är varje begäran som gör det helt välformat HTTP.
- Det stoppar inte credential fyllning på egen hand. Ett inloggningsförsök med ett riktigt stulet lösenord ser exakt ut som en legitim inloggning. Det är hastighetsbegränsande och MFA-territorium.
- Den ersätter inte patchning. En virtuell patch vid kanten är ett användbart stopp för dagarna mellan avslöjande och distribution - inte ett permanent svar.
Behöver du en?
Om din webbplats är en statisk broschyr utan formulär, inga inloggningar och inget att stjäla, kan du rimligen vänta. När du accepterar användarinmatning, kör en inloggning, tar betalningar eller lagrar något du skulle hata att läcka, slutar en WAF vara valfri. Attackerna som blockeras är automatiserade och konstanta - skannrar undersöker din webbplats just nu för WordPress-sårbarheterna 2023, oavsett om du kör WordPress eller inte.
Vanliga frågor
Vad är en WAF?
En WAF, eller webbapplikationsbrandvägg, är ett säkerhetslager som inspekterar innehållet i inkommande HTTP-förfrågningar – webbadresser, rubriker, cookies och kroppsdata – och blockerar de som matchar kända attackmönster som SQL-injektion, cross-site scripting och path traversal. Till skillnad från en nätverksbrandvägg, som bara ser portar och IP-adresser, förstår en WAF programskiktet.
Vad är skillnaden mellan en WAF och en brandvägg?
En nätverksbrandvägg filtrerar trafiken efter port, protokoll och IP-adress och kan inte se vad som finns inuti de förfrågningar som den tillåter. En webbapplikationsbrandvägg fungerar på HTTP-lagret och inspekterar det faktiska innehållet i varje begäran. En nätverksbrandvägg ser två begäranden till port 443 som identiska även när en innehåller en SQL-insprutningsnytta; en WAF gör det inte.
Gör en WAF sakta ner min webbplats?
Knappt. Regelutvärdering på en modern kant WAF lägger vanligtvis till under en millisekund per begäran, vilket inte är märkbart bredvid nätverksfördröjning. En WAF som körs på CDN-kanten förbättrar vanligtvis den totala prestandan i praktiken, eftersom skadlig och automatiserad trafik avvisas innan den förbrukar någon ursprungskapacitet.
Kan en WAF blockera legitima besökare?
Ja, och det kommer det att göra om det används slarvigt. Falska positiv innebär vanligtvis innehåll som liknar attack syntax – en artikel om SQL-injektion, ett efternamn som innehåller en apostrof, en klistrad stack spår. Standardbegränsningen är att köra WAF i övervakningsläge i en vecka eller två först, granska vad det skulle ha blockerat och lägga till undantag innan de verkställs.
Behöver jag fortfarande säker kod om jag har en WAF?
Absolut. En WAF är ett filter framför din applikation, inte en fix för vad som finns inuti den. Det gör kända sårbarhetsklasser svårare att utnyttja och köper tid mellan ett avslöjande och din patch, men den underliggande felen förblir exploaterbar av alla förfrågningar som reglerna inte matchar. Behandla det som ett försvar på djupet, aldrig som ett substitut.
Behöver en liten webbplats en WAF?
Om den accepterar någon användarinmatning - en inloggning, ett kontaktformulär, en sökruta, ett kommentarfält - så ja. Attacker mot små webbplatser är nästan helt automatiserade och oriktade: skannrar sveper hela internet sonderande för kända sårbarheter och bryr sig inte om hur mycket trafik du får. En rent statisk webbplats utan formulär och ingen adminpanel är det enda fallet där det rimligen kan vänta.
En WAF läser inkommande förfrågningar och blockerar de skadliga innan de når din ansökan. Sätt det på kanten så dålig trafik aldrig kostar dig, börja i övervakningsläge så att du hittar dina falska positiva säkert, bry dig om din regelordning så att regler inte undergräver blockregler - och fortsätt patchning, eftersom en WAF Det handlar om tid istället för immunitet.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT - mestadels värd - sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till Vismas förvärv, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
