Increase in SSH Brute Force Username Guessing

Wednesday, March 23, 2011

Ted LeRoy


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         3171             South Korea              641               Indonesia               565                 China           461              Germany           138                Brazil         121                Peru         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:
Network Access Control
Passwords Access Control SSH Attacks Brute Force username
Post Rating I Like this!
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.
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.
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!
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.
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 ??
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.
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.
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.
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.
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.
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.
Ben Keeley Why not use Fail2Ban and key based authentication for SSH?
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.
Tom Coats Great tips and warnings.
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.
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.