Knock knock. Who’s there? Not me.

tl;dr; Port scanning the entire IPv4 address space daily for months at a time generates a lot of very juicy data — and more than a few administrative complains. However, the results of such an exercise are well worth the burden … read more to find out …

While port-scanning a few hosts here and there with nmap can be fun and usually quite easy, doing the same cannot be said when scanning the entire IPv4 address space. Operations of that scale tend to be much more challenging:

You need to be fast if you want daily results; things like your bandwidth and choice of scanning tools start becoming essential considerations.
You have to be fair with others.
You have to be as stealthy as possible if you want to avoid (too much) administrative burden, such as having to handle abuse letters.

So what do you actually need to port scan IPv4 continuously?

Port scanners that are able to scan at wirespeed such as zmap, masscan, sinn. Whereas nmap would take you months to run your scan, these tools are built to cover a lot of ground in comparatively little time.
A good pipe: if you’re sending over a million packets a second, a home connection is not going to cut it — and it’s more than likely to cause you trouble ;-)
An understanding ISP or, better still, cutting the middle man out altogether. Getting your own AS would allow you to handle abuse letters directly and avoid unscheduled network cuts.
A nice, big expanse of storage to save all the captured data (with redundancy if possible).
An indexing solution to easily retrieve interesting results and stats.
A good scheduler that is able to handle various scanners (such as the ones mentioned above) as well as the synchronization of the entire process, including but not limited to: sending packets, capturing responses, storing pcaps/data, and indexing payloads.
A good understanding of Internet routing protocol in order to implement simple tricks to avoid clogging up routers on your traffic’s path to its destination. This would include, for instance, using multiple source IPs, randomizing target ranges, etc

In order to get an idea of what a good pipe is, you must consider that there are about 3.5 billion reachable IP addresses on IPv4. The time needed to send a single TCP SYN packet to each of these addresses greatly depends on the available bandwidth, for example:

10 Mbit/s -> ~62 hours
100 Mbit/s -> ~6 hours
500 Mbit/s -> ~74 minutes
1 Gbit/s -> ~37 minutes

Consequently, speed is tightly related to how much bandwidth you are willing to dedicate to your scanning processes, as well as your tools’ ability to fill all bandwidth at your disposal. Once again, tools such as zmap, masscan, or sinn are designed with these considerations in mind.

Once you’re set up with the tools and the bandwidth, you can begin gathering data. We’ve been performing port scanning and fingerprinting on different protocols and services for a little over 6 months now. If you’ve been running an IDS, it’s more than likely that you have seen our probes go by.

You might even have contacted us through our abuse email regarding those probes. So if you are wondering what all that was for, here is some information:

The protocols we query daily:

NTP and its vulnerabilities (CVE-2001-0414, monlist, readvar, …)
Scada devices (modbus, bacnet, …)
HTTP banner grabbing

Running those scans daily does generate a lot of data — but it also represents a lot of administrative work:

Over 180 abuse letters to which we always responded personally. We also provide each complainant with an opt-out in case our probes represent an issue.
Currently 266 ranges have been added to our opt-out list (~3M IPs).
Over 60 terabytes of traffic to store (and growing …).

The most interesting statistics are actually the results of our analysis, for instance:

Almost 4 million unique NTP servers out there responding to our probes.
Over 500K misconfigured NTP servers that could be abused through the MONLIST command in order to perform massive DDoS attacks.
More than 500K NTP servers run a vulnerable version of ntpd. This represents 98% of all servers running ntpd on the Internet … Update, anyone?
Over 70K devices run the SCADA-related Bacnet protocol, of which 51% located in the US and 24% in China.
Over 400K devices running the SCADA-related Modbus protocol, of which 67% are located in the US.
30 million HTTP servers (understand unique IP), with more than 100K geo-located in Switzerland.
Of these, the ratio of HTTP server tags returned are: ~51% Apache, ~31% Akamai and ~13% Nginx.

If those numbers don’t mean much to you, here’s a simple example based on the use of those NTP servers to perform a massive DDoS.

The idea is the following:
You can send a UDP packet to a NTP server to ask for the list of the last IP addresses that have queried the NTP server (this command is called MONLIST). Therefore, by sending a small query to an NTP server, you can generate a lot of traffic in the response (the list of all IPs as well as some additional information). Moreover, because this is all over UDP, it is possible to forge the source IP address and target, by reflection, some poor user (or not so poor, who knows).

Thanks to MONLIST, with a 90-byte packets you can reflect a much larger load onto the target (who will receive the actual response that was asked for) and thus create a DDoS-conditions on the victim’s end.

Let’s consider an attacker with questionable intentions and a rented botnet of a hundred hosts to DDoS a specific target. All that person needs to do is identify a few vulnerable NTP servers to use for the attack. Most of the vulnerable NTP servers we identified have a high amplification factor — that’s the ratio between the query and the reflected response.

We found there are approximately 120K NTP servers with an amplification factor of 194. Therefore there are more than enough out there for such an attack.

A single machine from the botnet querying a vulnerable NTP server with a packet of 90 Bytes, one per second, will generate a traffic of 90 Bytes * 194 per second (=~ 17 KBytes/s = 136 Kbit/s) on the victim. If that bad guy then uses the entire botnet and starts sending packets at a comfortable rate of 1500 per second (~1Mbit/s) instead of 1 packet per second, the resulting traffic on the victim’s side would be 90 * 194 * 100 * 1500 =~ 2.4 GBytes/s =~ 19 Gbit/s.

Given that you can rent a botnet for a couple of dollars per hour and that a 1 Mbit/s upload bandwidth is fairly common, is it starting to sound scary now ?

It’s not all doom and gloom, though. There are solutions to fight such attacks; look at this blogpost.

Have fun and stay out of the DDoS blast !

Links:

Share:

Related