Subscribe to receive notifications of new posts:

Mars Attacks!


4 min read

Following on from my recent post about when attacks hit CloudFlare, here's a follow up looking at where they come from. Or at least where they say they come from. Looking at attack statistics for the month of July 2012 the largest source of attacks is Mars.


Of course, not literally from Mars itself, but from what network engineers refer to as 'Martian IP addresses': IP addresses that are otherwise valid but shouldn't appear on the public Internet. For example, many corporate networks use the IP address range, and many home users will be familiar with addresses in the address range. Both of those addresses are valid, but not valid on the public Internet. When machines in a home or corporate network actually communicate onto the public Internet those internal addresses are converted to a public address by a technique called Network Address Translation (or NAT). If you're on a home or corporate network right now you can find your public IP address using the CloudFlare-powered

Full details of the reserved blocks of IP addresses can be found in RFC 5735.

We see vast numbers of attacks with IP addresses such as (apparently from inside a network), (apparently from inside the machine that's being attacked--spooky), (inside a corporate network), and (used on a local, private link).

Thanks, XKCD

Because these addresses are invalid on the public Internet when we build our attack statistics they appear as an invalid network. Looking at the top, potentially spoofed, networks that attack CloudFlare shows that invalid accounts for 23% of attacks, followed by 3.45% from (apparently) China Telecom, 2.14% from China Unicom, 1.74% from Comcast, 1.45% from Dreamhost and 1.36% from WEBNX. And then, on and on, for 37,284 different networks around the world. With a total of 41,838 networks, we've apparently been attacked during July by 89% of the networks on (this) planet.

It's also not surprising to see China Telecom high on the list: it's the largest network in the world announcing to the Internet that it has 114,212,832 addresses.

Of course, this traffic didn't necessarily actually come from those networks, and certainly not from Mars, unless NASA's Curiosity dropped off some servers on its way down, because the source IP address is being spoofed or forged.

The attackers can spoof the source IP address (where the packet says it comes from) because they do not need a reply. In most cases the attacker is simply seeking to overwhelm a CloudFlare Internet connection, or server, with traffic. There's no need for a reply at all, just a huge flow of packets. Forging the IP address means that the source cannot be easily determined.

And in some cases the IP address is legitimate but actually the IP address of an innocent victim. In the case of DNS or SNMP reflection attacks where a legitimate DNS or SNMP server is fooled into sending packets to attack CloudFlare, the source IP address is a real server. CloudFlare sees a great number of reflection attacks against our DNS infrastructure.

DNS reflection works like this: an attacker sends a DNS query to a DNS server on the Internet with a forged source address. The source address being forged is set to the address of a DNS server at CloudFlare that the attacker wants to overwhelm. The innocent DNS server that receives the packet sends a reply to the source adderss at CloudFlare. Of course, CloudFlare never sent the original packet, by address spoofing made it look like we did.

Of course, the attacker doesn't do this with one DNS server, they do it with hundreds or thousands so that CloudFlare suddenly receives a huge wave of DNS replies we didn't ask for. And, ironically, we get frantic calls from network managers asking us to stop attacking them. Since they see the source IP address is CloudFlare they, naturally, assume we've sent the traffic.

Mars Attacks!

Worse, reflection attacks also have an amplification effect as well. Since a DNS query packet can be very small (60 bytes, for example) and the reply much larger (e.g. 512 bytes), it's possible for an attacker to amplify the bandwidth available to them by sending thousands of small packets to DNS servers which respond to the CloudFlare server with a large packet. That means that the attacker uses a small amount of outgoing bandwidth to hit CloudFlare at a much greater rate.

The upshot is that when looking at layer 3/4 attacks the source IP is mostly useless: it's likely bogus or the address of a victim not an attacker.

So, Curiosity can trundle across the Martian landscape safe in the knowledge that CloudFlare's network team won't be firing back any response to those Martian packets.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
ReliabilitySpeed & ReliabilityAttacksDDoS

Follow on X


Related posts

September 29, 2023 1:00 PM

Cloudflare is free of CAPTCHAs; Turnstile is free for everyone

Now that we’ve eliminated CAPTCHAs at Cloudflare, we want to hasten the demise of CAPTCHAs across the internet. We’re thrilled to announce that Turnstile is generally available, and Turnstile’s ‘Managed’ mode is now completely free to everyone for unlimited use. ...