SSH Server "Time to Live"? Less than a cup of coffee!
After the stories I posted last week on SSH, I had some folks ask me about putting an SSH server on the public internet - apparently lots of lots of folks still think that's a safe thing to do.
Shodan lists 15 million such trusting souls:
OK - so can 15 million people be wrong? In a word, yes. I put an SSH / SCP server up for a few minutes yesterday, for a quick file transfer. For kicks, I left it up for a few minutes after I send myself the files, and had a coffee while I watched the logs. And yu-u-u-p, I had several IP's brute forcing against my SSH service within 10 minutes of the server being online.
These are all automated attack engines, but they are taking the Mirai approach of using well known / default credentials to attempt to login - exactly lke the Mirai botnet, except over SSH rather than telnet. I'll refer you again to http://www.defaultpassword.com and any number of other sites that have default credentials listed. "Common password" lists such as "the worst 500 passwords" or even comprehensive lists like the RockYou list, with transforms such as "add "99! or "!!"" to the end" are also surprisingly successful. I have to say that I got domain admin this week from some LinkedIn OSINT, an open SSH server and "456789" as a password.
Anyway, the "safe" time to live for an SSH server on the public internet really is minutes these days - in my case less than a cup of coffee. Look at your logs - the wolf has been at your door since the day you put that server online. If you are still seeing brute force attempts against your server, that's no guarantee that someone else hasn't already succeeded. Time to put your SSH server behind a VPN, preferably a VPN with multifactor authentication!
===============
Rob VandenBrink
Compugen
Comments
I've been running with PasswordAuthentication no, PermitRootLogin no for a while, including a login script that emails me as an alert. Should I assume this is no longer safe? Do you have an opinion on the Google-Authenticator 2FA integration with SSHD?
Anonymous
Nov 8th 2017
7 years ago
Anonymous
Nov 8th 2017
7 years ago
Obviously one should not allow access for "root" with "password" but disallowing password login is enough and likely more secure than most VPN servers are.
Anonymous
Nov 8th 2017
7 years ago
Anonymous
Nov 8th 2017
7 years ago
Anonymous
Nov 8th 2017
7 years ago
Yes, I would certainly say that SSH with 2FA or key based authentication is as good as a VPN (that'd be VPN with 2FA/MFA) any day. Any mainstream MFA provider does the trick, I see a lot of RSA, DUO and also yes, Google MFA solutions being used, they all work great - pick your favourite and go with it!
Anything with userid/password on the internet is definitely a target these days, but ssh and telnet are "higher on the radar" for attackers. VPN should be just as high, certainly the risks are greater, but for some reason we're not seeing that in practice. At least with my clients, I do see some brute forcing on VPN services, but it's not nearly as common as for telnet and ssh. That being said, yes, MFA, keys or certificates for VPN authentication is a must these days too. If a VPN is breached it's catastrophic, and it's only a matter of time before folks put successful VPN credentials up for sake as "marketplace" items (more than they are now that is). MFA or keys or certificates are the main protections there - I'd suggest MFA does the best job because (if done right), the person who just stole the corporate laptop doesn't get the MFA along with it.
All that being said, having one VPN service with 2FA / MFA is less of a target than a collection of SSH servers with 2FA / MFA or key based authentication. Especially if those servers are maintained by different people with different skill levels, it's likely that at some point, one of those SSH servers will (by error or an uninformed configuration) become a userid/password authentication host.
On fail2ban, yes, that traditionally filters out the attackers who only have a host or two doing their work for them. However, these days we have attackers with dozens or hundreds of bots involved in the attack. My screenshot didn't show it, but the attack I saw was up to 10 hosts (and rising) within a few minutes, and that was most certainly automated rather than targeted. So at that point you really need to look at keys or a VPN - someone who's determined enough will eventually get past fail2ban and similar tools.
For more on SSH, go back to the 3 stories on this that we posted last week? Some of this info is covered there as well.
Again, thanks for the comments and suggestions, keep them coming!
Anonymous
Nov 8th 2017
7 years ago
Anonymous
Nov 8th 2017
7 years ago
FTPs (FTP + TLS) is also an option, but often that's more trouble than it's worth. Unless you can make sure it's running PASV only, firewalls won't catch the port and direction change unless the certificate is installed on the firewall. And if it's configured for userid/password authentication, the root problem doesn't go away - you're still susceptible to brute force credential attacks.
Another option would be to use a "secure send" platform, maybe something that you can send a partner a "time bomb" https link via email, which lets them pull one file with a passphrase? We see lots of solutions like this being deployed these days for insurance and banking organizations, for one-time access to forms that need a signature for instance.
No matter the platform, of course also be sure to both update and pentest that platform regularly - even for the last option, for all things are "time-bombed" for the user, often the content doesn't actually get deleted (or doesn't get deleted securely). And of course on all platforms an authentication bypass or other security issue will often leave all the content breached or exposed (which usually comes to the same thing), so you'll want to follow vendor security announcements and patches (and industry news if your vendor isn't great about patching).
Anonymous
Nov 8th 2017
7 years ago
One point with VPNs, which is often overlooked, is that usually they are bi-directional. You could make connections through it in both ways. This is sometimes not wanted. Do you know how your VPN endpoint is protected? Often not.
Anonymous
Nov 8th 2017
7 years ago
Anonymous
Nov 8th 2017
7 years ago