IP Tables
How can I setup a IP Table that blocks traffic unless it's coming from any Cloudflare IP (Tunnel, Cloudflare Reverse Proxy, etc)
https://www.cloudflare.com/ips/ I was told this does not have the tunnel ip ranges
Cloudflare
IP Ranges | Cloudflare
This page is intended to be the definitive source of Cloudflare’s current IP ranges.
49 Replies
Cloudflare Tunnel doesn't prevent inbound connections directly to my IP from anyone not CF which is why I want to set this up.
How?
I'd like to block everything but SSH (ofc)
If you're using something like UFW, then
ufw allow <your-ssh-port>/tcp (ex. ufw allow 22/tcp)
ufw default deny incoming
otherwise, it depends on the firewall you are using. If you are using a VPS with an external firewall (Hetzner, Ovh, etc), I would configure those settings with them as well
Your rules wouldn't work when it comes to Cloudflare Tunnel I thought or am I thinking of CF Tunnel incorrectly and it works by having the orgin send outbound rather than inbound requests coming from CF?
Correct, Cloudflare Tunnels work by running a local daemon/service on your PC called cloudflared. This service connects outbound to Cloudflare's Edge, just like how you can visit https://cloudflare.com without port forwarding/opening any inbound ports. Firewalls like UFW are stateful and understand that the connection was established outbound and will keep track of it/allow it through
That's what makes CF Tunnels so cool, no need to expose ports, or even have a static IP
Yeah I'd have to agree.
I personally can't fathom how this is possible though you know
My brain won't comprehend how it knows someone needs something/making a request
my only guess is its using websockets perhaps or polling a CF API that tells it?
🤷♂️
;-;
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
My head still can't wrap around it! It's an amazing technology tbh
My only issue is you can't block inbound without extra softwarw
Would be awesome if you can do it with cloudflared
IP Tables & UFW is still hard to grasp for me, and one of our host providers still does not provide backups
Our main server does
ufw is pretty simple, there's lots of tutorials out therre about it if you're having issues. Usually as simple as blocking inbound and opening specific ports as needed
I mean, you can just block inbound with WAF, or a reverse proxy in between cloudflared and your app
I just tested my CF website which is barely configured right now
I have good hardware and network, but for some reason when I tried hitting my website API: it went down
It uses CF Tunnel
I'm curious how'd it go down if my server uses outbound connections, and receives nothing inbound
It wouldn't be due to resources or network, I have a EPYC 7402P VPS w/ 6 cores, 12gb DDR4, and 10gbps In/Out
Could the Cloudflare Tunnel have gone down? Under normal circumstances, a Cloudflare Reverse Proxy can never be downed (as they are massive NAT network of servers built for millions of requests), but is it not the same for CF Tunnel?
What do you mean it went down? If you're getting bad gateway/522, your tunnel is reachable but cannot contact origin, check tunnel logs (i.e journalctl -u cloudflared -f --lines=100)
I mean in theory it can absolutely go down, the fact it's outbound doesn't matter, you lose internet, connectivity to CF, CF loses the connection, etc.
The tunnel does do stuff to prevent that though, it establishes multiple redundant connections to at least two different Cloudflare datacenters/colo, it probably didn't go down, even if a connection fails it just retries but I can only guess, logs / exact error would be helpful
Tunnel Requests go through the same reverse proxy, they then get routed to your tunnel. There is a bit of overhead with tunnels, but they make up for it by scaling connections when needed and such. (and not that it really matters for this case, but they are not NAT, it's all anycast) (and opps, realized I pinged 3 times, should have turned it off, my bad)
status code 429
OHHH I KNOW THE ISSUE
you have unmetered rate limiting configured on your zone?
I ratelimit on my server
I don't use CF as i'm on free currently- which is really limiting
I think that might be the issue?
ah ok, you'll have to configure your rate limiting to use the CF-Connecting-IP header to rate limit by
Nevermind.
It isn't, odd.
I don't have CF Ratelimits up rn
so is cf ratelimiting me
Unless you have a rate limiting rule configured on your zone (Security -> WAF -> Rate Limiting Rules), no
Then why is a 429 being issued
I had one setup, but it was disabled.
What are the headers on the response? If it's a public website, can you share the url?
When it was down or right now?
When it was serving 429 responses
Don't know, did not check
Well that's what I would check for if it happens again, If you see the CF-Cache-Status header, it's your origin rate limiting you.
It sounds like its likely to be your origin, if you had rate limiting on it before.
Keep in mind when you are using tunnels, it sees all traffic coming from the same local ip. If your application does rate limiting, it needs to use the CF-Connecting-Header to get the real IP of the user
Could it perhaps be our DDos Protection provider?
I don't see how it would though as L7 was hit and not L4, and afaik from our conversations traffic isn't exchanged inbound w/ my orgin when you use Cloudflared
Unless the tunnel is pointed at it, no
Tunnel is pointed at our IPv4
If the tunnel is just connecting locally to a web server, they're not involved
Tunnels don't exchange data inbound
so this is why I am very curious
The protection doesn't protect upstream/outbound
Then it's probably unrelated, I doubt the protection is L7 either
So the CF Tunnel went down
Did Cloudflare null route us during the attack lmao
If the tunnel was dying from requests, you'd see a 1033 / Argo tunnel error (which I think is a 520 http response, something in the 500 range, def not 429)
If you have logs I would check them, i.e if you're running cloudflared as a system service, use
journalctl -u cloudflared -f --lines=1000
Ultimately though, it's either your origin returning 429, or CF Rate limiting (technically could be a Worker or something else custom, but you would have to have configured that) . The tunnel being down wouldn't return that status code. Protection blocking people would return 403, etc
Might be Pages/worker specific. I believe Workers themselves get upset after too many requests from a single IP, not sure what code they returnTunnel itself should be fine eitherway, just for fun I tested sending 5k request/s at a tunnel with 4 connections, and it just ate it. Your real origin behind tunnels is going to die far before the tunnel itself would
yea they're solid, not going to be the bottleneck
that's a 503 looks like
...the counter decreases accordingly. If the value of the counter is beyond a certain threshold, the request is rejected with a 503 error response
Yes, but the issue is what leaks from CF L7 Protection
You can get upward to like ~250,000-500,000 leak on a 1,000,000 RPS attack no matter what for example.
I'll likely have 25-35k RPS leaking on a 100k RPS attack- which I expect a lot of soon.
If it takes 4,000 RPS to overwhelm the CF Tunnel, I'm confused.
I could just not use CF Tunnel
and use Orgin Rules
Just- I do not know how to configure orgin rules to where for example
api.websitehere.com runs off IP:80 meanwhile stats.websitehere.com runs off IP:3000
Cloudflare is god damn awful at filtering attacks no matter how you configure it, it's good at tanking the initial RPS burst so that your server just doesn't straight up die from having a billion requests show up out of no where
I personally think this is a CF Tunnel issue
I don't think it's built for DDos Attacks
It assumes it'll perfectly migitate/filter every attack without leakage
Doubt that, I have enough resources to where it won't just straight up die
I have a 10gbps In/Out dedicated to myself meanwhile, the node NIC is 40gbps
Doubt my network would be manhandled, and my entire infrastructure is multi-threaded
While I attribute this to I haven't 100% configured things like rate-limiting, it should be able to handle 4000 RPS or whatever leaks easily
So pretty much 🤷♂️
Need to figure out how orgin rules work
Docs still confuse me
There is a lot of helpful guides out there for mitigating ddos attacks (<https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366), unmetered rate limiting which you can configure (https://blog.cloudflare.com/unmetered-ratelimiting/), community firewall rules, from community members like Leo (https://gist.github.com/Le0Developer/4c68f9a878a4cc2db88755ae06191dbc). There's a lot of configuration you can do to block http/1.1, challenge commonly abused ASNs, etc, depends exactly on your attack though
Tunnels can handle a ton of connections, 5k requests/s was just my test. I was testing on a single 7900x vCore, any more requests would be limited by cpu/nginx
Origin Rules are really simple, they use the same ruleset engine as every other type, a bit confusing at first but easy to grasp after a bit. Your ports confuse me though. Unless you are running HTTPS on port 80, you should really use https/configure a proper cert. (Note: This isn't needed for tunnels -- tunnels establish a secure outbound connection and just connect locally, so it's fine to use http with them as long as the configured service is local)
Cloudflare offers Origin Certs, certs only trusted by CF Proxy, you can use: https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/
Step 1: Configure your origins for https/proper certificates (either from Let's Encrypt/a trusted root authority, or origin certs)
Step 2: Make sure your SSL/TLS Mode is Full (Strict) (SSL/TLS -> Overview)
Step 3: Create a origin rule, hostname equals stats.example.com, dest port override 3000
We do plan on using SSL Certificates yes- but we haven't done it yet as the new API is not public yet
Theoritically I can run my backend on any port that is compatible with HTTP(s)
Do I just use hostname to specify the subdomain?
yep
without the scheme or anything else, ex. stats.example.com
I just use UFW (https://github.com/Paul-Reed/cloudflare-ufw). Those settings look sane to me though, other then that it looks like they are only allowing normal http (80) / https (443) ports. If you're using the non-defaults would have to change that
Why would I deny all incoming requests when I'm not using CF Tunnels anymore
you deny all incoming and then make exceptions for ssh / cloudflare
Plus this dude's a prick for not putting this first
Likely has costed skimmers so many time
ah
the firewall is not active yet until you do the last command, ufw enable
the very first part of that guide is disabling it if it is already enabled
@chaika.me I'm guessing i can still with Full (Strict) use certbot ssl instead of orgin server correct
yep, the requirements are just
Unexpired, meaning the certificate presents notBeforeDate < now() < notAfterDate.
Issued by a publicly trusted certificate authority or Cloudflare’s Origin CA.
Contains a Common Name (CN) or Subject Alternative Name (SAN) that matches the requested or target hostname.