Webbhotell med WAF
En WAF (Web Application Firewall) filtrerar och blockerar skadlig trafik innan den når din webbplats. Till skillnad från en vanlig brandvägg förstår en WAF webbtrafik och kan identifiera attacker som SQL-injection, XSS och brute force-försök.
WordPress-sajter är ett av de vanligaste målen för automatiserade attacker. En WAF på servernivå stoppar de flesta innan de ens når PHP, vilket både skyddar sajten och sparar serverresurser.
Webbhotell med WAF - och vilken brandvägg det är
En webbapplikationsbrandvägg filtrerar bort attacker innan de når din sajt. De flesta jämförelser nöjer sig med att kryssa i en ruta, men det är skillnad på lösningarna. Därför skriver vi ut vad brandväggen faktiskt är hos var och en av de fem.
En webbapplikationsbrandvägg filtrerar trafik innan den når sajten. Vi skriver ut vilken brandvägg det faktiskt är i stället för att bara säga att den finns. Så gör vi bedömningen
-
Imunify360 i alla paket Testat av oss Betyg 4,80Oderland kör Imunify360, som kombinerar brandvägg med daglig virusskanning, i alla paket för 215 kronor i månaden från servrar i Göteborg. Det är en beprövad lösning som ingår utan tillägg. Nackdelen är priset, listans högsta ingång.
-
Regelhantering i DirectAdmin Testat av oss Betyg 4,60Inleeds Prime #1 har en brandvägg i DirectAdmin där du kan slå av enskilda regler per webbapplikation, för 149 kronor i månaden med svensk telefonsupport. Det ger mer kontroll än en påslagen svart låda, men kräver att du vet vilka regler du rör.
-
Egen brandvägg plus Imunify360 Granskat, ej testat Betyg 4,30HostUp kör två lager: en egenbyggd nätverksbrandvägg och Imunify360 i cPanel, båda inkluderade, från 79 kronor i månaden. Ovanligt komplett i prisklassen. Supporten är dock chatt och e-post, ingen telefon om en regel blockerar legitim trafik.
-
Managerad brandvägg Testat av oss Betyg 4,60Kinsta sköter en managerad brandvägg med skanning åt dig för 35 dollar i månaden, så du behöver aldrig konfigurera regler själv. Bekvämt men mindre transparent. Supporten är enbart på engelska och priset i dollar varierar med kursen.
-
Brandvägg för tolv kronor Testat av oss Betyg 3,90EgenSajt inkluderar en webbapplikationsbrandvägg redan i sitt paket för 12 kronor i månaden, ett ovanligt lågt pris för funktionen. Paketet ger dock bara 1 gigabyte lagring och inga e-postkonton, och bolaget har två anställda.
Priser anges exklusive moms i leverantörens egen valuta, och avser det paket som bäst uppfyller facettens krav. Baslinjen är ett års bindning delat med tolv.
Utforska webbhotell efter ämne
En WAF stoppar angrepp innan de når din kod
En brandvägg på webbservernivå, ofta kallad WAF (Web Application Firewall), filtrerar HTTP-trafiken innan den ens når din webbplats. Till skillnad från en nätverksbrandvägg, som enbart bryr sig om IP-adresser och portar, förstår WAF:en webbprotokollens innehåll och kan skilja en legitim formulärskickning från ett injektionsförsök. Det är den skillnaden som gör den till ett av de mest effektiva säkerhetslagren för ett webbhotell.
Skadlig trafik på nätet är inte riktad mot just din sajt. Automatiserade bots skannar kontinuerligt miljontals domäner och provar kända sårbarheter i WordPress, Joomla, PHP och vanliga webbapplikationsramverk. Utan ett filter tar dessa förfrågningar den vanliga vägen in, till din PHP-process, din databas och din kod. Med en WAF på plats stoppas de förut.
Vad en WAF faktiskt gör
Principen är enkel: varje inkommande HTTP-förfrågan matchas mot en uppsättning regler. Reglerna beskriver mönster för kända attacker, till exempel hur en SQL-injektion ser ut i en URL-parameter, eller hur ett XSS-försök formateras i ett formulärfält. Matchar förfrågan ett mönster blockeras den, loggas och returnerar ett felmeddelande till angriparen. Legitima besökare märker ingenting.
I praktiken handlar det om att skydda din webbplats mot WordPress-specifika attackvektorer som automatiserade brute-force-angrepp mot wp-login.php, mot generiska webbutnyttjanden som filinkluderingsattacker, och mot en bred klass av nätbots som letar efter glömt inloggningsgränssnitt eller osäkrade backupfiler. En välkonfigurerad WAF hanterar allt detta utan att du behöver göra något manuellt.
Vad en WAF skyddar mot
De vanligaste attacktyperna som en brandvägg på applikationsnivå identifierar och blockerar.
SQL-injektion
Angriparen försöker mata in SQL-kod via formulär eller URL-parametrar för att läsa, ändra eller radera din databas. WAF:en känner igen mönstren och blockerar förfrågan.
Cross-Site Scripting (XSS)
Skadliga skript bäddas in i kommentarsfält eller kontaktformulär och körs sedan i besökarnas webbläsare. En WAF-regel stoppar dessa innan de lagras eller skickas vidare.
Brute force-inloggningar
Automatiserade verktyg provar tusentals lösenordskombinationer mot wp-admin eller xmlrpc.php. Rate limiting och inloggningsregler i WAF:en stänger ute dessa försök tidigt.
Skadliga bots och sårbarhetsscanners
Bots som kartlägger din sajt på jakt efter okonfigurerade endpoints, exponerade backupfiler eller föråldrade plugin-versioner filtreras bort innan de ens indexerar din struktur.
Filinkludering och path traversal
Försök att komma åt filer utanför din webbkatalog, eller att fjärrlasta skadlig kod, fångas av regler som bevakar hur sökvägar formuleras i förfrågningar.
ModSecurity och OWASP Core Rule Set
ModSecurity är den vanligaste öppen källkod-WAF:en på delade webbhotell och fungerar som en modul i Apache och Nginx. Den används på ett stort antal webbhotell som standard, ofta utan att det nämns på prissidan. Vad som skiljer installationerna åt är vilken regeluppsättning som körs.
Den mest utbredda öppna regeluppsättningen heter OWASP Core Rule Set (CRS), ett community-drivet projekt under OWASP (Open Web Application Security Project). CRS täcker OWASP Top Ten, listan över de vanligaste webbsårbarheterna, och uppdateras regelbundet när nya attackmönster identifieras. Ett webbhotell som kör ModSecurity med OWASP CRS ger ett grundskydd som täcker de allra flesta angrepp i det automatiserade botlandskapet.
Utöver CRS erbjuder kommersiella aktörer egna regeluppsättningar, ibland med snabbare uppdateringscykler och mer specifikt innehållsskydd. LiteSpeed-servrar har en inbyggd WAF-modul med egna regler, och molnbaserade tjänster som Cloudflare och Sucuri kör sina egna regelbibliotek uppdaterade i nära realtid mot nya hot. Vad du faktiskt får beror alltså inte bara på om WAF nämns i specifikationerna, utan på vilka regler som körs och hur ofta de uppdateras.
WAF på servernivå, plugin-nivå eller i molnet
Det finns tre huvudsakliga platser där en WAF kan sitta, och skillnaden är mer än teknisk.
Servernivå (ModSecurity, LiteSpeed WAF) är det effektivaste alternativet. Filtreringen sker i webbservern innan PHP ens startar, vilket innebär att skadliga förfrågningar aldrig belastar din kod eller din databas. Det är också det enda alternativet som fungerar oberoende av vilket CMS eller vilken applikation du kör.
Plugin-nivå, som Wordfence för WordPress, kör WAF-logiken inuti PHP. Det är bättre än ingenting, men attacktrafiken passerar webbservern och startar PHP-processen oavsett. Under hög belastning belastar det servern precis när du minst vill det. Vi ser det som ett komplement vid sidan av en server-WAF, inte som ett substitut.
Molnbaserat, som Cloudflare eller Sucuri, placerar ett filtreringslager framför din server på CDN-nivå. Attacktrafiken stoppas vid edge-noder långt innan den når ditt webbhotell. Det är tekniskt effektivt och lägger till ett geografiskt skyddslager, men introduserar ett beroende av en tredjepartstjänst för all trafik till din domän. För ett webbhotell med fokus på datasuveränitet kan det vara en avvägning värd att göra medvetet.
En WAF på servernivå stoppar attacken innan PHP startar. En plugin-WAF stoppar den efter att PHP redan gjort jobbet.
Virtuell patchning och snabbheten i regeluppdateringar
En funktion som sällan nämns i webbhotellsreklam men som spelar stor roll i praktiken kallas virtuell patchning. Idén är enkel: när en ny sårbarhet publiceras i ett populärt WordPress-plugin eller en PHP-komponent kan angripare börja utnyttja den inom timmar. En officiell rättelse från plugin-utvecklaren kan ta dagar eller veckor, och många sajter förblir oskyddade under hela den perioden.
Med virtuell patchning kan webbhotellet eller WAF-leverantören skriva en regel som blockerar det specifika exploitmönstret, utan att du behöver uppdatera pluginet. Skyddet aktiveras centralt för alla kunder på plattformen. Det är en av de starkaste argumenten för en WAF som underhålls och uppdateras aktivt, snarare än en statisk installation med samma regler som för tre år sedan.
Märk att virtuell patchning inte ersätter faktiska uppdateringar. Den köper tid och minskar riskytan, men det slutgiltiga målet är alltid att den underliggande sårbarheten åtgärdas i kod. Säkerhetskopior är fortfarande det sista skyddslagret om en attack mot förmodan lyckas.
False positives och hur man hanterar dem
En aggressivt konfigurerad WAF kan blockera legitim trafik. Det kallas false positives och är den vanligaste praktiska utmaningen med ModSecurity i strikt läge. Typiska scenarion är e-handelssystem som skickar HTML-innehåll i POST-formulär, programmeringsverktyg som Postman, eller administratörer som klistrar in kod i ett CMS-formulär.
Bra webbhotell hanterar detta antingen via ett gränssnitt i kontrollpanelen där du kan ange undantag, eller via supporten som kan vitlista specifika regler för din installation. Om ett webbhotell inte kan hjälpa dig med det är det ett tecken på att WAF-implementationen är enkelriktad och ogenomskinlig. Den bör gå att justera utan att du behöver stänga av hela skyddet.
En WAF ersätter inte uppdateringar
Det är vanligt att tänka att en aktiv WAF gör det säkert att skjuta upp plugin-uppdateringar ett par veckor. Det stämmer inte. Zero-day-sårbarheter kan börja utnyttjas innan regler ens existerar, och vissa attackvektorer riktar sig mot logik snarare än mönster som en WAF känner igen. Uppdatera alltid WordPress, teman och plugins i nära anslutning till att rättelser ges ut.
Det här bör du kontrollera hos din leverantör
- WAF aktiverat som standardInte som opt-in i ett premium-paket. Ett grundskydd ska inte kräva att du vet om att det finns.
- Vilken regeluppsättning som användsOWASP CRS är ett bra riktmärke för öppna installationer. Fråga specifikt om det inte framgår av dokumentationen.
- Hur ofta reglerna uppdaterasAutomatiska uppdateringar i realtid eller i nära anslutning till publicerade CVE:er är markant bättre än manuell skötsel.
- Stöd för virtuell patchningInnebär att leverantören aktivt bevakar nya sårbarheter och publicerar tillfälliga regler under perioden innan officiella rättelser finns.
- Möjlighet att vitlista regler eller IP-adresserBehövs för att hantera false positives utan att stänga av hela WAF:en. Bör finnas i kontrollpanelen eller via supporten.
- Loggning av blockerade förfrågningarDu bör kunna se vad som blockeras och varför. Fullständig transparens är ett tecken på en mogen implementation.
Vanliga frågor om WAF och webbsäkerhet
Svar på de vanligaste frågorna om hur en WAF fungerar, när den räcker och vad som händer när den blockerar fel saker.
Vad en WAF skyddar mot
En WAF på servernivå blockerar framför allt de attackmönster som OWASP CRS (Core Rule Set) definierar: SQL-injection via formulärfält och URL-parametrar, cross-site scripting (XSS) där angripare försöker injicera skript i din sajt, automatiserade brute force-angrepp mot inloggningssidor, och filinkluderingsattacker (LFI/RFI) som försöker läsa eller köra filer utanför webbroten. Attacker mot kända pluginsårbarheter i WordPress blockas också, ofta via signaturer som uppdateras löpande när nya CVE:er publiceras.
En WAF täcker det den är designad för, nämligen kända HTTP-baserade attackmönster, men lämnar flera angreppsytor öppna. Zero-day-sårbarheter saknar regler tills säkerhetsforskare publicerat en analys och regeluppdatering tagits fram. Attacker som går via legitim autentisering, exempelvis ett stulet lösenord, passerar WAF:en odetekterat. Och logikfel i applikationskoden, där angriparen utnyttjar hur systemet är tänkt att fungera snarare än en teknisk brist, syns inte i HTTP-trafiken på ett sätt som WAF:en känner igen. Det är anledningen till att uppdateringar och backuper förblir nödvändiga skyddslager parallellt med WAF.
För en enkel blogg utan betalformulär eller inloggade användare utöver administratören är en WAF på servernivå ett tillräckligt aktivt skyddslager, förutsatt att WordPress och alla plugins hålls uppdaterade. Den klassiska missräkningen är att tro att en liten sajt inte är ett mål: botar söker inte efter intressanta sajter utan skannar hela internet systematiskt och attackerar allt de hittar. Vad som varierar är inte risken att bli kontaktad, utan risken för skada om ett angrepp lyckas. En blogg utan kunddata har låg skadepotential, men en hackad sajt kan sprida skadlig kod till dina besökare eller användas i spamkampanjer, vilket skadar dig ändå.
WAF på servernivå vs säkerhetsplugin
ModSecurity körs som en modul i webbservern och granskar varje HTTP-förfrågan innan PHP ens startar. Det innebär att skadliga anrop aldrig når WordPress-kärnan, vilket sparar serverresurser och stoppar attacker på en djupare nivå. Wordfence och liknande plugins laddas som PHP-kod inuti WordPress, vilket betyder att PHP redan körts och en del av attackytan passerats när granskningen sker. Plugins har däremot bättre kännedom om din specifika installation: de känner till dina plugin-versioner, inloggade användare och applikationslogik, vilket ger mer träffsäker blockering av vissa WordPress-specifika hot. I praktiken kompletterar de varandra snarare än utesluter.
OWASP Core Rule Set (CRS) har fyra paranoia-nivåer som styr hur aggressivt WAF:en blockerar misstänkt trafik. Paranoia level 1 (PL1) är standardläget hos de allra flesta webbhotell och slår bara på de säkraste reglerna med minimala falska positiva. PL2 adderar fler mönster och börjar träffa viss legitim trafik vid hög last. PL3 och PL4 är avsedda för hårdade applikationer med strikta säkerhetskrav och genererar falska positiva på nästan alla vanliga webbapplikationer utan noggrann genomgång av undantag. Om ditt webbhotell inte specificerar vilken nivå de kör är det nästan alltid PL1, vilket är ett vettigt val för den breda marknaden.
Falska positiva märks oftast som ett formulär som plötsligt slutar fungera, en 403-sida utan förklaring, eller en betalningsintegration som avbryts mitt i flödet. Det händer när legitim trafik liknar ett attackmönster, exempelvis ett kontaktformulär som skickar HTML-kod eller ett plugin som gör ovanliga POST-anrop. Åtgärden är att be webbhotellets support vitlista den specifika regeln eller URL:en som triggar blockeringen. Seriösa leverantörer loggar blockerade anrop så att de kan identifiera exakt vilken CRS-regel som bröt mot trafiken. Ser du bara en 403 utan logg har du ett tecken på ett webbhotell med begränsad WAF-konfiguration.
Cloudflare WAF och externlösningar
Cloudflares gratisplan och ett välkonfigurerat ModSecurity med OWASP CRS skyddar mot liknande grundläggande attacktyper, men de arbetar på olika sätt och på olika ställen. Cloudflare sitter framför din server vid edge-noder runt om i världen och stoppar trafik innan den ens når ditt webbhotell, vilket minskar serverbelastningen. ModSecurity körs lokalt på webbhotellets server. Cloudflare lägger dessutom till IP-ryktesdatabaser, botfiltrering och grundläggande hastighetsbegränsning som inte ingår i standard ModSecurity. Det gör Cloudflare till ett värdefullt komplement, men inte en ersättning: ModSecurity på servernivå fångar angrepp som passerar Cloudflares regler, exempelvis mer sofistikerade applikationsattacker mot specifika sårbarhetsmönster.
Dubbel WAF fungerar i praktiken utan konflikter för den absoluta majoriteten av sajter: Cloudflare filtrerar trafiken på väg in och webbhotellets WAF granskar det som passerar vidare. Risken för konflikter uppstår i kantsituationer där samma legitima anrop triggar regler i båda systemen och svårigheten att felsöka ökar eftersom du nu behöver avgöra vilket lager som blockerar. Det praktiska rådet är att aktivera Cloudflare, bevaka loggarna under ett par veckor, och sedan adressera falska positiva lager för lager. Börja med det lager som blockerar, inte med att inaktivera ett system i taget på känn.