Defaults.Exposed › Fikser › CDN / WAF og hosting

Slik fikser du CDN / WAF og hosting

To avlesninger av rørsystemet bak nettstedet ditt: om du sitter bak et beskyttende skjold (en CDN med en Web Application Firewall, som Cloudflare) som filtrerer angrep og absorberer trafikktopper, og et kart over hvem som faktisk driver DNS-en, nettstedet og e-posten din. Begge er informative på vår scoring — de påvirker ikke karakteren — men de beskriver hvor eksponert opprinnelsesserveren er for angrep og driftsintanser, og hvor sammenvevde leverandørene er. Et skjold foran og et fornuftig oppdelt sett av leverandører er hva robuste virksomheter ser ut som.

Bunnlinjen for virksomheten din: Et nettsted uten noe skjold foran tar hvert angrep og hver trafikktopp direkte på opprinnelsesserveren — så en bot-flom, en lanseringsdags-bølge, eller et enkelt automatisert angrep kan slå deg offline i timer, og gjenoppretting er ditt ansvar. Å sette en CDN/WAF foran (gratistier tilgjengelig) filtrerer det store flertallet av automatiserte angrep, absorberer bølger og gjør siden raskere over hele verden — typisk et ettermiddags arbeid for IT-personen din, uten lisenskostnad. Separat, hvis DNS-en, nettstedet og e-posten din alle lever hos én leverandør, tar en enkelt driftsstans eller brudd der hele online-tilstedeværelsen ned på én gang; å kjenne leverandørkartet er det første du trenger under en hendelse. Ingen sjekk endrer karakteren din — men begge beskriver reell eksponering for driftsintanser, tapte salg og sakte, smertefull gjenoppretting.

Hva dette kan koste deg

• En burst av bot-trafikk eller en liten DDoS treffer den uskjermede serveren din på morgen for en stor kampanje — siden kryper eller faller, kunder får feil ved kassen, og du mister dagens salg mens webhotellet slukker branner. En CDN/WAF foran ville ha absorbert det.
• DNS-en, nettstedet og e-posten din kjører alle gjennom én leverandør; den leverandøren har en driftsstans og siden, bookingsystemet OG e-posten din går mørk i samme øyeblikk — du kan ikke engang sende 'vi er klar over problemet' fordi postkassen er nede.
• Et automatisert angrep sonderer siden din hele natten — SQL-injeksjons- og innloggingsgjettingsskript som hamrer opprinnelsen direkte fordi det ikke er noe brannmurlag for å filtrere dem — og du finner ut av det bare når noe brekker. En WAF blokkerer størsteparten av den støyen før den noen gang når koden din.
• En hendelse treffer og ingen kan svare på det grunnleggende spørsmålet 'hvem ringer vi engang?' — er nettstedet på samme webhotell som e-posten? Hvem driver DNS-en? Timer renner bort bare med å kartlegge rørsystemet mens siden forblir nede.
• Et prospekts IT-team skanner deg før de signerer og ser en bar opprinnelsesserver uten CDN/WAF og en server-versjonsheader som reklamerer nøyaktig hvilken programvare (og versjon) du kjører — et lite 'disse menneskene har ikke herdet det grunnleggende'-signal på verst mulig tidspunkt.

Hvorfor det er viktig. Begge sjekker her er informative i metodikken vår — de er registrert med null poeng og endrer aldri karakteren din — fordi de beskriver infrastrukturen din heller enn å teste en bestå/feile sikkerhetskontroll. Vi viser dem fordi de kartlegger reell forretningseksponering. Et nettsted uten CDN/WAF tar hvert angrep og trafikktopp rett på opprinnelsen, uten filtrering og ingen absorpsjon; å legge til en (Cloudflares gratistier er den vanlige ruten) er en av de høyest-hendelse, lavest-kostnad-oppgraderingene en liten virksomhet kan gjøre. Og et klart leverandørkart — å vite om DNS, nett og e-post er delt eller stablet hos én leverandør — er det første du trenger når noe går galt og forskjellen mellom en begrenset hendelse og en total nedstenging.

Hva dette er, i enkle ord

Hvert nettsted kjører på en server et sted. Spørsmålet denne siden svarer på er: hva står mellom det åpne internett og den serveren — og hvem driver faktisk delene av online-tilstedeværelsen din?

Det er to deler:

1. CDN / WAF — skjoldet foran. En CDN (Content Delivery Network) er et globalt nettverk som sitter foran siden din, betjener innholdet raskt til besøkende hvor som helst, og absorberer trafikkbølger. En WAF (Web Application Firewall) er et filter som inspiserer innkommende forespørsler og blokkerer de skadelige før de når serveren. De populære tjenestene (Cloudflare, AWS CloudFront, Fastly, Akamai, Sucuri og andre) bunter disse sammen. Vi ser på svarene til siden din og rapporterer om vi kan se et skjold foran — og vi noterer hva slags nettserver du kjører, også.

2. Hosting / leverandørkart — hvem driver rørsystemet ditt. Vi leser de offentlige postene som sier hvem som håndterer DNS-en din (katalogen som gjør domenet om til en adresse), og hvem som håndterer e-posten din. Derfra kan vi si om DNS, nettsted og e-post er delt mellom leverandører (robusthet) eller stablet hos én (praktisk, men et enkelt feilpunkt).

Det viktigste å vite på forhånd: på vår scoring er begge disse informative. De påvirker ikke karakteren din. Vi viser dem fordi de beskriver hvor eksponert virksomheten er for nedetid og angrep — noe som er et annet, og svært praktisk, spørsmål enn karakteren.

Hva dette kan koste deg

Disse er ikke abstrakte risikoer — de er de hverdagslige måtene et uskjermet, sammenvevd oppsett gjør et lite problem til en dårlig dag.

• Slått offline den dagen det betyr mest. Siden sitter på opprinnelsesserveren uten noe foran. På morgen av en lansering eller en kampanje, skyter trafikken opp — eller en beskjeden bot-flom treffer — og serveren klarer det ikke. Sider stopper opp, kassen gir feil, og du mister dagens omsetning mens webhotellet slukker branner. En CDN absorberer bølger og en WAF filtrerer søppeltrafikk; sammen er det forskjellen mellom «travel dag» og «nede hele morgenen.»

• Alt mørker på én gang. DNS-en, nettstedet og e-posten kjører alle gjennom én leverandør. Den leverandøren har en driftsstans (det skjer med alle av dem til slutt) og siden, bookingsystemet og e-posten forsvinner samtidig. Du kan ikke behandle bestillinger, og du kan ikke engang sende e-post til kunder for å si at du er klar over det — fordi postkassen er nede. Å splitte leverandørene betyr at én feil er begrenset, ikke total.

• Koden tar hvert angrep direkte. Uten WAF treffer hvert automatisert sond — injeksjonsforsøk, innloggingsgjetting, kjente-exploit-skannere — applikasjonskoden din uten filtrering. Du satser på at programvaren er feilfri og fullt oppdatert, for alltid. En WAF blokkerer det overveldende flertallet av den automatiserte støyen før den når deg, og gjør «konstant bakgrunnsangrep» til «mesteparten filtrert.»

• En langsom, panikkslagen hendelse fordi ingen har kartet. Noe bryter og den første timen sløses på «vent, hvem driver DNS-en vår? Er e-post på samme webhotell? Hvem ringer vi?» Når leverandørkartet er uklart, starter alle hendelser fra null. Å kjenne kartet på forhånd gjør et kaos til en telefonsamtale.

• Et dårlig førsteintrykk for en forsiktig kjøper. Et prospekts IT-team skanner deg før de signerer og ser en bar opprinnelse uten CDN/WAF — og en server-header som åpent reklamerer programvaren og versjonen din. Det er et lite signal, men det plasserer deg i «har ikke herdet det grunnleggende»-kolonnen på nøyaktig feil tidspunkt.

Hva det faktisk er

CDN / WAF — beskyttelseslaget

Når en besøkende (eller en angriper) ber om siden din, kan forespørselen enten gå rett til opprinnelsesserveren, eller den kan gå gjennom en CDN/WAF først. Hvis det er et skjold foran, kan det skjoldet:

• Filtrere skadelige forespørsler (WAF-delen): blokkere injeksjonsforsøk, bot-angrep og kjente exploitmønstre før de noen gang når koden din.
• Absorbere trafikk (CDN-delen): betjene cachet innhold fra servere nær hver besøkende og suge opp bølger, slik at en topp — legitim eller fiendtlig — ikke knuser opprinnelsen.
• Gjøre siden raskere: innhold levert fra en nærliggende kanteserver laster raskere for besøkende over hele verden.

Vi oppdager et skjold ved å se på fingeravtrykkene disse tjenestene etterlater i svarhodene til siden — for eksempel en cf-ray-header (Cloudflare), x-amz-cf-id (Amazon CloudFront), x-served-by (Fastly), x-akamai-transformed (Akamai) eller x-sucuri-id (Sucuri). Vi leser også Server-headeren for å identifisere den underliggende nettserveren (nginx, Apache, IIS, LiteSpeed, Caddy og så videre), og flagget enhver X-Powered-By-header som deler for mye.

Hva «bra» ser ut som: en CDN/WAF oppdaget foran opprinnelsen, og en Server-header som ikke reklamerer et spesifikt versjonsnummer.

Hosting / leverandørkart — infrastrukturavhengighetene dine

Domenet ditt peker stille til flere forskjellige tjenester:

• DNS — katalogen som gjør virksomheten.com om til den faktiske serveradressen. Vi leser navneserver (NS)-postene dine og gjenkjenner vanlige leverandører (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, DigitalOcean, Hetzner, Linode og regionale registrarer blant dem).
• E-post — der e-posten din håndteres. Vi leser MX-postene dine og gjenkjenner vanlige leverandører (Google Workspace, Microsoft 365, Proofpoint, Mimecast, Barracuda, Zoho og andre).

Fra dette kan vi se om disse ansvarsområdene er delt mellom leverandører (en feil i én tar ikke ned de andre) eller stablet hos én enkelt leverandør (praktisk, men én driftsstans eller brudd tar alt).

Hva «bra» ser ut som: som et minimum, DNS holdt av en dedikert, pålitelig leverandør heller enn buntet inn i samme konto som alt annet — slik at domenets katalog ikke deler skjebne med nettstedet og innboksen.

Slik fikser du det (gratis, ~1 ettermiddag)

Gi dette til IT-personen din eller webutvikleren — fiksen er gratis. Å sette en CDN/WAF foran siden koster ingenting på de vanlige gratisnivåene, og å undertrykke serverversjonen er en en-linje innstilling. Det er ingen lisens å kjøpe. (Betalte alternativer her er bare overvåking, porteføljesporing og revisjoner — aldri selve fiksen.) Eierens eneste beslutning er: ja, sett et skjold foran siden.

Fordi begge sjekker er informative, er ingen av dette gradert — men en CDN/WAF er en av de høyeste-verdi-robusthet-oppgraderingene en liten virksomhet kan gjøre, så det er verdt å gjøre.

1. Sett en CDN/WAF foran siden din

Den vanligste, gratis ruten er Cloudflare:

1. Opprett en gratis Cloudflare-konto og legg til domenet ditt.
2. Cloudflare leser eksisterende DNS-poster; sjekk at de importerte riktig.
3. Endre domenets navneservere (hos registraren — der du kjøpte domenet) til de to Cloudflare gir deg. Dette er bryteren som ruter trafikk gjennom Cloudflare.
4. Sett SSL/TLS-modus til Full (strict) slik at kryptering forblir ende-til-ende mellom besøkende → Cloudflare → opprinnelsen. (Unngå «Flexible», som lar den siste strekningen være ukryptert.)
5. CDN og en grunnleggende WAF er nå aktive. Du kan tune WAF-regler senere, men standardinnstillingene filtrerer allerede mye.

Andre ruter, avhengig av stakken din:

• AWS CloudFront — opprett en distribusjon som peker til opprinnelsen; par med AWS WAF for filtrering. Best hvis du allerede er på AWS.
• Sucuri WAF — DNS-basert, krever ingen endringer på serveren; bra hvis du ikke kan røre opprinnelsen.
• Fastly / Akamai — enterprise-klasse CDN-er/WAF-er, typisk for større eller høyere-trafikk-nettsteder.

Etter å ha byttet, test siden, bekreft at HTTPS fungerer overalt, og se på den i en dag. Ikke aggressivt cache sider som må forbli personlige eller live (innloggede områder, handlekurver, kasser).

2. Slutt å reklamere serverversjonen din

Enten du legger til en CDN eller ikke, undertrykk versjonen serveren annonserer — det er gratis informasjon du gir angripere.

Nginx:

server_tokens off;

Apache (i hovedkonfigurasjonen):

ServerTokens Prod
ServerSignature Off

Fjern en overdelende X-Powered-By-header (f.eks. fra PHP eller et applikasjonsrammeverk) på server- eller CDN-nivå — på Cloudflare kan du strippe den med en svarhoder-transformasjonsregel.

3. Fornuftsjekk leverandørkartet (valgfritt, ~10 minutter)

Se på der DNS-en, nettstedet og e-posten faktisk bor:

• Hvis alle tre sitter i én leverandørkonto, vurder i det minste å flytte DNS til en dedikert leverandør (Cloudflare DNS er gratis og rask). Den enkle splittingen betyr at domenets katalog overlever en hostingdriftsstans.
• Skriv ned kartet — DNS-leverandør, webhotell, e-postleverandør, registrar, og innlogging/støttekontakt for hver. Denne ene siden er det mest nyttige du kan ha foran deg under en hendelse.

Plattformnotater

• Google Workspace / Microsoft 365: disse er e-post-leverandørene dine, ikke nettstedet ditt. Å sette en CDN/WAF foran nettstedet berører ikke e-posten, og omvendt — de er separate beslutninger. (Å ha e-post på Google/Microsoft og nettstedet bak Cloudflare er et perfekt godt, bevisst-splittet oppsett.)
• Administrerte nettstedsbyggere (Wix, Squarespace, Shopify): disse inkluderer sin egen CDN og et nivå av WAF-beskyttelse som en del av plattformen, så du er kanskje allerede skjermet selv om header-sjekken ikke navngir en leverandør. Du kan vanligvis ikke legge til din egen Cloudflare foran; det er fint — plattformen håndterer det.
• WordPress på eget webhotell: ideell kandidat for et gratis Cloudflare-lag foran. Kombiner det med et sikkerhetsplugins brannmur for applikasjonsnivåregler.

Vanlige feil

• Kjøre en bar opprinnelse «fordi siden er liten». Små sider treffer de samme automatiserte angrepene og bot-flommene som store — botene sjekker ikke omsetningen din først. Gratistier for CDN/WAF eksisterer nettopp for små sider; å ikke bruke det er å la en enkel gevinst ligge.
• Bruke Cloudflare «Flexible» SSL. Det viser en hengelås men lar tilkoblingen mellom Cloudflare og opprinnelsen være ukryptert. Bruk alltid Full (strict) slik at det er kryptert ende-til-ende.
• Cache de feil tingene. Å aggressivt cache innloggede sider, handlekurver eller kasser kan vise én kundes innhold til en annen eller foreldede priser. Cache statisk innhold; la personlig og transaksjonsbaserte sider være ukachet.
• Stable alt hos én leverandør uten å innse det. Bekvemmelighet er fint hvis det er et bevisst valg — men mange virksomheter oppdager bare at DNS, nett og e-post deler én konto under driftsintansen som tar alle tre ned. Gjør det til en beslutning, ikke en oppdagelse.
• La serverversjonen stå synlig. Det er et gratis, en-linje herding-steg som er lett å glemme. Slå det av.

En merknad om karakter

For å si det helt tydelig: ingen av disse sjekkene påvirker karakteren din. De er registrert i metodikken vår som informative, med null poeng, og vi straffer aldri deg for en uskjermet opprinnelse eller et enkelt-leverandør-oppsett. Vi rapporterer dem fordi de beskriver reell eksponering for nedetid, angrep og sakte hendelse-gjenoppretting — og fordi å legge til en gratis CDN/WAF er en av de beste-verdi-oppgraderingene en liten virksomhet kan gjøre. Hvis du ikke gjør noe her, er karakteren din uendret. Hvis du setter et skjold foran siden og splitter DNS-en, har du gjort virksomheten meningsfylt mer robust gratis. Det er den riktige måten å lese denne siden: ikke et tall å forsvare, men en robusthetsforbedring verdt å ta.

FAQ