Are you looking to make this feature available to only the paid tier or also to the free tier? Wasn't certain based on the blog posting, but most of the time you'll say if a feature is enterprise only, etc.
Currently on the free tier for my personal projects and would love to play with this on my personal k8s cluster.
It's gross to advertise your own company, but the weather's bad soooo ...
We have an open source tool called wormhole that works similarly. You can run it yourself, or use it on fly.io (including the free tier): https://github.com/superfly/wormhole
Getting back to it myself. Ultimately my past successful works have have never been intended to be. And I enjoy them still, upon rediscovery. So not much to lose except the feeling of being redundant. It's good to stay current but also habitually create with minimal inhibition.
For many, many DDoS scenarios this does not work. The spurious packets may saturate an upstream ISP, causing that ISP to unilaterally apply a null route or block for all packets for the targeted origin IP. No CloudFlare packets would arrive at all.
If one is concerned about DDoS, one should work with their ISPs on the plan of action for various scenarios. Finding out their procedures when ones' hair is on fire is not fun.
It's not so much about changing the IP address, but moving the targeted system out from behind the clogged tube. Changing IP address may or may not do that.
Allowing only cloudflare IPs for ports 80/443 (e.g. in nginx) is easy and the server can still be used for other purposes without Cloudflare. Other services can use different domains, would be hard to find out the server ip this way.
IPv4 space is far too small not to use this. Often times if an attacker has determined your provider in the past, they may be able to leverage that information and scan only nearby ranges.
Other common anti-DDoS proxy bypass tactics:
- direct.* subdomain used to be used by default on CloudFlare for a direct route to the server
- Check headers in outgoing emails for an origin IP (this one gets way too many sites)
- CloudFlare only recently got websocket support - check if their websocket servers are secured or not
- Check for an MX record
- Use DNS bruteforcing tools to attempt to find other services
We don't change the IPs often and we always update the list well before they are ever used (typically months before). The last update was two years ago. I'm sorry if you had a problem.
I remember being affected by this too a few years ago. It's not something I thought to check and update often. I was disappointed that I was never emailed or otherwise notified by the change.
This technique is in use for years, just get IP classes from CF website and set them in your iptables for ports 80/443 + any other IPs (yours, from your organization etc) and drop the rest.
Another way to get IPs is reading e-mail headers (register account on target website to get e-mail etc), so many sites behind CloudFlare expose their webservers IPs there.
It's also possible to bypass Cloudflare if the target allows remote / external file upload (e.g avatar upload on forums, host the the relevant avatar on your own server and check your webserver access logs).
Unfortunately, iptables can't protect against all forms of DDOS attacks. Even just getting flooded by packets being routed to a particular IP can cause a datacenter's network to be affected. Something like CloudFlare Warp is the only way to truly prevent packets from being routed to your servers in the first place (I don't work for CloudFlare).
If it's not known where your servers are (because you got new IPs in a new hosting facility and never allowed them to communicate with the outside world directly), it's true that a packet flood would affect you, but it you would be awful hard to target.
Just changing IPs is not enough if the new allocation is publicly linked to your company. It may help to get IP space through a third party or shell company to anonymize it a little more, and make sure it is never publicly identifiable as yours, either in paperwork or through scans.
It would be good if AWS et al had an easy way to manage third party ip ranges for security groups. When I was deploying a site we came across this issue and so whitelisted Cloudflares ip ranges but it made me uneasy because what happens if a new IP address is added? How do we manage this list and what sort of notice is provided?
the JS DDOS portal, while amicable in intention, exists in a privileged place among hosting service providers. Dreamhost found out all to well how easy it was to be targeted in dragnet federal litigation designed to violate the privacy of internet users. Cloudflares JS is innocuous only in that it --to public knowledge-- is not being used to unmask anonymous proxy users or silently track specific site visitors in a dragnet fashion.
Im not too encumbered by JS encapsulation at the moment, but a warrant canary might put my mind at ease assuming the internet still does those
https://en.wikipedia.org/wiki/Warrant_canary
Cloudflare has a transparency report[0], updated twice a year.
In the transparency report there's a warrant canary:
Some things we have never done
Cloudflare has never turned over our SSL keys or our customers' SSL keys to anyone.
Cloudflare has never installed any law enforcement software or equipment anywhere on our network.
Cloudflare has never terminated a customer or taken down content due to political pressure.
Cloudflare has never provided any law enforcement organization a feed of our customers' content transiting our network.
>Where do you draw the line between political pressure and the management's political beliefs?
So far, Cloudflare's most notorious content on the other side of the line has been Daily Stormer back in August of 2017.
>The tipping point for us making this decision was that the team behind Daily Stormer made the claim that we were secretly supporters of their ideology
That latest report says it covers the first half of 2017 so we'll have to wait to see whether they consider the actions from the second half of the year to change the fourth item on that list.
Is it concerning yet that they haven't put up their semi annual warrant canary, actually? The last two times, they had it updated by January 14th [0] and July 8th.[1]
