When botnets try to break in, do you know which doors should be locked?

Closing the most common holes will deter most automated attempts

Last week, while upgrading the openssh version on his employer's web servers, Michiel Vancoillie noticed that malware-infected, hacker-controlled bots had tried to log in to his servers more than 20,000 times during one two-day period.

That's huge for a tiny web design place like NinetyNine, Whose greatest claim to fame is a free app free search tool designed to search and manage ASDoc files generated by Adobe's Flex web application development toolset.

There are plenty of botnets and plenty of malware, not all of which are designed for on-by-one server penetrations this one was apparently trying to accomplish. Most botnet operations are much larger-scale, especially internationally.

The specific techniques and weak spots this attempt probed are interesting, though.

Looking at the server logs, Vancoilliehe looked at the login attempts, though, he discovered two interesting things: first, the vast bulk of login attempts were made with invalid user names – flat guesses by attacking bots about what might or might not be a valid login.

The invalid usernames were repetitive, and kind of doofy, too: minecraft, eggbreaker2 ,batman ,sir , queen, elmo, frenzy, christmas, idiot, birdseed, einstein123, breast, knight, cookie, eminem.

Second, most of the attempts made with valid names didn't use actual names; they aimed at services that might run on a the server the bots were attacking and, if they were, might have default access rights that used the names of the apps for authentication: Root, postgres, ftp, bin, mysql, proxy,uucp, mail, news postfix, daemon, backup, nobody, IP, list, gnats, man, irc, sys, games.

Sounds silly, but a lot of apps actually do come with default settings for usernames and security that are simple enough for brand new users to remember. The defaults are passed out in documentation and supplied on support forums.

It's not hard for malware writers to get ahold of and paste them into a list of possible ID/password combinations to be used against the target machine.

By far the most common term used was Root, which made up 18.8 percent of all attempts, and more than 80 percent of attempts using valid names.

The very distant No. 2 choice was Postgres, with about 17 percent of the existing names segment.

Bots used invalid names (random guesses) 77 percent of the time, but stuck with the practice of going for names that reflected generic functions as often as possible.

Repetition was much lower, though. The most common invalid name was Oracle, at five percent.

Botnet password cracking strategy

Using those patterns, it looks as if the Botmaster's tactic was to take a few passwords that are commonly built in to the OS or applications, and hammer them with a lot of attempts using different passwords.

Since invalid names came with a much higher likelihood of failure, the Botmaster decreed bots should tried the common ones a few times, but spread out to as many usernames and passwords as possible.

Some of the most common invalid names:

























The type and distribution of names (and failure to get into the server) either demonstrated or proved security processes for an SSH server, according to Vancoillie:

1. Lock up your root

Root is the go-to username or password. It was used in 18.8 percent of all attempts, 80 percent of those using existing users.

Solution: Disable root login. "You can disable root login by opening sshd_config and changing the 'PermitRootLogin' setting to 'no.'" Vancoillie wrote.

Then restart the SSH daemon and don't forget the admin password. You'll never get back in.

FTP is also a common service and target. Vancoillie has FTP turned off because NinetyNine uses Secure FTP (SFTP) instead.

2. Set up a chroot jail

In Unix systems, the "chroot" command changes the apparent root operating system – so after logging in you appear to be working from drive "X:" rather than "C:" for example. Most Unix virgins will run into this most frequently when booting from a Windows system disk in order to rebuild a Windows installation.

You can also use it to set up a "chroot jail," that will let attackers log in, but keep them locked in a harmless and quarantined section of the site. Vancoillie puts his at /etc/ssh/sshd_config; instructions for setting up and useng it are under Modify SSHD_config on this blog page.

A more detailed explanation of how to set up a chroot jail is here.

These tips only apply to Unix servers, of course, and to relatively lightweight, generic automated attacks, not those modified for a particular site, or those for which more than a few zombie PCs have been arrayed to keep probing until they find a weakness.

Windows or other servers have similar functions for root access and the potential to set up a honeypot directory that quarantine attackers who do penetrate.

Vancoillie's example does give a better idea of how some botnets prob for potential targets, looking for easy openings and then moving on if they don't find them.

These precautions are very basic – like locking the door before you leave the house.

Cops will give you the same advice if your house is ever robbed; your security doesn't have to be so tight no thief can ever get in, it only has to be tough enough to give them a little more incentive to try the neighbor's place rather than yours.

Read more of Kevin Fogarty's CoreIT blog and follow the latest IT news at ITworld. Follow Kevin on Twitter at @KevinFogarty. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon