CloudFlair: Bypassing CloudFlare using Internet-wide scan data | Hacker News Reader

CloudFlair: Bypassing CloudFlare using Internet-wide scan data

blog.christophetd.fr

151 points68c12c1648 comments

See also Cloudflare Warp https://blog.cloudflare.com/introducing-cloudflare-warp/ which enables you to hide completely and connect to Cloudflare and also the use of this to expose k8s to Cloudflare natively: https://blog.cloudflare.com/cloudflare-ingress-controller/

Is there a way to get bumped up on the beta queue? Thanks!

Email jgc @Cloudflare

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

Another option is webrelay ingress controller for k8s, also tunnel based :) https://webhookrelay.com/v1/examples/relay-ingress.html

Warp is pretty good, but it doesn't support websockets.

yet

Slightly off-topic:

> A few minutes before publishing this article, someone brought to my attention that a similar piece had been written a few months ago

This can be demotivating. I've been trying to remember that I should write for myself, to collect my thoughts and not to satisfy the interwebs.

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.

You can also potentially view the historical DNS A records for the domain to view the pre-Cloudflare IP at http://viewdns.info/iphistory/.

If you're determimed, though, you just null route, or block, etc, everything other than Cloudflare inbound.

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.

Well you're behind CloudFlare.

Just change your IP address, and tell CloudFlare the new one.

Sure the DDOSers could find your new IP, but it's not like changing your public DNS, it would be difficult for them to find it.

I don't think your SSL certs would show the new IP on the website in the blogpost very quickly if you changed IP.

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.

It’s easier than you might think, I used to blackhole anything non-Cloudflare and they offer a list of their IP’s:

https://www.cloudflare.com/ips/

Great post. Also, Cloudflare Warp looks like it will be cool.

(disclaimer: I work on DNSTrails) Another way to find the origin is to use trails left by DNS using a tool like https://www.DNSTrails.com.

You can see a sample with a site that moved to Cloudflare like this: https://dnstrails.com/domain/haveibeenpwned.com

when the origin is properly secured (which we encourage all customers to do) even passive DNS won't help: https://dnstrails.com/domain/canhazip.com

nice!

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.

Yes, CloudFlare even provides official lists for this purpose.

https://www.cloudflare.com/ips/

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

> Check headers in outgoing emails for an origin IP (this one gets way too many sites)

Are there any workarounds for this, other than running mail servers on a separate network and IP range?

Use Amazon SES to send your email. SES actually conceals your origin IP -- unlike other providers like Sendgrid, which include it.

Run your mail server on a different provider and configure it to strip the relay headers - some mail relay services may also work for this purpose.

it's far from an ideal solution given they keep changing the lists

I only seem to find out when people complain that the site is down from certain parts of the world

keeping changing the lists

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.

https://www.changedetection.com/log/cloudflare/ips-v4_log.ht...

EDIT: I was rude in the previous version of this comment. Sorry for being a jerk. And thanks to dang for letting me edit.

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.

I'm surprised services like AWS don't have a CloudFlare option from a dropdown menu when setting up a firewall.

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.

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.

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).

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?

Cloudflare has text files here https://www.cloudflare.com/ips/ - would be cool if there was some standard protocol for this.

DNS AXFR query would be suitable, I think. https://en.wikipedia.org/wiki/DNS_zone_transfer

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.

[0] https://www.cloudflare.com/transparency/

Where do you draw the line between political pressure and the management's political beliefs?

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]

[0] https://web.archive.org/web/20170114100401/https://www.cloud...

[1] https://web.archive.org/web/20170708164222/https://www.cloud...

>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

https://news.ycombinator.com/item?id=15029852

https://news.ycombinator.com/item?id=15034304

I think the writer is not aware of mod_cloudflare https://www.cloudflare.com/technical-resources/

Another thing that you can do is use Apache virtual hosts and send all traffic that connects to the IP to an empty page.

Is warp just "railgun" rebranded? That worked well for my company, when it worked.

No, it's a totally new code base and different model.

Funny.. next time please finish the article in two or three sentences.

https://news.ycombinator.com/item?id=13719366

Reply on news.ycombinator.com