Alla artiklar
#cloudflare#waf-bypass#origin-security#zero-trust#sni-deception#cdn-security#underminr

Varför Cloudflare-proxy ensam inte räcker

Alexander Norman

"Tillåt inkommande endast från Cloudflare-IPs" är en svagare regel än den verkar, den litar på alla CF-kunder, inte bara din zon. Här är vad angripare faktiskt kan göra med setupen, och vad Cloudflare Tunnel åtgärdar som den regeln inte gör.

Uppdatering 2026-05-24: ADAMnetworks publicerade nyligen en formell paketering av samma attackvektor under namnet "Underminr" (underminr.ai/technical). Deras analys täcker samma fundamentala observation som vi beskrev i april: delade CDN edge-IPs i kombination med SNI/Host-baserad routing kan utnyttjas för cross-tenant unauthorized access.

Skillnad i perspektiv: deras paketering fokuserar på offensive use (C2, exfiltration, defense evasion). Vår analys från 15 april var defender-orienterad ("tillit till CF-IP-listor räcker inte"). Båda är giltiga.

Rekommendationerna nedan gäller fortfarande. Kort sammanfattning för otåliga läsare:

  1. WAF-regler som accepterar "trafik från CF-IPs" skyddar inte mot cross-tenant attack via CF Workers, Proxied DNS, eller Tunnel ingress.
  2. Den enda lösning som fungerar är Cloudflare Tunnel (med originServerName-validering) eller mTLS från CF till origin med privat CA.
  3. Om du redan kör mTLS eller Tunnel kan du ignorera Underminr säkert.

Vill du verifiera din egen exponering? Kör en origin-bypass test mot dina externa tjänster. Vi erbjuder det som del av pentesting.se.


Många organisationer sätter Cloudflare framför sina webbapplikationer och antar att de är skyddade. WAF-regler, DDoS-skydd, bot management, allt hanteras av Cloudflare-edge.

Men det finns ett fundamentalt problem med den vanligaste setupen: om din origin-server accepterar trafik från någon Cloudflare-IP kan varje Cloudflare-kund nå den direkt.

Problemet: delade IP-ranges

När du proxar din domän genom Cloudflare flödar trafiken så här:

Användare → Cloudflare Edge → Din origin-server

För att "skydda" origin lägger många team in firewall-regler:

Tillåt inkommande HTTP/HTTPS från Cloudflares IP-ranges

Det låter logiskt. Bara Cloudflare når origin. Förutom...

Cloudflares IP-ranges är delade mellan alla ~30 miljoner domäner i nätverket. Vilken CF-kund som helst kan routa trafik genom samma IPs via:

  • Cloudflare Workers — deploya en Worker som hämtar din origin med valfri Host-header
  • Proxied DNS — skapa en A-record som pekar på din origin-IP i sin egen CF-zon
  • Cloudflare Tunnel — konfigurera en tunnel ingress-regel med httpHostHeader-override

Alla tre metoder gör att trafik ankommer till din origin från Cloudflares IP-ranges, vilket helt kringgår dina brandväggsregler.

Att hitta origin-IP:n

Första steget för en angripare är att upptäcka din origin-IP. Trots Cloudflare-proxy är det ofta trivialt:

Icke-proxade subdomäner

mail.example.com    → 203.0.113.10   (Oderland, direkt)
www.example.com     → 104.16.x.x    (Cloudflare, proxad)

Mailservrar, FTP, cPanel, staging-miljöer, dessa pekar ofta direkt på origin.

Certificate Transparency-loggar

Varje TLS-certifikat som utfärdas loggas publikt. En sökning på crt.sh avslöjar subdomäner som kan ha funnits innan Cloudflare lades till, eller interna tjänster med egna certifikat.

Historisk DNS

Tjänster som SecurityTrails, RapidDNS och Shodan sparar historiska DNS-records. Även om ni flyttade bakom Cloudflare för år sedan finns den gamla A-recorden som pekar på origin bevarad.

Shodan / Censys

Sökmotorer för internet-anslutna enheter indexerar din origins IP, portar och TLS-certifikat, ofta med exakt vilket hostname som serveras.

Bypassen i praktiken

När en angripare har origin-IP:n kan de:

  1. Ansluta direkt — om origin accepterar trafik från vilken källa som helst (ingen brandvägg alls)
  2. Routa genom Cloudflare — om origin bara accepterar CF-IPs, använd Worker/proxied DNS/tunnel

Det andra fallet är det intressanta, och det är värt att vara exakt med vad som faktiskt kringgås:

  • Kringgås: origin NSG / brandväggs-allowlist som litar på CF IP-ranges. Requesten lämnar fortfarande CF:s nätverk, bara från en annan kunds zon, så origin ser en legitim CF-source-IP.
  • Fortfarande genomfört (i de flesta fall): target-zonens WAF-regler, rate limiting, bot management och Access-policies. De ligger vid edge för targetens zon, inte vid origin. Om angriparens Worker sätter Host: target.example.com routas requesten tillbaka genom target-zonen och dess WAF utvärderar payloaden.

I våra egna auktoriserade tester bekräftade vi detta: Worker-routade LFI-payloads blockerades fortfarande med 403 av target-zonens WAF, och Access-skyddade rutter omdirigerade fortfarande till IdP-inloggningsflödet.

Det verkliga bypass-värdet är snävare men fortfarande allvarligt: det besegrar "endast Cloudflare-IPs"-brandväggsregeln, som ofta är det enda lagret mellan angripare och origin. När IP-allowlistan är besegrad kan angripare:

  • Räkna upp origin direkt utan att träffa er WAF alls (via Mode 3, om NSG är svag).
  • Sondera efter origin-tjänster som inte fronts av CF (admin-panels, staging, APIer på andra portar).
  • Utnyttja felkonfigurationer där target-zonens WAF-regler är svagare än antaget — t.ex. en permissiv path-regel vid origin som blockar vid edge men inte när den nås med en annan SNI.

Lösningen: Cloudflare Tunnel (cloudflared)

Den korrekta arkitekturen använder Cloudflare Tunnel (tidigare Argo Tunnel):

Användare → Cloudflare Edge → cloudflared-daemon → Din origin

Nyckelskillnad: origin lyssnar aldrig på en publik IP. cloudflared-daemonen kör på din server och initierar en utgående anslutning till Cloudflare-edge. Inga inbound-brandväggsregler behövs.

Det betyder:

  • Ingen origin-IP att upptäcka
  • Inget sätt att ansluta direkt
  • Inget sätt att routa genom en annan CF-zon
  • All trafik tvingas passera genom ER Cloudflare-zon, och därför ER WAF, rate limits, bot rules och Access-policies

Alternativ: Authenticated Origin Pulls

Om du inte kan använda Tunnel, aktivera Authenticated Origin Pulls, mTLS mellan Cloudflares edge och din origin. Din origin verifierar ett klientcertifikat som bara ER zon presenterar.

Det döljer inte din origin-IP, men säkerställer att även om en angripare routar genom Cloudflare avvisar din origin anslutningen eftersom de inte har rätt klientcertifikat.

Checklista för försvarare

  • Origin-server har ingen publik IP (använder Cloudflare Tunnel)
  • ELLER: Authenticated Origin Pulls aktiverat med mTLS-verifiering
  • Inga icke-proxade subdomäner som läcker origin-IP (kolla: dig +short mail.example.com)
  • Historiska DNS-records avslöjar inte origin (kolla SecurityTrails)
  • Origin TLS-certifikat läcker inte i Shodan/Censys
  • NSG/brandvägg blockar ALL inbound utom tunnel-trafik
  • DNSSEC aktiverat på domänen

Vår automatiska detektion

Pentesting.se detekterar nu automatiskt Cloudflare origin-bypass-sårbarheter som del av discovery-scannen:

  1. Identifierar CF-proxade domäner
  2. Sonderar vanliga icke-proxade subdomäner (mail, ftp, cpanel, staging, dev)
  3. Kollar Shodan för origin-IP-bekräftelse
  4. Testar origin-åtkomst på port 80 och 443
  5. Rapporterar fynd med specifika åtgärdsförslag

Detta körs vid varje discovery-scan, ingen manuell konfiguration behövs.


Alexander Norman är grundare av Adminor AB och Pentesting.se, en kontinuerlig säkerhetsbevakningsplattform för nordiska företag.


Se även i ordlistan: WAF, mTLS, TLS, CDN, DDoS, LFI.

Vill ni se vad er externa angreppsyta egentligen ser ut? Gratis hälsokoll, ingen creditcard, två minuter.