Hulk Smash Puny SSH!

Sorry, I’ve been monkeying around on the twitter birds, following one of my favorites, SecurityHulk. https://twitter.com/securityhulk

Follow, read, laugh, cry, and ponder the Green Wisdom.   Anywho, todays fun to be had is SSH.  I’m going to skip the history lesson (here) and summarize.  SSH gives us a secure connection into a location, providing confidentiality and integrity.   Primary usage is accessing a remote command line, but you can do so much more with it, from tunneling all web traffic through it (bypass web filtering,) to using X11 for a full graphical experience.

It’s called Secure Shell, so that means it’s impenetrable right? Meh, just like any house, the front door can be solid steel, but if you leave the window open, you’re hosed.

So how can we be safe with SSH on the F5? Let’s jump right into the good stuff.  (the following is directed towards SSH on the F5 management interface. While it’s good general rules, it is extremely applicable to the F5)

1. Strong Passwords

   Why are we still harping on this one?! Cause it still is an issue.  Once attackers got into a company, bouncing between devices was easy because:

80% Use of weak administrative credentials (SRC: Trustwave GSR2012 )

What’s a strong password? Tough question.  There are all sorts of guidelines for password strength. If you want to go off various entropy Bit standards, than a strong password will have 80-bits of entropy.  Or you could require the output of /dev/urandom be used as a password:

dd if=/dev/urandom bs=1 count=15|base64 -w 0      gives:  lhTiX6b6eNxoZXqugvTs

That’s easy to remeber right? 

In the end, you have to decide what is secure to you. Personally, I recommend the following minimums:

With the typical reuse limits  (cannot reuse last 3 passwords), password cannot contain username, and it is on a limited life (6 months, 1 year max)

2. Management Interface SSH on Public Internet  - why baD?!

The F5 Platform is a critical piece of network infrastructure. Would you expose the management interface of your core routers and switches to the public internet? Please.. Please PLEASE answer no. If you did not answer no, I trust that you’ve run through a full Risk Analysis of it. So then, what’s a good way to handle the management access? Management domain Basically, create a separate vlan for management access. On the vlan, you can put in a nice set of tight ACLs. Then, you can use the vlan for all the management type traffic you need to do.

Check out the Ask F5 solution for some more direct data on the management port.

3. Authorized Keys

SSH on the F5 makes use of the authorized key file and you can to! The authorized key file stores the public key of a public/private key pair.  Once an admin puts their public key in the file, they can then log on to the system using the corresponding private key.

** IMPORTANT NOTE ** Make sure you’re read the Security Advisory regarding an old F5 SSH issue

One thing to think about if you are making use of the authorized keys path is to ensure that it is managed and audited. 

How do you audit the authorized key files?  It’s just a string of random garbage right? People always forget that at the end of the key, there is a comments section.  I recommend putting identifying information for the key in that section:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAqJ7hlsGK+h8+6f3k1hkEy0h9SfDfoihEJa/2uhcTMXg0b2E/

ELnNjeHUC6sl0SR5qQRn2OH6F/3qawClcjrs625hK+wTAdGeg9r/0GCehnGqXR8xTAq1EqStIoLhBtzfe6l0krwsuH

e3cHCW+PybFKXE7l5qBjUs8saE53o6mNc= rsa-key-20121010 bob is a monkey

This way, when I do the quarterly audits, I know that that key is for the monkey bob. If monkey bob’s access ever needs to be pulled, I know which key is his. 

I hope you found a shiny tidbit of information in my Hulk inspired ramblings. Remember, SSH is our friend! Just want to be sure it’s not getting friendly with the wrong people.

:)