Sometimes it is interesting to take a look at darknet data and see what you come across.
A darknet, in this case, is a set of address space that contains no real hosts. That means no client workstations to initiate conversations with servers on theiInternet, and no advertised services from those ranges, such as a web, DNS, or database server.
You shouldn't see traffic to addresses within those ranges. It should be as desolate and deserted as Chernobyl.
In practice, however, you will see traffic. It could be the result of malware attempting to find machines to infect, or probes as part of a research project, or maybe just a misconfiguration or an adrress typo.
But most darknet traffic is rarely the result of a mistake.
For three weeks last month we examined Netflow traffic data for a few of our darknets destined to a nearby Cisco router.
Sixty found per cent of traffic flows probed for hosts on TCP port 445, commonly used for SMB file sharing over TCP.
The next highest percentage of traffic was for port 1433, the default for Microsoft SQL Server, which only accounted for 3.09% of the traffic flows.
Looking at that data, you'd think that securing traffic to port 445 may be a very good idea based solely on the volume of traffic into the darknet. But what about the other traffic?
In port 1433 traffic, we found sequential scans by the same host for TCP/1433. That meant sequential scans of IP addresses like x.x.x.1, then x.x.x.2, then x.x.x.3, which were re-scanned later.
Of the flows destined to TCP/1433, 94.9% had a source port of 6000. Only 57 hosts were responsible for those flows from port TCP/6000 over the three-weeks.
Out of the 1013 unique IPs our darknet ranges saw scanning for TCP/1433, 57 shared a repeated source port of TCP/6000.
Sourcing all traffic from port 6000 is not really expected behaviour, so you can assume that a common tool or malware may be on those 57 hosts.
Of the port 5060 traffic in the table above, only 0.041% of the traffic was to TCP/5060, and the rest was to UDP/5060, commonly used for the Session Initiation Protocol (SIP).
Our darknets saw 673 unique IP addresses SIP scanning, and it bore similarities to the TCP/1433 scans in that sequential scans where one IP address attempted to locate servers listening for SIP on every IP address in the range.
The SIP scans didn't use port 6000, but used other source ports, such as UDP 5060, 5061, 5062 and 36209.
Another interesting finding from the darknets was that only three of the 673 IPs were scanning for both TCP/1433 and UDP/5060. That was a curious finding.
But does it still hold true for other ports? The next one I chose to examine more closely was port TCP/22, the port commonly used for SSH sessions. Our flows to TCP/22 came from 130 unique IPs, of which we had seen flows from four of the same IP addresses to port TCP/1433 and six to port UDP/5060.
How many were shared in common between all three ports? The same three IP addresses from the previous results.
Let’s think about this a minute. One thousand one hundred and thirteen different IP addresses scanning for SQL Server, 673 addresses scanning for SIP, and 130 addresses scanning for SSH.
Out of all of those addresses, only three were scanning for all three services. The rest of them were specifically targeting certain services with their scans.
This means that if you were specifically watching for rogue SQL Server connection attempts and actively blocking those hosts based on source IP addresses, it would provide little to no protection for other services like SSH or SIP.
For each service that is exposed to the internet, you must give separate consideration to ensure that the service is adequately protected. A blacklist mechanism for one service, such as for SSH connections, may have almost no relevance or provide no protection to another service such as SIP or SQL Server.
