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.
If you have any comments, additional examples of safeguards, or additional information please let us know here. Cheers,
|
Adrien de Beaupre 353 Posts ISC Handler Jun 18th 2010 |
Thread locked Subscribe |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
Changing your listening ssh port to something non-standard almost eliminates this.
|
James 35 Posts |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 18th 2010 1 decade ago |
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 |
Quote |
Jun 19th 2010 1 decade ago |
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 |
Quote |
Jun 20th 2010 1 decade ago |
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 |
Quote |
Jun 21st 2010 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!