Du har en webapp på en VPS. Adgangsloggen viser loginforsøg på /wp-admin, requests med UNION SELECT i query-strengen og jævn trafik fra datacenter-IP-intervaller, der ikke har noget at gøre på dit site. Du vil filtrere det åbenlyse skrald fra, før det når din applikation.
Det er her, de fleste møder begrebet WAF SaaS. For mange læsere er "WAF" og "Cloudflare" det samme, fordi Cloudflare var det første, de stødte på. De er ikke det samme. WAF SaaS er en kategori: en web application firewall leveret fra skyen, som inspicerer din HTTP-trafik på udbyderens edge, før den sendes videre til dit origin. Cloudflare er ét produkt inden for den kategori.
Denne artikel gennemgår, hvordan WAF SaaS fungerer, hvad de store udbydere tager, hvor det fejler i praksis, og hvornår din egen WAF på en Linux-VPS er det bedre valg.
TL;DR
- WAF SaaS er en web application firewall leveret fra skyen. Du router trafik gennem udbyderen eller knytter WAF'en til en understøttet cloudressource; tjenesten vurderer HTTP(S)-requests, før den beskyttede applikation håndterer dem.
- De store udbydere bruger tre brede prisformer: abonnementsniveauer (Cloudflare og Sucuri), forbrugsbaseret fakturering (AWS WAF) og salgsdrevne tilbud (Imperva og Fastly). Forbrugsbaserede omkostninger stiger med behandlede requests og valgfrie funktioner, mens abonnementer generelt er mere forudsigelige.
- Der findes en dokumenteret kritik af WAF SaaS, og den tages op nedenfor. Den peger på latency, falske positiver, uigennemsigtig blokering og datarouting via tredjepart.
- Selv-hostede WAF'er på en VPS er en reel mulighed. SafeLine og BunkerWeb er de to open source-projekter med momentum lige nu. De kører som reverse proxy foran din applikation.
- Slet ingen WAF kan være et forsvarligt valg, når applikationssikkerheden er moden, eksponeringen er styret, overvågningen er stærk, og den resterende risiko er dokumenteret og accepteret.
Sådan fungerer WAF SaaS
En request til example.com rammer først udbyderens edge, fordi din DNS peger derhen. Edge-noden terminerer TLS, parser HTTP-requesten, kører den gennem en regelmotor og sender den derefter videre til dit origin, blokerer den, udfordrer den (CAPTCHA, JavaScript-test) eller rate-limiter kilden. Hvis den sendes videre, ser din applikation requesten, som om den kom fra udbyderens IP, med den oprindelige klient-IP i en header som X-Forwarded-For eller CF-Connecting-IP.
Mange WAF SaaS-produkter bruger en udbyderdrevet reverse proxy eller en edge-integration, men ikke alle tjenester rulles ud via en DNS-ændring. Cloudflare, Sucuri og Fastly sidder typisk i request-stien ude på edge. AWS WAF knyttes derimod til CloudFront eller til understøttede AWS-ressourcer som Application Load Balancers, API Gateway-API'er og AppSync-API'er. I alle tilfælde vurderes HTTP(S)-requests, før den beskyttede applikation håndterer dem.
En WAF inspicerer lag 7-data som request-headers, stier, query-strenge, metoder, cookies og den konfigurerede del af request bodies. En traditionel netværksfirewall træffer primært beslutninger på lag 3 og 4 ud fra adresser, protokoller og porte. Vores guide til hardware- kontra softwarefirewall dækker den bredere skelnen.
Managed WAF-beskyttelse trækker som regel på tre regelkilder:
- OWASP Core Rule Set (CRS) er et open source-grundlag for ModSecurity og kompatible WAF-motorer. Det dækker almindelige angrebskategorier som SQL-injection, cross-site scripting, command injection og local file inclusion. Produkter bygget på ModSecurity leverer ofte CRS med, mens mange cloududbydere i stedet bruger egne managed rules.
- Leverandørstyrede regelsæt er proprietære regler, som udbyderen holder opdaterede. Cloudflares "Managed Rules", AWS WAF's "AWS Managed Rules" og Impervas threat intelligence-feed hører alle til her.
- Egne regler er dem, du selv skriver. "Blokér requests til /admin, der ikke kommer fra dette IP-interval", "rate-limit /api/login til 5 per minut per IP".
En SQL-injection-regel kan flage et velkendt mønster som ' OR 1=1 -- i en query-parameter eller request body. Det fanger dovne probes, men en WAF kan stadig misse obfuskerede payloads, logikfejl og ondsindede requests, der ligner normal applikationstrafik. Den vurderer observerbare request-signaler, ikke forretningsmæssig hensigt.
Hvad det beskytter imod, i klar tale:
- Injection-angreb, hvor payloaden matcher en kendt signatur
- Bottrafik fra kendte scannere
- Simple brute force-mønstre
- Volumetrisk DDoS, når udbyderen også kører DDoS-scrubbing
- Basalt API-misbrug
Hvad det ikke gør:
- Patche din applikation
- Erstatte inputvalidering i din kode
- Stoppe angreb, der ligner normal trafik
Applikationssikkerhed kommer stadig fra applikationen. En WAF løfter gulvet mod almindelige og automatiserede angreb, men sikker kodning, patching, autorisation, inputhåndtering, overvågning og incident response sætter loftet.
WAF SaaS vs. on-prem-appliance vs. selv-hosting på en VPS
I 2026 findes der tre almindelige WAF-deploymentmodeller: cloud-WAF SaaS (Cloudflare, AWS WAF, Fastly og andre), fysiske eller virtuelle appliances (herunder tilbud fra F5 og Imperva) og selv-hostet software på en VPS eller din egen server.
De tre adskiller sig på fire praktiske spørgsmål: hvem driver inspektionslaget, hvem betaler for kapacitet, hvem tuner reglerne, og hvad sker der, når WAF'en blokerer noget, den ikke burde. Resten af artiklen bruger disse fire som sammenligningsramme.
Cloud-WAF SaaS
Du router trafik gennem udbyderens edge eller knytter WAF'en til en understøttet cloudressource. Udbyderen driver inspektionskapaciteten og de managed opdateringer, mens du vælger regler, laver applikationsspecifikke politikker og tuner undtagelser. Almindelige valg er Cloudflare, AWS WAF, Imperva, Sucuri og Fastly.
Afvejningen: kapacitet og drift bliver en andens problem. Men hver eneste HTTP-request løber også gennem en andens infrastruktur. Din HTTP-trafik passerer udbyderens infrastruktur, og request-metadata eller matchede payload-uddrag kan blive logget afhængigt af udbyder, produkt og logindstillinger.
On-prem-appliance-WAF
En fysisk eller virtuel appliance sidder i din netværkssti. Køberne er typisk organisationer med etablerede netværkssikkerhedsoperationer, faste kapacitetskrav, stramme deploymentkontroller eller eksisterende leverandørrelationer. Kapacitet, opgraderinger, høj tilgængelighed og tuning forbliver kundens ansvar.
For mange små og mellemstore teams gør indkøb af appliance, fast kapacitet og driftsbyrde dette til den mindst praktiske vej. Den kan stadig passe organisationer, der har brug for et control plane inde i netværket og har folk til at drive det.
Selv-hostet WAF på din egen VPS
Du installerer en WAF på en Linux-VPS, peger din DNS mod den VPS, og WAF'en sidder som reverse proxy foran din applikation. Du driver den. Du tuner den. Du logger ind klokken to om natten, når en managed rule-opdatering blokerer en legitim request, og der ikke er andre at ringe til.
To open source-projekter har momentum: SafeLine, en open source-WAF med en semantisk analysemotor i stedet for ren regex-matching, og BunkerWeb, en NGINX-baseret WAF, der leverer ModSecurity med. Deres licenser, deploymentmodeller og ressourceforbrug tages op senere, i afsnittet om selv-hosting.
Afvejningen er den omvendte af SaaS-modellen. Du kontrollerer inspektionslaget, kapaciteten, loggene og tuningen. Det mindsker afhængigheden af en tredjeparts WAF-udbyder, men upstream-netværk og hostingudbydere transporterer stadig trafikken. Infrastrukturgrænser, båndbredde, patching og incident response er nu dit ansvar.
SaaS-WAF vs. selv-hostet WAF på din VPS
Sammenligningstabellen nedenfor fokuserer på de praktiske forskelle, som sysadmins skal drive og budgettere med.
| Kriterier | Cloud-SaaS-WAF | Selv-hostet WAF på en VPS |
|---|---|---|
| Hvem driver inspektionslaget | Udbyderen, på netværkets edge | Dig, på din VPS |
| Hvem betaler for kapacitet | Udbyderen, faktureret videre til dig via abonnement eller per request | Dig, VPS'ens faste pris |
| Hvem tuner reglerne | Du konfigurerer; udbyderen leverer managed rule-opdateringerne | Dig, fra ende til anden |
| Muligheder ved falske positiver | Tune regler og undtagelser inden for udbyderens kontroller; eskalere platformproblemer | Redigere reglen selv; deploye igen på minutter |
| Datarouting | Requests går gennem udbyderens inspektionsinfrastruktur | Requests går gennem infrastruktur, du kontrollerer, før de når origin |
| Hvordan omkostningerne opfører sig ved en trafikspids | Forbrugsbaserede komponenter kan stige med requestmængden | Typisk mere forudsigelig, men båndbredde og skalering kan stadig koste ekstra |
| Driftsbyrde | Lav, begrænset til konfiguration og tuning | Du driver både VPS'en og WAF'en |
WAF SaaS-priser i 2026
WAF SaaS-priser kombinerer typisk abonnementsniveauer, forbrugsbaserede gebyrer eller salgsdrevne tilbud. Offentlige priser kan ikke sammenlignes direkte, fordi hver udbyder pakker managed rules, botkontrol, logging, support og DDoS-funktioner forskelligt.
| Leverandør | Prismodel | Startpris | Hvad startniveauet indeholder | Bemærkninger |
|---|---|---|---|---|
| Cloudflare | Abonnementsniveau | Gratis; Pro 20 $/md. årligt eller 25 $/md. månedligt; Business 200 $/md. årligt eller 250 $/md. månedligt | Free Managed Ruleset; bredere kontroller varierer efter betalt plan | Tjek de aktuelle regler, grænser og inkluderede sikkerhedsfunktioner før køb |
| AWS WAF | Per request | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Selvadministrerede regler; AWS Managed Rules kan tilføjes som managed rule groups | Ekstra kapacitet, body-inspektion, premium managed groups, CAPTCHA, Challenge, Bot Control og Fraud Control kan lægge til regningen |
| Imperva | Enterprise-tilbud | Kontakt salg | Managed rules, threat intelligence og API-sikkerhedsmuligheder | Ingen direkte sammenlignelig offentlig selvbetjenings-WAF-pris |
| Sucuri Platform | Abonnementsniveau | Basic Firewall 9,99 $/md.; Basic Platform 229 $/år | Firewall-plan: WAF/CDN; Platform-pakken tilføjer scanning og oprydning | Den selvstændige firewall og den årlige Platform-pakke er forskellige produkter |
| Fastly | Via salgsafdelingen | Kontakt salg | Edge- eller distribueret inspektion, managed rules og API-beskyttelse | Ingen direkte sammenlignelig offentlig selvbetjenings-WAF-pris |
AWS WAF offentliggør priser per komponent, mens Cloudflare og Sucuri offentliggør priser på selvbetjeningsplaner. Imperva og Fastly bruger salgsdreven prissætning på sammenlignelige WAF-tilbud.
Tjekket den 29. juli 2026: Cloudflares planpriser angiver Pro til 20 $ om måneden ved årlig fakturering eller 25 $ ved månedlig, og Business til 200 $ om måneden årligt eller 250 $ månedligt. Sucuris firewall-prisside lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from AWS WAF-priserne as of the same date.
Imperva og Fastly offentliggør ikke direkte sammenlignelige selvbetjenings-WAF-priser, så behandl begge som kontakt-salg-muligheder frem for at stole på tredjepartsestimater.
AWS WAF-prissiden angiver basisgebyrer på 5 $ per web ACL om måneden, 1 $ per regel eller regelgruppe om måneden og 0,60 $ per million behandlede requests. Der kan komme ekstra gebyrer for øget kapacitet, større body-inspektion, CAPTCHA- eller Challenge-handlinger, premium managed groups og svindel- eller botkontroller. Angrebstrafik kan derfor øge regningen, men effekten afhænger af mængde, varighed og aktiverede funktioner. Rate-baserede regler beskytter applikationen; de gør ikke allerede behandlede WAF-requests gratis.
Hvor WAF SaaS kommer til kort
Falske positiver er den første praktiske begrænsning. En legitim upload, et API-kald eller en formularindsendelse kan ligne et angrebsmønster og udløse en managed rule. Operatøren skal så finde den regel, der matchede, indsnævre eller udelukke den og bekræfte, at undtagelsen ikke skaber et bredere bypass.
WAF'er træffer beslutninger ud fra request-signaler, ikke forretningsmæssig hensigt. Stramme regler kan blokere legitim trafik; brede undtagelser kan svække beskyttelsen. Cloudtjenester giver som regel event-logs, regeloverskrivninger og egne responses, men hvor meget indsigt og tuning du får, varierer med plan og udbyder.
Pro-tip. Start nye eller væsentligt ændrede regler i detection- eller count-tilstand. Observér repræsentativ trafik, test både kritiske og sjældne workflows, gennemgå falske positiver, og tilføj snævert afgrænsede undtagelser, før du slår blokering til. De nuværende CRS-tuningretningslinjer anbefaler en til to uger, eller indtil spidsbelastning og kritiske workflows er blevet kørt igennem.
Den anden begrænsning er performance-overhead. Et ModSecurity-benchmark fra 2023 målte 9.462 uploads af små filer til 7,36 sekunder med CRS slået til mod 4,55 sekunder uden. Gennemløbet faldt fra 2.079 til 1.285 requests i sekundet, mens nginx' peak-CPU steg fra 8 % til 73 %. Det var én konfiguration og én workload, så brug det som bevis for, at inspektion koster noget, ikke som et universelt sizing-forhold.
Den tredje begrænsning er datarouting. Hver eneste HTTP-request, inklusive request body, går gennem udbyderens infrastruktur. For applikationer, der håndterer persondata, finansielle transaktioner eller sundhedsdata, er det et konkret spørgsmål om datasuverænitet. En EU-hostet applikation, der router kunders requests gennem en amerikansk WAF-udbyder, har et tungere revisionsspor at forsvare og et par ekstra kontraktvilkår at acceptere end den samme applikation med en selv-hostet reverse proxy på en VPS i samme jurisdiktion.
Den fjerde begrænsning er tuningbyrden. Udfordringerne ved WAF-tuning omfatter falske positiver, begrænset applikationskontekst og regler, der skal følge med hyppige kodeændringer. Kilden er et leverandørperspektiv, men det driftsmæssige mønster er reelt: teams investerer enten i løbende tuning eller lader flere regler blive stående i detection-only.
Den samme kritik fra 2023 argumenterer for, at WAF'er kan blive sikkerhedsteater, når teams læner sig op ad dem i stedet for at fikse applikationen. Argumentet er stærkest for teams med moden applikationssikkerhed: parametriseret databaseadgang, solid autorisation, regelmæssig dependency-scanning, immutable deployments og effektiv overvågning. I mindre modne miljøer kan en WAF stadig mindske eksponeringen for almindelige automatiserede probes. Begge dele kan være sande.
WAF'er er ét lag i defense in depth. De erstatter ikke applikationssikkerhed, og de er heller ikke sikkerhedsteater. En WAF's marginale værdi er høj for nogle teams og lav for andre. Det afgørende er, hvordan applikationen nedenunder ser ud.
Hvornår det giver mening at hoste en WAF selv
Selv-hosting vinder i tre situationer. Det taber i tre andre. Først dem, det vinder.
Selv-hosting vinder, når politik- eller datasuverænitetskrav udelukker inspektion af en ekstern WAF SaaS-mellemmand, når trafikmønstrene gør forbrugsbaseret prissætning mindre attraktiv end at køre dedikeret infrastruktur, og når et team vil have direkte kontrol over blokeringsbeslutninger og rettelser af falske positiver.
Selv-hosting taber, når der ikke er driftskapacitet, når applikationen ligger på en managed platform, hvis routingmodel gør en ekstern proxy besværlig, eller når en udbyderdrevet gratis plan allerede dækker de nødvendige kontroller med mindre kompleksitet.
Cloudflares gratis plan kan være et praktisk udgangspunkt for små og mellemstore teams, der i forvejen bruger deres DNS eller CDN og accepterer deres model for trafikinspektion. Selv-hosting bliver mere attraktiv, når datarouting, direkte kontrol over regler eller forudsigelige infrastrukturomkostninger vejer tungere end at minimere driftsarbejdet.
SafeLine og BunkerWeb
To selv-hostede open source-WAF'er er værd at kende.
SafeLine er licenseret under GPL-3.0, deployes med Docker Compose og er bygget op om semantisk analyse frem for et rent CRS-regelsæt. SafeLine-repositoriet rapporterer 71,65 % detektion, 0,07 % falske positiver og 99,45 % samlet præcision i Balance-tilstand på deres egen evaluering med 33.669 stikprøver. Det er projektvedligeholdernes egne målinger, ikke en uafhængig benchmark, og de bør ikke generaliseres ud over det testsæt.
BunkerWeb er licenseret under AGPL-3.0 og bruger NGINX under motorhjelmen. Den integrerer ModSecurity med OWASP Core Rule Set og understøtter flere deploymentmodeller, herunder Linux, Docker, Swarm og Kubernetes.
Dimensionér begge projekter ud fra en målt requestmængde, de aktiverede beskyttelser, TLS-arbejdet og logopbevaringen. Til en SafeLine-installation med lav trafik er 2 vCPU og 4 GB RAM et konservativt udgangspunkt med luft over installationsminimum. Den nuværende BunkerWeb-quickstartvejledning anbefaler mindst 2 vCPU og 8 GB RAM til test eller ganske få services, og 4 vCPU med 16 GB RAM til produktionsmiljøer, der beskytter mange services. Lagerplads afhænger primært af logmængde og opbevaringstid: mål det i stedet for at love et fast antal måneder.
Pro-tip. Kør den selv-hostede WAF i samme region som applikationens origin, når det kan lade sig gøre. En fjern proxy lægger en interregional netværks-roundtrip til hver request og kan forringe latency i stilhed. Mål end-to-end-svartiden fra dine brugeres regioner, før du skifter til produktion.
Du driver selv WAF'en, hvilket betyder, at den underliggende infrastruktur også er dit ansvar: oppetid, sikkerhedspatches, TLS-certifikater, backups, logrotation, overvågning, kapacitet og genopretning. Test fejladfærden lige så omhyggeligt som filterreglerne, så WAF'en ikke bliver et single point of failure.
En Beslutningsramme
Der findes fire veje: Cloudflares gratis niveau, en betalt cloud-WAF SaaS, en selv-hostet WAF på en VPS og slet ingen WAF. Betingelsen, der peger på hver af dem, er forskellig.
Vælg et gratis cloud-WAF-niveau, når de tilgængelige managed rules og grænser passer til applikationens risiko, datarouting-modellen er acceptabel, og prioriteten er at minimere driftsarbejdet. Test rigtige workflows, før du antager, at standardindstillingerne er nok.
Vælg en betalt WAF SaaS, når du har brug for flere managed rules, logging, egne kontroller, bot- eller API-beskyttelse, support eller kapacitet, end gratisniveauet giver. Sammenlign den præcise funktions- og grænsematrix, ikke bare plannavnet. AWS WAF er stærkest, når applikationen allerede bruger understøttede AWS-ressourcer, og teamet er trygt ved at forudsige komponentbaserede omkostninger.
Vælg en selv-hostet WAF, når de tidligere nævnte selv-hosting-betingelser er opfyldt, og dit team kan drive proxyen pålideligt. SafeLine og BunkerWeb er de to projekter, du bør vurdere først.
Slet ingen WAF kan være et forsvarligt valg, når applikationssikkerheden er moden, eksponeringen bevidst er begrænset, overvågningen er stærk, og den resterende risiko er dokumenteret og accepteret. Det bør bare ikke blive standardvalget, alene fordi et framework validerer input.
Konklusion
Vælg WAF SaaS for udbyderstyret kapacitet og mindre driftsbyrde. Vælg selv-hosting for direkte kontrol, når teamet kan køre proxyen pålideligt. I begge modeller gælder: udrul regler i faser, mål latency og falske positiver, og hold applikationssikkerheden forrest.
Hvis selv-hosting passer til dine krav, så start med en Linux VPS i samme region som dit origin. Cloudzy tilbyder også marketplace-installationer med ét klik til SafeLine og til BunkerWeb, så du kan begynde at teste uden selv at bygge basis-stakken op i hånden.
Byg på en Linux VPS med root-adgang, NVMe og AMD EPYC-kraft.
Se Linux-planerOfte stillede spørgsmål
Hvad er WAF as a service?
WAF as a service er en web application firewall leveret fra skyen. Trafikken når tjenesten via DNS- eller reverse proxy-routing, via en edge-integration eller ved at blive knyttet til en understøttet cloudressource. Udbyderen driver inspektionskapaciteten og de managed opdateringer; du vælger politikker, tuner undtagelser og tilføjer applikationsspecifikke regler.
Er Cloudflare en WAF?
Ja. Cloudflare leverer WAF-funktionalitet som en del af en bredere edge-platform, der også omfatter DNS, CDN og DDoS-beskyttelse. Gratis planer får Cloudflare Free Managed Ruleset; bredere regelsæt, kontroller, analytics og botmanagement afhænger af den valgte plan og tilkøb.
Er Cloudflares gratis WAF nok?
Det afhænger af applikationens angrebsflade, de nødvendige regler, behovet for logging og opbevaring, API- eller botkontroller, supportkrav og din tolerance over for falske positiver. Free Managed Ruleset kan være et brugbart fundament, men autentificering, betalinger eller regulerede data oversættes ikke automatisk til én bestemt betalt plan. Sammenlign de aktuelle funktionsgrænser, og hold dem op mod din trusselsmodel.
Hvad er forskellen på en WAF og en firewall?
En traditionel netværksfirewall filtrerer primært trafik ud fra lag 3- og lag 4-information: adresser, protokoller og porte. En WAF vurderer HTTP(S)-requests på lag 7, inklusive de konfigurerede headers, stier, parametre og body-indhold. Moderne sikkerhedsprodukter kan sløre grænserne, men de to kontroller er stadig supplerende frem for udskiftelige.
Hvad er WAAP, og hvordan adskiller det sig fra en WAF?
WAAP står for Web Application and API Protection. Det er bredere end en traditionel WAF: leverandører kombinerer typisk WAF-regler med API-discovery eller -håndhævelse, botmanagement og DDoS- eller misbrugskontroller på applikationslaget. Præcis hvad pakken indeholder varierer fra udbyder til udbyder, så WAAP bør ikke opfattes som et standardiseret funktionssæt.
Har jeg brug for en WAF, hvis mit framework allerede validerer input?
Ikke altid. Frameworkets kontroller mindsker risikoen, men dækker ikke ethvert mønster af automatiseret misbrug. Tilføj kun en WAF, når den adresserer en klart defineret risiko, der retfærdiggør omkostningen og tuningen.
