Increase in SSH Brute Force Username Guessing

Wednesday, March 23, 2011

Ted LeRoy

E4b33dbe234685965beb3e9f2a0ad456

Check your log files folks.  I've noticed an increase in the number of automated attacks against SSH lately.

Below are some recent stats from a server with port 22 open. The data on this particular server was in /var/log/auth.log (Table 1). 

It may be in another location such as /var/log/secure, or better yet on your syslog server, depending on your configuration. 

These stats were accumulated between 21 and 23 March, 2011:

(Table 1)

     IP                  # of attempts       Origin

114.70.60.247         3171             South Korea

118.97.8.28              641               Indonesia

113.5.32.68               565                 China

84.16.224.166           461              Germany

200.149.25.74           138                Brazil

200.62.142.142         121                Peru

83.222.168.165         117              Bulgaria

Total Attemps: 5214  

The crackers are using automated tools that scan for valid ssh logins using a username list. 

The tools scan a range of IP's using the login name and record names that are prompted for login credentials. 

The sites and names that come up on the list can be processed again, checking for weak passwords, or password brute force vulnerabilities.

The tools and method are not new, but the number of attacks seems much higher lately.

Usernames seen scanned for include common names such as root, web, and guest, but also guesses at real users like claudia and craig.

To see if any of the usernames you have configured may have been guessed, search for the names in the appropriate log file. 

For example, sudo cat /var/log/auth.log | grep "Invalid user guest" replacing guest with the username you're concerned about, and editing the path to your log files.

Some protection from such attacks include disabling root login via ssh, using public/private key pairs for login instead of relying on passwords, and setting a maximum authentication tries threshold to thwart brute force password attacks.

Although it doesn't protect against this particular attack, it is also good practice to keep your system, including your ssh daemon up to date, and to only allow SSH version 2 connections.

How you go about setting these protections will vary depending on the flavor of Linux or BSD you are running.

Safe computing!

Ted LeRoy

Possibly Related Articles:
18771
Network Access Control
Passwords Access Control SSH Attacks Brute Force username
Post Rating I Like this!
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson What varieties of SSH server are vulnerable to this? OpenSSH on any box I've ever used prompts you for a password regardless of what username you use. I always thought that was part of the standard.
1300908313
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy Hi Rod,
Yes, SSH will prompt for a password.

This isn't a vulnerability in SSH, it's an attempt at enumerating valid logins and searching for weak passwords.
1300910565
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy Hi Rod,

Yes, it looks like no matter what username is input, I'm prompted for a password. The tools must be trying username/password pairs and reporting successful logins for further exploit.
Thanks for pointing that out!
1300916106
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson If you are seeing a different name each time rather than the same name several times in succession with a different password, they are probably just trying to avoid the 3 tries your out lock outs by hitting multiple names with the same password, then when they've exhausted the username list start over with the next password.
Most systems track the same user trying and failing over and over and will lock that user out, far fewer systems watch for same IP trying many user names.
1300917125
73d0e1095870b725152f48157d253034
Keith Glass The key to beating this attack, is rate-limiting at the firewall, and customizing your SSH error messages to deliver minimal information, i.e. respond to a bad username OR password with "Invalid Username and/or Password". Why make enumeration easy ??
1300921780
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson Keith,

Agreed 100%, but again, I don't think I've ever seen that problem with an SSH server. Lots of other logins (especially on the web where being "helpful" to the user seems to take precedence over making sure the user is the person who is actually authorized to log in.
1300936972
1de705dde1cf97450678321cd77853d9
Ian Tibble My own personal experience with my Linux VPS is that there are literally hundreds of brute force attempts being made on my SSH every week, using the same combinations of password attempts - it looks a standard list included with a vulnerability scanner like Nessus. Most likely the sources are BOTs.
If you disabled direct root login and use reasonably strong passwords you're ok. Can you use your firewall / iptables? Depends on the situation. Personally i do not because my source IP address changes a lot (i need to access SSH from various different locations). I only blocked out SSH with iptables when i was setting the VPS up, because the brute force attempts were filling my /var/log/auth.log and making it hard to trouble-shoot other issues!!
Some I know don't use passwords at all, they configured public/private key encryption for access to SSH. Just depends what you're trying to protect really.
1300960414
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy I'm glad the topic is generating so much discussion. Thanks guys. I see "Invalid username ..." in the log files. From the ourside there may be no difference though whether using an invalid login or valid login with a bad password. It could still be useful to know if any valid usernames were attempted.
1300968164
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson Ted, try it yourself, enter a valid username and purposely get the password wrong, see what it logs it as.
My system logs it as "Failed password for rod" when that happens.

When I log in with bad credentials (either username or password) the error message displayed within the SSH session is simply "Permission denied, please try again."
Having looked at that I think it's probably a good idea to customize that to remove the invitation to try again, but it doesn't give the user any idea which half they got wrong.
1300969235
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy I agree Rod,
I'm not sure the behavior isn't different on different systems though. I'll do some experimenting.
One additional mitigating technique I forgot to mention is enforcing password security for user accounts. This helps avoid trivial passwords.
1300971552
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy Ian, iptables was not running on this particular server. It is behind a stateful firewall, but iptables is a good idea as well.
I believe it iptables can be set up to deny traffic after a certain number of invalid packets are received from a particular address. Not sure this could be tied into SSH though.
1300972014
0b8d1c9dc5f4a80e6646d8d18b8683fe
Ben Keeley Why not use Fail2Ban and key based authentication for SSH?

http://felipeferreira.net/?p=47

https://help.ubuntu.com/community/SSH/OpenSSH/Keys
1300986020
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy Ben,
That's a great solution. For people that don't have that yet though, it's good to keep an eye on log files.
1300997411
591052017c12c3277d83b0b437c13302
Tom Coats Great tips and warnings.
1301058447
E4b33dbe234685965beb3e9f2a0ad456
Ted LeRoy Thanks for the comments folks.
I've done some experimenting, and have found the following:
SSH login seems quite secure in that it does not reveal whether a login problem lies with the username or password. Even if an invalid username is entered, SSH prompts for a password until the max session retries is reached.
Telnet on some devices (older Cisco IOS for example) will state "%Login invalid" if an incorrect username is entered allowing brute force name guessing.
Obviously, SSH is the secure protocol, and it should be used wherever possible. If Telnet must be used, it should be restricted by firewall rules or Access Control Lists so only certain trusted hosts can connect.
1303306693
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.