may the force be with you

It is also possible that these attacks have been going on longer then just the past few months, as it was noted on the SANS mailing list that at least one individual has seen attempts using a “guest/guest” login/password combinations about a year before these new ones. It is quite obvious that this is the work of an automated program as the user names used are attempted in alphabetical order. The time-stamps are also a dead give away, with connections only a few seconds apart.

Here is an example from my /var/log/auth.log

Jul 14 02:12:19 rage sshd[47297]: Illegal user admin from 203.197.118.71
Jul 14 02:12:25 rage sshd[47299]: Illegal user test from 203.197.118.71
Jul 14 02:12:30 rage sshd[47301]: Illegal user guest from 203.197.118.71
Jul 14 02:12:37 rage sshd[47303]: Illegal user webmaster from 203.197.118.71
Jul 14 02:12:41 rage sshd[47305]: Illegal user mysql from 203.197.118.71
Jul 14 02:12:45 rage sshd[47307]: Illegal user oracle from 203.197.118.71
Jul 14 02:12:50 rage sshd[47309]: Illegal user library from 203.197.118.71
Jul 14 02:12:54 rage sshd[47311]: Illegal user info from 203.197.118.71
Jul 14 02:12:59 rage sshd[47313]: Illegal user shell from 203.197.118.71
Jul 14 02:13:03 rage sshd[47315]: Illegal user linux from 203.197.118.71
Jul 14 02:13:07 rage sshd[47317]: Illegal user unix from 203.197.118.71
Jul 14 02:13:12 rage sshd[47319]: Illegal user webadmin from 203.197.118.71
Jul 14 02:13:16 rage sshd[47321]: Illegal user ftp from 203.197.118.71
Jul 14 02:13:23 rage sshd[47323]: Illegal user test from 203.197.118.71

As you can see in the above example, login attempts were only a few seconds apart indicating the use of a script. It is also obvious that they are using well known account names which could quite possibly could be used in a corporate environment where they might have setup the web development team with the user name “webadmin”. It was also speculated on the SANS mailing list that password lists were circulating around with 3,400 to 22,000 passwords listed. It is very easy to come across these types of lists on the web, more reason for administrators to practice safe password use.

A dangerous addition to these attacks is the attempts to break into “root” accounts. I will discuss later on how you can prevent the root account being compromised over SSH, but it is worth noting that, even though you can disable the root account, the attackers still try. More proof that we're dealing with an automated “script kiddie” type of program.

Here is another example from /var/log/auth.log:

Jul 14 02:13:51 rage sshd[47335]: Failed password for root from 203.197.118.71 port 33396 ssh2
Jul 14 02:13:55 rage sshd[47337]: Failed password for root from 203.197.118.71 port 33443 ssh2
Jul 14 02:13:59 rage sshd[47339]: Failed password for root from 203.197.118.71 port 33490 ssh2
Jul 14 02:14:06 rage sshd[47341]: Failed password for root from 203.197.118.71 port 33541 ssh2
Jul 14 02:14:11 rage sshd[47343]: Failed password for root from 203.197.118.71 port 33632 ssh2
Jul 14 02:14:16 rage sshd[47345]: Failed password for root from 203.197.118.71 port 33686 ssh2
Jul 14 02:14:22 rage sshd[47347]: Failed password for root from 203.197.118.71 port 33739 ssh2

Another thing to notice is the “Failed password” column, in the previous example it was reported as “Illegal user”. The difference being that for “Failed password”, your system actually has that user account to be compromised. If that particular user had a weak password, it wouldn't take long for a dictionary attack to find it. The indication that the user name actually exists or not isn't shown to the attacker.

How to know if you're being attacked and possible locations of the attackers

Finding where these attacker are coming from might be a daunting task, getting the IP address of the connecting computers is easy, but if that is where the attacker actually is might be a different story. Recently I started running p0f on my system. This gave me an indication on what types of systems, how many hops, and the connection type of the attackers. Since p0f is passive the attackers had no knowledge they were being monitored.

Sample output from p0f:

As with this sample, the rest of my logs show that its mostly Linux based systems that are compromised. P0f works perfect in this situation since you know that the attackers are going to connect, it just sits and waits. It also gives us one very important piece of information, the IP address of the attacker.

With the address of the attacker it is possible to find out who owns it and to report the abuse. It was a part of a few discussions on the SANS mailing list that it is the right of administrators to report these abuses.

With ARIN which most administrators known about, you can look up the information on a single IP address. It reports back with information on the owner including (most times) contact information to report abuse. For example I did a look up on “67.110.118.138” which, ARIN gladly tells us, is registered to XO Communications in Reston, VA USA. We can see that they own the “67.104.0.0” to “67.111.255.255” network block. The most important thing that they provide is an email address and a phone number for reporting abuse.

If you are working in a corporate environment, and you are experiencing unknown attackers attempting to break into your system, it should be your duty to report these attacks to their respective net block owners, if enough people reported them, eventually they would stop.

Although this type of attack isn't aggressive, it is one of those attacks that, if you don't have strong passwords or change them frequently, will eventually work. Password security is a must, but it is up to the administrators to enforce it.

There is of course a few things you can do, the most important being disabling root logins over SSH. Adding “PermitRootLogin no” to your sshd_config file will disable the root account from being logged into remotely. If you need to be able to work as root on the same system, the best solution is log into a normal user account and then from there to use “sudo” or even “su – root”.

As well as logging from traffic capture programs such as p0f, your system also logs automatically. Under FreeBSD, and most likely Linux, SSH logs invalid and failed logins to “/var/log/auth.log” or “/var/log/messages”. Watching this file closely allows the administrator to actually see which user names are being tried by the attackers. If you happen to see a known user name, you know its time to do an audit.

Another interesting program you can use is called Tattle, which was created by C.J. Steele from discussions on the SANS mailing list. Tattle is a perl script that looks through your log files and automatically notifies domain authorities of systems performing SSH dictionary attacks. This is exceptionally handy if you administer a few different systems that offer SSH.
Marcus J. Ranum also has an interesting tool called “Never Before Seen” that is a “Anomaly detection driver”. It could easily be used to watch log files and report on SSH attempts that are usually not suppose to be connecting.

As a last step measure you could always reconfigure the port that the SSH daemon listens on. By changing the “Port” setting in your “sshd_config” file, you can easily fool the attackers into thinking you're not running SSH at all, but it's no guarantee that they won't find you again by doing a simple port scan. Changing the port is definitely no solution to strong passwords.

It would seem that these dictionary style attacks are by no means new, but they do offer a slight annoyance with the potential to cause harm. They have become common place as seeing Code Red worm attempts in your web server logs. Your best weapon against these attacks is to monitor, be diligent in your reporting to the proper authorities and always enforce a strong password policy.

SANS Mailing Lists- http://lists.sans.org/
ARIN - http://www.arin.net/
Tattle - http://sodaphish.com/files/tattle
Never Before Seen - http://www.ranum.com/security/computer_security/code/
p0f - http://lcamtuf.coredump.cx/p0f.shtml

source: http://www.whitedust.net/article/27/Recent%20SSH%20Brute-Force%20Attacks/