Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC: Distributed SSH Brute Force Attempts on the rise again - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Distributed SSH Brute Force Attempts on the rise again

SSH brute force attempts seem to be on the rise again, at the SANS Internet Storm Center we have received a number of reports that a number of networks are seeing them. The source IP addresses vary with each new attempted username in the wordlist, which would indicate that the attempts are distributed through botnet(s). It only takes a single user with a weak password for a breach to occur, then with that foothold escalation and further attacks are likely next. This is certainly not a new phenomenon, however I think it is a good time to raise awareness about it once again.

Reader xemaps wrote in with this log snippet:

"Whole day my server has been targeted by a botnet, attacker also changed ip each new dictionary user."

Jun 17 23:02:03 pro sshd[17444]: Invalid user mailer from 217.37.x.x
Jun 17 23:03:24 pro sshd[17460]: Invalid user mailer from 87.66.x.x
Jun 17 23:05:27 pro sshd[17617]: Invalid user mailman from 89.97.x.x
Jun 17 23:09:30 pro sshd[17639]: Invalid user mailtest from 62.2.x.x
Jun 17 23:15:44 pro sshd[17894]: Invalid user maker from 83.236.x.x
Jun 17 23:16:47 pro sshd[17925]: Invalid user mama from 84.73.x.x

Reader Ingvar wrote in with a similar pattern:

"On my home system I have seen these login attempts that start with user "aaa" and goes on alphabetically from over 1000 different hosts around the world (judging from the DenyHosts reports). Normally I only see single-digit attempts per day."

Jun 17 02:14:56 MyHost sshd[808]: error: PAM: authentication error for illegal user aaa from 151.100.x.x
Jun 17 02:23:11 MyHost sshd[870]: error: PAM: authentication error for illegal user aabakken from 150.254.x.x
Jun 17 02:24:57 MyHost sshd[875]: error: PAM: authentication error for illegal user aapo from 173.33.x.x
Jun 17 02:35:23 MyHost sshd[885]: error: PAM: authentication error for illegal user abakus from 121.160.x.x
Jun 17 02:37:32 MyHost sshd[895]: error: PAM: authentication error for illegal user abas from 190.200.x.x
Jun 17 02:38:18 MyHost sshd[900]: error: PAM: authentication error for illegal user abc from 193.251.x.x

Last year ISC Handler Rick wrote up a diary for Cyber Security Awareness Month - Day 17 - Port 22/SSH about SSH brute force attempts and some safeguards that can be implemented. Here is a brief summary:

  • Deploy the SSH server on a port other than 22/TCP
  • Deploy one of the SSH brute force prevention tools
  • Disallow remote root logins
  • Set PasswordAuthentication to "no" and use keys
  • If you must use passwords, ensure that they are all complex
  • Use AllowGroups to limit access to a specific group of users
  • Use as a chroot jail for SSH if possible
  • Limit the IP ranges that can connect to SSH

If you have any comments, additional examples of safeguards, or additional information please let us know here.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.










 

Adrien de Beaupre

353 Posts
ISC Handler
I think its best to launch automated countermeasures triggered by monitoring SYN packets on port 22. Set a threshold at let's say 120 packets in 60 seconds (or whatever you think is the lower end of unreasonable). That way it doesn't matter if its an SSH scan, or an SSH bruteforce attack. There might be many sources and a single destination, or a single source and many destinations. It doesn't matter. You want to stop both the recon (scanning) and the attack (bruteforcing) right?
nate

1 Posts
nate: if you mean closing your SSH port to anyone (perhaps including yourself) in the face of aggressive scanning/bruteforcing, that is not going to be appropriate in many situations. If you're really that fortunate, then you may as well shut down the service completely, or disable plaintext authentication and require client keys instead.

The nice thing about this attack though, is that it should be easy to compile a comprehensive list of infected hosts and go about getting people to fix them.
Steven C.

171 Posts
That's what I was thinking. Is there a place we can submit the hundreds of ip addresses we have? Or would just need to contact all of them ourselves?
Steven C.
1 Posts
Changing your listening ssh port to something non-standard almost eliminates this.
James

34 Posts
using a non-offical port for ssh (or any other registered service), is just a hack. security by obscurity, etc.

the real solution is to get people to fix their broken security, which led to the attempts in the first place.
Anonymous
joeblow: When you consider defense in depth, your goal is to implement multiple measures that, working together, protect your system/environment.

While changing your port should not be the only step taken to protect your systems, it does reduce your surface area by eliminating the potential of most of the automated scripts. Why would you not want to reduce your surface area if it's as trivial as using a different port (depending on your situation)?

I would also be surprised that the writers of PCI would recommend such a "hack" if it was indeed so.

Also, the "real solution" that you propose is generally outside of your control, while the configuration of your systems is well within your control. What you're proposing is akin to saying "We should not have a police force because the real solution is to get everyone to just follow the law."
Anonymous
so sending off a few thousand abuse@ emails is unacceptable? really? regardless of who has the control, the more respectable ISP's will disconnect botnetted hosts.
Anonymous
Seeing a lot of this against our SFTP server. Are the bots just looking for shells or are they smart enough to see a Windows SFTP server when they actually achieve a login? Implementing keys for logins will be the next step and is as close to a solution as is reasonably achievable in a business environment.
jtwaldo

17 Posts
If you're running SSH on a non-standard port, and being attacked, then it is a much more serious threat. It means you're obviously being targeted because someone took the time to do some reconnaissance.
Thus running SSH on a non-standard port is much more than just "security through obscurity," it's one more layer that can give you the edge on an attacker.
jtanium

3 Posts
To jtanium's point, I have some preliminary data that supports that: http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk
Daniel M.

4 Posts
It's not enough to
* Set PasswordAuthentication to "no" and use keys

If you use PAM, don't forget to
* Set UsePAM no
Nerijus

7 Posts
One of these has been hitting me. I've got a patched sshd with extra logging, and I'm seeing stuff like this:

2010-06-20_23:09:23.63890 SSH: Server;Ltype: Version;Remote: 116.228.139.242-43976;Protocol: 2.0;Client: libssh-0.4.3
2010-06-20_23:09:23.86726 SSH: Server;Ltype: Kex;Remote: 116.228.139.242-43976;Enc: aes256-cbc;MAC: hmac-sha1;Comp: none
2010-06-20_23:09:24.86417 SSH: Server;Ltype: Authname;Remote: 116.228.139.242-43976;Name: homepage
2010-06-20_23:09:24.86546 Invalid user homepage from 116.228.139.242
2010-06-20_23:09:24.86562 input_userauth_request: invalid user homepage
2010-06-20_23:09:24.86796 Postponed keyboard-interactive for invalid user homepage from 116.228.139.242 port 43976 ssh2
2010-06-20_23:09:25.08751 Postponed keyboard-interactive/pam for invalid user homepage from 116.228.139.242 port 43976 ssh2
2010-06-20_23:09:27.72068 PAM: Permission denied for illegal user homepage from 116.228.139.242
2010-06-20_23:09:27.72084 Failed keyboard-interactive/pam for invalid user homepage from 116.228.139.242 port 43976 ssh2
2010-06-20_23:09:27.94102 Connection closed by 116.228.139.242
Nerijus
1 Posts
But this also complicates end user access to resources by moving to non-standard ports. Depending on the software it is a challenge to both unskilled and skilled computer users to know that one site is using port 28 and another using 293 for SSH, etc. Help desk calls and general quality of use experience needs to be a part of your decision matrix or you may more than irritate people who you report to.

This isn't to say you should never do this but the big picture can't be overlooked just for the security benefit. As noted above if someone wants to target you they will figure out the port you are using without too much effort. This only stops the worms and similar automated mass attacks that aren't directed specifically at you. Worthwhile but not the only decision factor.
BGC

23 Posts

Sign Up for Free or Log In to start participating in the conversation!