Edit: I remember writing this in the airport. Some links no longer work.
Originally posted August 2008 by IBM Systems Magazine
I just took off my shoes, took out my laptop, removed the liquids from my carry-on bags and the metal from my pockets. I walked through a metal detector and my belongings filed through the X-ray machine. This was all done in the name of airport security.
It was inconvenient. It took time to navigate through the lines, show my documents and eventually clear security. It took money to implement and maintain all of the systems in place. However, the inconvenience, lost time and money spent was offset by the idea of keeping attackers out of the system. In fact, the knowledge that these defenses were in place potentially kept many threats at bay.
After all of this, the secure area could still be attacked by determined individuals and organizations. A trusted employee could cause harm. Someone who passed a background check could then turn around and do harm. X-rays and metal detectors are deterrents, but they can’t guarantee that nothing bad will ever happen.
As we all prefer the convenience and time savings we gain when we fly, decisions are made as to acceptable risk and potential inconvenience to travelers. People learn the new security rules and follow them. Airport security and server security involve protecting different things, yet have similar goals. Instead of protecting planes, you want to protect data, keep it on your server safe from attackers and limit system access to authorized personnel.
Planning Network Security
The only secure server is one that’s turned off. After you hit the power button, you have to start trusting people. When you power it on and let people have access, you run the risk of compromised security. You must trust the people that work on the servers. You should decide what activities you’re trying to prevent. Are lives at stake if medical data is updated? Is privacy and financial harm to your customers an issue if Social-Security numbers or credit-card numbers are disclosed? Are trade secrets and confidential business plans at risk if someone has access to sensitive information?
As you think about securing your machines, think about network security, physical security and user security. I’m attempting to get you to think about what you’re doing right, wrong and what you might need to change. This isn’t an all-inclusive list—threats change and evolve, and specifics change—but the basic concepts remain the same.
See the Redbooks* publication, “Understanding IT Perimeter Security” for more information on this topic (www.redbooks.ibm.com/redpapers/abstracts/redp4397.html?Open).
We usually put our machines behind firewalls. In some environments, firewalls aren’t enough, and absolutely no network activity is allowed to the public Internet. Some companies choose to implement different network layers and segregate which machines access which networks. In some environments network traffic isn’t allowed to leave the computer room—you have to use a secure terminal in a secure area to access data. Again, you must weigh what you’re trying to accomplish, from whom you’re trying to protect yourself and what harm will be done if the data you’re trying to secure is compromised.
I once heard about a phone call from a customer to a service provider who was hosting his servers. The customer asked the provider how secure his physical servers were and was told that they were in a raised-floor environment that required a keycard to access. The customer replied that he was standing in front of the servers on the raised floor and he wasn’t happy. Dressed in his normal clothes—not as a maintenance man pretending to do work on the air conditioning unit—the customer gained entry when a friendly, helpful authorized person held the door to the raised floor open for him.
This event caused mantraps to be installed. To access the raised floor, you had to scan your fingerprint and your keycard, and then enter the mantrap one employee at a time. It caused more pain when many people needed to access the raised floor at once, but it was determined that this pain was offset by the gains in knowing exactly who was on the raised floor, and removing the possibility of someone letting any unauthorized people onto the floor. If an attacker gains physical access to the machine, then it’s game over; physically securing the machines is critical.
Tightening Security
Many data centers have locked cages around the servers. In the aforementioned scenario, even if a helpful employee helped you access the raised floor, you’d still need keys to the cages to work on the machines.
This isn’t limited to a raised-floor environment. Once I have access to a desktop machine I can add a small connector between the keyboard and the machine to log keystrokes and capture passwords. I can copy data onto a USB thumb drive. I can boot the OS into maintenance mode and make changes to allow me to access the machine in the future, or change the root password. All I need is a part-time job with a cleaning crew and many machines are vulnerable to attack.
Many people still use Telnet and FTP to access their machines. Both of these programs send their traffic unencrypted over the network. If I trace the network traffic on my machine I can easily capture cleartext passwords. I’d make it a priority to convert to SSH/SCP/SFTP so that the network traffic was encrypted.
SSH has its own problems. Many people like to set up public/private keys and allow themselves to access their servers without passwords. It can be convenient to use one master workstation to connect to all of the machines. By setting up public/private keys you may easily create wonderful tools that allow you to make changes across your environment instead of logging in to each machine individually. If you choose to do this, be sure to protect your private keys. If I steal your keys, I can log on as you. It would be better to create a passphrase and then use SSH-agent instead of having no passphrase at all. Again, you have to weigh the risks versus the benefits. See “References,” below.
On the public Internet, the number of attacks logged against port 22 has been rising. If your SSHD is listening on the public Internet, it might be worth changing the port it’s listening on. This will keep some automated scripts from attacking you, since you won’t be listening to the port that they expect you to, but this is also offset by the pain of notifying everyone that needs to use this newly changed port. This won’t help if the attacker port scans you and finds the newly assigned port, but may help defend against automated tools and unsophisticated attackers.
Final Tips
Run netstat –an more on your machine and look at all the ports that are listening. Do you know what every program is? If not, find out what starts that process and turn it off. Check in /etc/inetd.conf, /etc/inittab, /etc/rc.tcpip etc and turn off unneeded services. You can’t connect to a machine that isn’t listening.
Verify your path is set correctly and think before you type. I’ve heard of attackers that would change root’s path to have “.” at the beginning, which caused it to execute whatever was in the local directory first. Then they had to add a script or program to some directory and get root to run it. Depending on the administrator’s skill level, they might not even know that they just gave away root access to the machine.
Secure, Workable System
Monitoring logs, hardening machines and continually maintaining a secure posture can be painful for both system administrators and for users. You want to keep the data relatively easy to access for those whose jobs demand it, while keeping others out. In both scenarios, the goal is a secure workable system, either in the air or on the raised floor.
References
www.lbl.gov/cyber/systems/ssh.html
www.securityfocus.com/infocus/1806
www.cs.uchicago.edu/info/services/ssh