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:
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:
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?!
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.
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:
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.