My website uses Discourse. Initially, it wasn’t protected by Cloudflare and suffered a DDoS attack.
Later, I changed the IP address and implemented Cloudflare. However, the website was attacked again by DDoS, seemingly due to a leak of the origin server’s IP.
When using Cloudflare CDN, how can we prevent the origin server’s IP from being leaked? Does anyone have any good methods? Thank you.
I don’t know but the IP of every servers online will be leaked out at the same time that is created.
You can prevent a lot of leaking by doing the following
HTTPS_PROXY and HTTP_PROXY so Discourse will use that (set them in the env section of your app.yml)NO_PROXY='127.0.0.1, localhost, <internal-network>'See also Install discourse with internet access only via proxy, Configuration outbound proxy and Discourse Link previews through a proxy server? - #14 by supermathie
Also, when you’re behind CF, you can modify the firewall on your Discourse host to only allow incoming traffic from your Cloudflare IPs (and the host you access it from yourself)
This is the solution. Security by obscurity isn’t secure. Then it won’t matter if your ip is common knowledge.
This or alternatively, a simpler approach would be to use what’s called a cloudflare tunnel. It should be a one-time setup and then you should be able to mostly close off your firewall for inbound connections.
I believe I went with this a while ago (without the proxy setup u mentioned). I’m not sure if this applies to all firewalls (or maybe something in my setup)
but in my case with ufw, it’s worth mentioning docker bypasses ufw by default so you need to make sure to apply the rules to your internal docker ip’s as well.
It’s been a while but I can look further into details if you still need this, later this week.
And yes, Cloudflare tunnels are amazing! @itsbhanusharma
You will want to use the firewall that your VPS provider provides for you. Using a host based firewall will be far less effective in fighting a DDoS since the traffic does get to your network stack.
I think most large providers do offer DDOS protection by default? Shouldn’t this be sufficient? Adding CloudFlare IP’s manually through the interface seems like a hassle (my custom bash script takes 2 seconds and auto fetches the CF IP’s for example).
Have to say I usually read the opposite, ufw/local fw over the provider’s fw 
Edit; I do understand the logic here, from ddos perspective this is probably more effective and you’re right. That being said, if the main IP is hidden correctly from the start, ddos shouldn’t be an issue right?
Most providers have an API for that nowadays?
Correct! But that’s a pretty big “if”…
Actually wrong. Just because the IP isn’t never hidden. Ddos isn’t an issue if a reverse proxy or similar has tools to stop it. And even then when there is real attack something more is needed than entry level solution. And if bots or slave users are knocking closed ports or IP-limited ports that isn’t so big issue. I would call it another thursday on WordPress world but Discourse is another world is so many ways.
On other hand, I’m not an expert of this.
But I’m curious… how much traffic is needed that ddos is succesful? Of course it depends of resources of setup, but please give me some numbers.
It depends on your definition of hidden. Yes, all IP addresses are public. But then which of the 4 billion IP addresses is the correct one? I think, for this discussion, the IP can be considered hidden if there is no way to determine the IP address(es) for a server that is serving a specific Discourse forum (so the function f(h) is undetermined where function f gives you the true IP address for a host)
Given:
But I agree with you that “hidden” is a confusing and incorrect term. “unknown” is probably better.
That depends on the type of DDoS. For an application-layer attack this might be true, buit also hard since it would need some kind of rate limiting with request inspection. But for a network-layer attack (simply traffic flooding by amplification or a syn attack) this might not hold. Besides, what you’re basically saying is “it’s not an issue if you can mitigate it” which is kind of obvious, but also hard and/or expensive.
It also depends on the type of attack. An application layer attack would need to be tailored to Discourse but could for instance run some heavy queries like searches to overwhelm the application servers, while a network layer attack can be more generic, take more traffic and can simply clog nginx or the VPS network.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.