Guest Post by Richard Pettit, Developer, Lieberman Software Corporation
Sometimes the focus of security is on the infrastructure that takes up the most space. The systems in the racks, on the desktop and on the budget. But, it’s important to protect every item in your sprawling network – especially the Unix/Linux servers.
An Uninvited Guest
I leave my Linux server running all the time. It’s the file and directory server for my local network. It’s easier to keep it up and running so the other Unix systems on the network are available at any time. It’s also the firewall for the local network as it is connected directly to the Internet.
It was a surprise. I logged in first thing in the morning and when I ran who, I saw that root was logged in from a remote IP that I didn’t recognize. Someone had logged into my Linux server remotely with my privileged account. They had cracked my password, which upon reflection, was not very secure. It was a common dictionary word with one letter changed from the letter “o” to the number “0”. I had been hacked. Granted, it’s common IT policy to not allow root logins from the network, but this was my home network, not a business.
This is not a terrible story since there was nothing critical on the machine. There was no bank account information, no credit card numbers, no Personally Identifiable Information. They could look at anything they wanted and all they would find was some source code that was already open source. Luckily, it was a bust for them.
Back in Time
An important point about this story is that it took place in 2002, 15 years ago. It’s not a new concept; hacking a system by guessing a simple password. Knowledge of Unix/Linux system accounts was well known that long ago and the usurping of security by using an account with elevated privilege was an instrument in the toolkit of the bad guys.
Time to Act
So, fool me once, shame on you, etc. But that was a while ago. What excuses can be employed in 2017 when this is well-known and examined problem has very effective countermeasures? And, in light of the enormous number of Unix/Linux servers being used worldwide by major corporations with much to lose, this type of lapse goes way beyond fool me twice, shame on me.
There is simply no excuse for not implementing an Automated Privileged Identity Management (PIM) solution that keeps passwords and SSH keys safe on the corporate Unix/Linux network. The responsibility falls on the desk of the CISO. When the time required to recoup the cost of a PIM solution is within one day, this isn’t a difficult decision given the possibility of a 9-digit financial loss from the hack.
Privileged Identity Management for Unix and Linux
The security of your entire network is only as good as your least secure server. And, relegating the Unix/Linux infrastructure to a status of any lesser degree is the attack surface that hackers are looking to exploit. After all, it’s likely they’re launching their attack from a Linux machine! There’s no reason why they can’t launch it again from inside your network on your Linux machines.
Taking the simple step of implementing a PIM solution for the Unix/Linux network can be the difference between being secure and finding out (too late) that you’re not alone on your Linux server.
Keep the passwords of privileged accounts complex, change them on a frequent schedule, and audit their use. Keep the SSH private keys secure to prevent SSH vulnerabilities, change them on a regular schedule, and audit their use. This is the task of a PIM solution. It’s is not just for the Windows infrastructure, but for the Unix/Linux servers as well. In fact, I would argue that PIM is especially critical for your Unix/Linux servers.
Want more tips for securing your privileged identities? Get our white paper, Best Practices in Privileged Identity Management.
If you like this topic, please subscribe to our Cyber Defense Newsletter.
You can also follow us on Twitter.