--- title: "Firewall og edge-sikkerhed til websites | Serpwise" description: "Stop exploit-probes, aggressive bots og trafikspikes på edge-netværket. Styr firewall, Block Groups, rate limits og browser-sikkerhed i Serpwise." url: "https://serpwise.ai/da/product/firewall-security/" source: "https://serpwise.ai/da/product/firewall-security/" --- Firewall og edge-sikkerhed # Stop skadelig trafik. Før den rammer din origin. Serpwise inspicerer requests, før dit site skal håndtere dem. Blokér kendte exploit-paths, aggressive bots, uønsket trafik og floods, og gennemgå alle beslutninger i én sikkerhedskontrolflade. [Book en sikkerhedsdemo](/da/demo/) [Læs sikkerhedsdocs](/docs/shield/) - Ingen origin-kode eller serverkonfiguration - Politikker og dokumentation pr. domæne - Monitorér, allowlist eller blokér Sikkerhed og trafik Rigtig produkt-UI ![Serpwise Security og Traffic med beskyttelsesstatus, blokerede requests og aktuelle signaler](/product-screenshots/security-traffic.png) Et Serpwise demo-workspace med trafikinspektion, blokerede beslutninger, protection coverage og næste anbefalede handlinger. Tallene er demodata. Beslutninger på edge-netværket Blokerede requests bruger ikke origin-kapacitet Managed protection Kuraterede kontroller uden vedligeholdelse af serverregler Sikkerhed under passthrough Beskyttelsen fortsætter, når HTML-ændringer er slået fra Den skjulte pris på dårlig trafik ## Din origin skal betjene kunder, ikke absorbere hvert eneste probe. Scannere, aggressive bots og trafikspikes skaber mere end en sikkerhedsrisiko. De bruger origin-ressourcer, forurener analytics og tvinger teams til at vedligeholde beskyttelse på tværs af hosting, applikation og CDN-lag. 01 ### Origin-belastning Selv en harmløs 404 koster båndbredde og compute, når requesten når din server. 02 ### Sikkerhedsstøj Kendte exploit-paths og automatiske probes skjuler den trafik, der faktisk kræver undersøgelse. 03 ### Fragmenteret kontrol Beskyttelse bliver langsom at ændre, når hver politik kræver en ny leverandør, konfigurationsfil eller release. Ét beskyttelseslag ## Kontrollér requesten, responset og dokumentationen. Brug kontrollerne sammen, eller aktivér kun det enkelte domæne har brug for. Sikkerheden kører i gatewayen uafhængigt af kundens CMS og applikationsstack. 01 ### Custom firewall-politikker Definér beslutninger pr. domæne for trafikbetingelser som land, path, bot-identitet og request-kontekst. Detaljeret trafikkontrol [Se betingelser](/docs/conditions/) 02 ### Managed Block Groups Aktivér kuraterede grupper til almindelige WordPress-, PHP-, CMS-, dotfile-, webshell-, konfigurations- og API-probes. Kendte attack-paths stoppes på edge-netværket [Se Block Groups](/docs/block-groups/) 03 ### Exploit Shield Blokér kendte exploit-paths før origin, og blackhole midlertidigt kildens IP efter et match. 403-response før origin fetch [Læs om Shield](/docs/shield/) 04 ### Rate limiting Brug et glidende vindue pr. IP til at absorbere aggressiv request-volumen og returnere standard 429 backoff-headers. Beskyt origin-kapaciteten [Se rate limiting](/docs/shield/#rate-limiting) 05 ### Browser-sikkerhed Anvend HSTS, framing, MIME, referrer, permissions, cross-origin og CSP uden at redigere serverkonfigurationen. Standard, strict og report-only workflows [Se security headers](/docs/security-headers/) 06 ### Beslutningsdata Gennemgå inspiceret trafik, blokerede beslutninger, botaktivitet, aktiv beskyttelse, aktuelle signaler og events på request-niveau. Se hvad der skete og hvorfor [Se analytics](/docs/analytics/) Beskyttelse med høj effekt ## Fjern hele klasser af scannerstøj med én beslutning. Block Groups samler kendte request-mønstre med høj sikkerhed i kontroller, som kan aktiveres pr. domæne. Requests der matcher, får en bodyless 404 på edge-netværket før upstream fetch. Block Groups beskytter mod kendte probes på request-paths. De erstatter ikke en application WAF mod angreb inde i legitime routes. Managed grupper Source control og secrets /.git, /.env, /.aws, /.ssh WordPress-probes wp-config, xmlrpc, wp-login PHP- og webshell-paths phpmyadmin, adminer, shell.php CMS-probes Magento, Drupal, Joomla API- og docs-probes GraphQL, Swagger, actuator Eksponeret konfiguration credentials, .sql, Dockerfile Sikre kontroller ### Blokér eller monitorér Se hvad der ville matche, før I aktivt afviser requests. ### Bot-filter Anvend udvalgte grupper på al trafik eller kun kendte bots. ### IP-allowlist Lad betroede kontor-, admin- og partnernetværk gå uden om en gruppe. ### Beskyttelse af crawlere Verificeret Googlebot og Bingbot er undtaget fra Block Group-afvisning. Requestens vej ## Beslut på edge-netværket. Send kun tilladt trafik videre. Sikkerhedskontroller kører før normalt optimeringsarbejde og origin-behandling, så afviste requests stoppes tidligt, mens legitim trafik fortsætter gennem Serpwises leveringsvej. 1. 1 ### Inspicér Læs path, request-kontekst og kendt bot-identitet. 2. 2 ### Klassificér Match custom policies, managed grupper, Shield og rate limits. 3. 3 ### Beslut Tillad, monitorér, blokér eller rate limit efter domænets politik. 4. 4 ### Stop eller videresend Returnér edge-responset, eller send den tilladte request videre mod origin. 5. 5 ### Registrér Skriv beslutningen til trafik-analytics og sikkerhedsevents. Operationel kontrol ## Beskyttelse I kan indføre uden at gamble med produktionstrafik. Sikkerhedspolitik kræver en sikker rollout. Serpwise holder observation, enforcement, undtagelser og fallback tæt på beslutningen. ### Monitorér før I blokerer Brug monitor mode til Block Groups og report-only mode til CSP, mens I gennemgår rigtig trafik. ### Bevar legitim adgang Brug IP-allowlists, bot-filtre og undtagelser for verificerede crawlere, hvor en politik kræver nuance. ### Bevar sikkerhed i passthrough Shield, rate limiting, security headers og redirects forbliver aktive, når HTML-ændringer er slået fra. ### Ændr uden origin-release Styr beskyttelse pr. domæne uden at udgive applikationskode eller redigere webserverens konfiguration. Spørgsmål om sikkerhedsproduktet ## Det tekniske teams typisk spørger om først. 01 Erstatter Serpwise vores nuværende WAF? + - Ikke nødvendigvis. Shield, firewall-politikker, Block Groups, rate limiting og browser-kontroller giver et nyttigt beskyttelseslag i Serpwise-gatewayen. Block Groups fokuserer på kendte probes på request-paths og bør ikke præsenteres som en komplet application WAF mod angreb inde i legitime routes. 02 Kan vi se hvad der ville blive blokeret, før vi aktiverer en politik? + - Ja. Block Groups understøtter monitor mode, og CSP Builder understøtter report-only mode. Brug de workflows til at samle dokumentation, tilpasse undtagelser og skifte til enforcement, når resultaterne er rene. 03 Vil Block Groups forstyrre søgemaskinernes crawlere? + - Verificeret Googlebot og Bingbot er undtaget fra Block Group-afvisning. I kan også bruge bot-filtre og IP-allowlists til politikker, der kræver mere kontrol. 04 Virker beskyttelsen stadig, hvis vi slår Serpwise-optimeringer fra? + - Ja. I passthrough mode stopper HTML-ændringer, mens Exploit Shield, IP-blackhole, rate limiting, security headers og redirects forbliver aktive. 05 Hvor hurtigt træder sikkerhedsændringer i kraft? + - Sikkerhedsindstillinger anvendes i gatewayen uden en origin-release. Shield og security headers gælder på den næste request gennem gatewayen, mens Block Group-konfiguration udbredes til edge-noder inden for få sekunder. 06 Hvad skal vi vide om den nuværende rate-limit state? + - Den nuværende Shield-implementering holder rate-limit counters og midlertidige IP-blackholes i memory. De nulstilles ved gateway-restart og deles ikke mellem gateway-instanser. Vi dokumenterer begrænsningerne tydeligt, så teams kan afgøre hvordan Serpwise passer sammen med deres eksisterende sikkerhedsstack. Tag jeres trafikmønster med ## Se hvilke requests Serpwise kan stoppe før origin. Book en sikkerhedsdemo med et rigtigt domæne eller trafikproblem. Vi gennemgår politikdesign, managed protection, sikker rollout og den dokumentation jeres team får. [Book en sikkerhedsdemo](/da/demo/) [Læs sikkerhed & tillid](/da/security/)