Vad är en WAF, och behöver din webbplats verkligen en?
En brandvägg för webbapplikationer låter som en överdrift tills den dagen den tyst blockerar attacken som skulle ha förstört din vecka. Vad en WAF gör, vad den inte kan göra och vem som faktiskt behöver 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 i kanten, det stoppar skadlig trafik innan det kostar dig någonting. 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 satt upp det tidigare. Det är inte ett glamoröst inslag. Det är dörrvakten vid dörren, som 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: låt 443, blockera det undernätet, klart. Den har ingen aning om vad som finns inuti den trafik den tillåter, och den kan inte göra det – allt som anländer till hamn 443 ser identiskt ut från där det står.
En brandvägg för webbprogram fungerar ett lager uppåt, vid HTTP. Det läser URL, frågesträngen, rubrikerna, cookies och begäran kroppen, och letar efter mönster angripare använder. Till en nätverksbrandvägg, GET /products?id=5 och GET /products?id=5' OR '1'='1 Det är samma begäran till samma hamn. För en WAF är de helt klart inte det.
Vad en WAF gör med en begäran
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. Avslås 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 den passerar. Så här hanterar du trafik som 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 tillbaka. 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 blockeras kontrollerar du regelordningen före allt annat. En bred tillåtningsregel ovanför dina blockregler är den vanligaste orsaken till att en attack passerar genom en brandvägg som är tekniskt påslagen.
Den del som ingen nämner: falska positiva
En WAF som aldrig har blockerat en legitim begäran är en WAF med sina regler som är nedslagna för långt. Spänningen är inneboende - du matchar mönster på text, och verklig 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. Ett formulär där någons efternamn innehåller en apostrof. En utvecklare som klistrar in ett stackspår i en supportärende. En marknadsförings-URL med en ovanlig kodad parameter.
Därför bör alla WAF-distributioner starta 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 och 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 tillbringat den fjorton dagar avvisa kunder.
Edge WAF eller ursprung WAF
| Till ditt ursprung | Vid kanten | |
|---|---|---|
| Där attackerna upphör | När du har 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 bli överväldigad | Absorberas över hela nätverket |
| Ser en dekrypterad begäranskropp | Ja, ja | Ja TLS slutar vid kanten |
| Gäller alla dina webbplatser på en gång | Per server | Per zon, centralt |
En ursprunglig WAF har redan förlorat bandbredd och CPU när den 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 gör 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 utnyttjandet svårare, vilket ger dig tid att lappa. Sårbarheten finns fortfarande kvar.
- Det stoppar inte logiska brister. Om din kassa accepterar en negativ mängd, är varje begäran som gör det perfekt välformad HTTP.
- Det slutar inte att fylla på med referensmaterial av sig själv. Ett inloggningsförsök med ett riktigt stulet lösenord ser ut precis som en legitim inloggning. Det är en begränsning av räntan och ett område med maximalt ekonomiskt stöd.
- Den ersätter inte patchning. En virtuell korrigering vid kanten är ett användbart stopp för dagarna mellan avslöjandet och distributionen – 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. Så fort du accepterar användarinmatning, kör en inloggning, tar emot betalningar eller lagrar något som du skulle hata att läcka slutar en WAF att 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 begäranden som den tillåter. En brandvägg för webbprogram fungerar på HTTP-lagret och kontrollerar 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-injektionsnyttolast. Det gör inte en WAF.
Har en WAF sakta ner min webbplats?
Knappt. Regelutvärdering på en modern WAF läggs vanligtvis till under en millisekund per begäran, vilket inte märks bredvid nätverksfördröjningen. 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 en säker kod om jag har en WAF?
Helt klart. 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 det 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 ditt program. 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, tänk på din regelordning så att regler inte undergräver blockregler - och fortsätt patchning, eftersom en WAF Det ger mer tid än immunitet.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, 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.
