If you’re hosting a web service behind Cloudflare, properly hiding your origin IP address(es) requires blocking all HTTP/HTTPS traffic that doesn’t come from Cloudflare. Whitelisting is important to prevent attackers from scanning the internet and finding your origin IP.
First, we block all http/https requests by dropping TCP requests to port 80/443.
# iptables -A INPUT -p tcp --dport http -j REJECT --reject-with tcp-reset
# iptables -A INPUT -p tcp --dport https -j REJECT --reject-with tcp-reset
We’ll use iptables with the reject-with tcp-reset flag. Without this flag, an attacker can still detect that a program is listening on the port, whereas with the flag, the port will appear to be closed. The difference can be seen in nmap, were a regular reject shows up as “FILTERED” and a tcp-reset reject shows up as “CLOSED”.
Next, we’ll add the Cloudflare IP ranges so they can connect to our host.
# for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport http -j ACCEPT; done
# for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport https -j ACCEPT; done
Now we’ve ensured that only Cloudflare servers can access ports 80/443! To everyone else, it appears that the server isn’t running anything on those ports.
If your server has IPv6 interfaces, you’ll also need to run the same commands using ip6tables:
# ip6tables -A INPUT -p tcp --dport http -j REJECT --reject-with tcp-reset
# ip6tables -A INPUT -p tcp --dport https -j REJECT --reject-with tcp-reset
# for i in `curl https://www.cloudflare.com/ips-v6`; do ip6tables -I INPUT -p tcp -s $i --dport http -j ACCEPT; done
# for i in `curl https://www.cloudflare.com/ips-v6`; do ip6tables -I INPUT -p tcp -s $i --dport https -j ACCEPT; done
Here’s an old (over a year) post that’s been sitting in my queue for a while. Some things may be out of date.
Many web administrators use Cloudflare to mask their server’s IP address to protect against DDoS attacks. Cloudflare works by sitting between clients and the server. With Cloudflare running as a middleman, a server’s IP never needs to be revealed to the public, since public clients connect through Cloudflare. Any attacks are routed first to Cloudflare, who can provide defenses and protect the origin server. Unfortunately, there are many other ways that an attacker can still resolve the original server’s IP address, bypassing Cloudflare’s protection and attack the origin directly.
In this post, I’ll highlight some methods, provide a short background on how/why they work, and give steps on fixing them.
The most basic technique, used by almost all “Cloudflare IP Resolvers”, is brute-forcing DNS records. But first, let’s go over some background information on how this works. Suppose you are the web administrator in charge of example.com, with the IP address 188.8.131.52.
The classic diagram of Cloudflare is this:
HD Moore from Rapid7 recently disclosed that over 5800 Automated Tank Gauges at gas stations around the world were publicly accessible. Anyone connected to the internet can now view the in-tank inventories of the gas stations and manage the gas tanks.
The process to access the gauges is simple:
1. Telnet into port 10001 of an ATG’s IP.
2. Type ^A (Ctrl A) followed by I20100. This command outputs a basic report.
There are over 600 commands that can be executed, some of which include setting alarm thresholds, editing sensor configurations, and running tank tests. You can view them all in the vendor manual.
A list of affected IP’s can be found on Shodan.
LizardSquad, the “hacker” group that recently DDoSed Microsoft’s and Playstation’s gaming networks, released a DDoS tool/service that can be found on www.lizardstresser.su.
LizardStresser is simply another booter, a tool that anyone (mostly script-kiddies) can pay to DDoS a target. Like every other booter, LizardStresser is accessible through a webpage (www.lizardstresser.su) where users can signup and pay for booter access.
Not surprisingly, LizardStresser is extremely poorly written, which led to me to find a user enumeration vulnerability in a few minutes.
Dumping Usernames and UIDs
Through lizardstresser.su’s ticket system, users can request customer support from admins.
After a ticket is created, a user can send messages through the ticket.
Skip to the good part.
Some background info:
In the early years of high school, I was a part of a community that produced game mods (which I’ll now call AAA). There was another community who also developed similar mods (which I’ll now call BBB). Not surprisingly, there was a lot of animosity between the two communities and it quickly escalated to more than competing by building better products.
While both communities didn’t condone it, members of both eventually started launching DDoS attacks against other. The impact of these attacks was more than just taking down the community forums. Since both communities developed game mods, downtime of the servers meant downtime for their thousands of users.
Members of both communities launched DDoS using boaters. Booters, or “network stress testers”, are DDoS services usually comprised of compromised dedicated servers that send massive amounts of traffic. Booters are relatively cheap and extremely easy to use – the perfect option for script kiddies. At the time, an effective booter would cost just a few dollars for an hour of DDoS’ing. If someone wants to take down a server, he goes onto the booter, types in the IP and port, and the attack is sent.
A screenshot of a booter’s control panel.
The downtime had a significant impact. Too much downtime would cause users to leave. Losing customers meant a loss in revenue. At the time, both communities had peaks of 10k simultaneous users each – not a small number.
The admin of AAA was considering paying for DDoS protected servers, which were very, very expensive at the time. The profit margins from the community could not justify renting such a server.