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.

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:

Oracle

A

Test

Admin

Guest

TS

Teamspeak2

Teamspeak

T2s3

Teamspeak3,

minecraft,

TS2, CS

User

CSS

Nagios

Webmaster

Apache

Student

Robert

Alex

TMP

Info

Mailtest

Administrator

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.

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.

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.