SANS ISC: SSH Server "Time to Live"? Less than a cup of coffee! - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

I'm assuming that since you suggest putting it behind a VPN that you believe key-authentication to be also unsafe? Could you elaborate?

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?

This is why tools like bfd, fail2ban, Denyhosts, etc. are all very useful. Immediately cuts off brute-force attempts. If you have a lot of services that are internet-facing, some kind of network appliance would be far better of course.

Sorry, I couldn't agree less. A VPN is nothing more secure than SSH is.

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.

I use fail2ban tightened up ( 1 password fail gets your IP a 120 minute ban ). Cuts down the automatic attacks well enough to be useful for me.

While I certainly agree that restricting any administrative access to systems to behind a VPN is best, I'd like to see this post updated to account for the use of public-key authentication / SSH keys, and/or multi-factor authentication. (I typically avoid fail2ban and similar solutions, due to the denial-of-service potential.) Consider that SSH can be used AS an effective VPN solution - especially with public-key authentication and MFA in-place.

Great feedback, thanks everyone!

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!

I'd be interested in thoughts regarding sFTP. Our EDI software uses sFTP (also 22/tcp) with username/passwords. Trading partners likely would have difficulty using VPN and/or MFA. Our software disconnects after x failed attempts and automatically bans when certain usernames are attempted. The logs seem to indicate that it has been fairly effective. However, I'd like to hear what other EDI shops do.

Usually sFTP (FTP over SSH) can be at least connected to using a standard SSH client, so I'd suspect that your server is seeing the same sort of continuous attack traffic that any other SSH server might see. With a trusted partner often you can restrict access to an sFTP host to their fixed IPs - is that an option for you?

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).

Time to live usually refers to first compromise, not the first packet sent your way.

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.

You can dramatically decrease the number of failed authentication attempts if you use "security by obscurity"- choose another port for SSH. 99,9% of those bots only use the traditonal ports for telnet and SSH. Configuring SSH to use port 55 (for example) and a ban of 120 minutes after the 3rd failed authentication attempt leads to 15 - 20 entries *per year* in my OSSEC logs.

Rather than fail2ban I use a nice failsafe trick built into iptables.

$IPT -t filter -A IN_public_deny -p tcp --dport ssh --syn -m recent --name ssh_attack --rcheck --seconds 90 --hitcount 1 -j REJECT --reject-with tcp-reset

the important part is "--syn -m recent --rcheck --seconds 90 --hitcount 1". That part means I get one chance every 90 seconds or so to establish a connection. Success or fail I must wait 90 more seconds to connect again to the port in question.

History seems to indicate that they give up pretty quickly to go after lower lying fruit. It's annoying but also amusing to see in the logs that some idiot automatically tried 1000 more times in very rapid succession after his first attempt failed the password. To protect against that no great big deal of a password is needed to prevent it being cracked - as long as it's something not on the password list. "Fisbang3" would probably take centuries to crack at a wild guess with only one try every 90 seconds. I first used this concept with ipchains a long time ago, in computer years. (Sadly, it seems like yesterday in my years. Don't get old.)

{^_^}

Is port knocking no longer viable?