Track a hack: Find out who’s hitting your servers

If you’ve run a publicly visible server with open SSH access and looked through your auth logs once in a while, you’ll have noted a large number of seemingly random login attempts. Unless you restrict SSH access to a list of specific source IP addresses, anyone on the Internet can attempt to log into the box, and large numbers of individuals running scripts will do just that. For the most part, smart security will reduce this threat to nothing more than a nuisance, but it’s still relatively interesting to see what’s going on with those attempts.

A few weeks ago, I began parsing the logs created by denyhosts, a *nix utility that watches for invalid login attempts and shuts off access to source IP addresses that fail to successfully log in after a configurable number of chances. It’s a fantastic utility that will decrease the noise your server sees on an ongoing basis. If you haven’t already set up denyhosts on your visible servers, you should do that right now, then come back and read the rest of this — or read on to understand why you should.

I began gathering and parsing the denyhosts data in a semi-scientific manner. I was watching hosts in the United States and Europe that were running on six different network providers and cataloging every IP that attempted access. Denyhosts would shut down an IP after 10 failed attempts on the same login, or across multiple logins, thus limiting the data I collected to IP addresses ostensibly trying to break in. The results are not really up to snuff for what I would consider an exhaustive research project, but for our purposes, they’re interesting enough.

Two of the hosts that were monitored were on the same public IP subnet. One of those boxes hosts a sizable number of domains and websites, hosts email for a slightly smaller number of domains, and is a registered DNS server. The other box does nearly nothing, but acts as a firewall and runs a few small services. You might think the busy server would see a higher number of login attempts than the other because it has a much larger presence, in terms of the services it exposes. I mean, attacking Web servers is about as old as Web servers themselves.

The results were the exact opposite. Within a one-week period, the busy server blocked 47 IP addresses, while the quiet box blocked 86, nearly twice as many. I can only guess that because the quiet box is acting as a firewall and gateway, its IP address was seen by a large number of websites and servers across the Internet, and this caused it to be added to pingback lists for further perusal. Rather than Web servers, the focus was on what appeared to be an edge gateway. I suppose that makes some sense — if you can break into the gateway, there may be much more behind it than a Web server.

But perhaps not. The boxes at hosting providers registered the most attempts of all, with each system showing an oddly similar number (between 115 and 121) of unique attempts. These were all servers running in colocation facilities around the world, with different hosting providers, on completely different subnets, with no relation to each other whatsoever. Those netblocks are widely known to be assigned to hosting providers, so these attempts were clearly aimed at servers, not gateways.

As you might imagine, these requests came from all over the world, from Ankara to Melbourne, from the Ukraine to Sarasota and back again. The attempts to access these systems involved a vast range of usernames, from your usual “root,” “apache,” and “bin” to “virus,” “mom,” and “herschel.” (My favorite might be “giblets.” What are the odds of hitting a bull’s-eye with that username?) Most boxes showed upward of 600 unique attempted usernames. Some of the denied callers would go for seemingly random usernames, or even strings of characters, while others were clearly walking a dictionary, starting with “a” and getting only as far as “aaad” or the like before they were blocked.

The nature of this laissez-faire experiment was such that I was using production servers that were being protected from these types of attacks. If I had the time and inclination, firing up a few dozen VPSes around the world and letting them run for a while would bring in better and more complete data.

The fact of the matter is that there is a constant stream of scripts knocking on the door of SSH ports all over the globe, trying to overcome impossible odds and guess the login to a server. Many of these scripts are geared toward exploiting known holes in Linux-based appliances that are set to their defaults and thus are using known logins. Others are looking for security holes caused by software installations that create users with valid shells and default passwords.

But that’s certainly not all they’re looking for. The panoply of attempts I’ve perused over the past week show a wildly schizophrenic threat, the computing equivalent of trying to unlock a door by throwing a box full of keys at it. But once in a while, one of those scripts will work, and suddenly that threat is very real indeed.

Oh, one last thing: Across two continents, three countries, and six network providers, there was one IP address in common to them all. As far flung physically and logically as these systems were, one single, solitary IP address tried to access every single one. That IP address is located in Ningbo, China.

Who’s knocking on your door? There’s your answer.

This story, “Track a hack: Find out who’s hitting your servers,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.