Blocking SSH to Limit Security Exposures

Published: 2013-01-26
Last Updated: 2013-01-27 00:51:59 UTC
by Scott Fendley (Version: 1)
3 comment(s)

If you look over the ISC diaries from the past few years, you will find a sizable number which discuss some vulnerabilty or another involving SSH.  Recently, I have seen a number of security issues involving SSH that has caught my attention.  The first two are the recent announcement of the Barracuda backdoor earlier this week, and that malware authors have been targeting Linux with backdoored SSH daemons meant to steal account credentials.  

The next didn't directly involve SSH, but does shine a light on the lax controls that many organizations have toward resources that should only be accessible inside the corporate network.  That Google was able to index a significant number of HP printers seems to indicate that many organizations have been slow to limit the flow of data in and out of the network.

I would assume that most security concious enterprises have taken steps to require their workforce to VPN into the organization prior to doing a Remote Desktop session, or access services containing senesitive data.  I remember the pain and pushback felt as we implemented this security control in the recent past.  And I remember the sob stories from IT professionals who complained that we were being unreasonable, or needed an exception to the rule. (No you do not need an exeption just because your iPad can't seem to keep a VPN connection stable, while you are doing video editing over an RDP connection. But I digress.)

From my experience, a breach involving SSH seems to have much greater risk than that of compromising a single workstation.  SSH is primarily used by systems administrators, networking engineers, and developers to access some of the most critical infrastructure in an organization.  From a financial standpoint, the SFTP side of the protocol is used by many organizations to upload ACH transactions to their respective bank.  

I have personally seen an uptick the amount of SSH scans, but am not seeing a surge within the DShield data as of yet.  Many organizations may be protecting the inbound and outbound activity well, but the vast majority may not be. It is probably past time that the rest of us to take steps to limit the security exposures to our critical systems with regard to SSH.  Blocking inbound SSH is only one piece in the puzzle.

Be on the lookout for more activity involving SSH in the upcoming months and years.  Anyone else seeing an uptick in SSH activity in the past week? Or is this a localized targeted attack?

 

Scott Fendley ISC Handler

Keywords: ssh
3 comment(s)

Comments

Humm. I thought SSH was suppose to be a VPN... ;-)

Seeing a huge uptick in SSH/RDP scans both from and to public IaaS servers. CSPs provide unpatched servers will few controls to limit administrator access, so its a bit of the wild west. Part of the reason I helped develop GhostPorts (http://www.cloudpassage.com/features/multifactor-authentication.html). Think of it as port knocking with real authentication. Your SSH/RDP ports stay blocked to the world until you enter a six digit code sent to your cell. At that point access is open to our IP only. Combine that with a passphrased SSH key you *have not* posted to Github, and you are in pretty solid shape. ;-)

Cheers,
Chris
I graph failed logins and invalid logins on our ssh server but don't see any recent upticks in either. We also use 2-factor authentication (we use Entrust's identity guard and have been happy with it so far).

Without a strong multi-factor auth setup I'd run sshd on a non-standard port and/or require port knocking like Chris mentions or require ssh-certificate-based auth or all of the above.
New Cisco ASA SSH CVE:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5717

Diary Archives