Out of the box, your operating system probably isn’t the most secure. In this video, you’ll learn some best practices for security your operating system from the bad guys.
<< Previous Video: Monitoring System LogsNext: Physical Port Security >>
When you first install an operating system, one of the things you commonly do before you ever connect it to a network or put it in production is to harden the operating system. And what we mean by that is to make your operating system one that is much more secure. We want to be sure we have all the latest patches.
We want to be sure all of our applications are up to date. There may be different tweaks we can do to make sure that our operating system is hardened. We’re wanting to improve that security. But it’s not just any one thing. It’s a number of different things to be able to increase the security.
That’s one of the challenges we have with making sure our operating systems and our computers in general are secure is that there are so many different ways the bad guys can get in. So obviously there’s so many different ways that we need to consider when we’re hardening up our operating systems. This also requires constant maintenance. We need to make sure that we have all of the latest patches.
Vulnerabilities are announced every month, sometimes in much more frequency. So we need to be sure that we have all the latest patches for our operating system and the latest patches for the applications that are running on that computer. In fact, we even, after putting the patches on and making sure our applications are up to date, may still find our systems vulnerable because of a configuration change that we made that allows the bad guys on to our system.
So we have to constantly monitor and maybe do checks of our systems to make sure that we haven’t inadvertently configured our system in a way that’s going to allow the bad guys to gain access. One way to harden our systems is to disable any services that may be running that we just don’t need. They’re unnecessary. This is a bit of a challenge. For instance, Windows XP, when you first install it, has almost 90 services installed.
Not all of them are active, but they are all installed. This is a screenshot of my Services view all my Windows XP. Some are started. Some are not. But you may not want to have all of them running, because all of those services may create an additional opening for the bad guys.
But we have to figure out which ones have the potential for trouble. The ones that we are worried about are the ones that that have known vulnerabilities. But of course, we’re also concerned about any services that have unknown vulnerabilities. But if we disable the service, we don’t have to worry about the vulnerabilities. So there’s the value in disabling some of these unnecessary services.
This may require a bit of research. These services are running Windows, Linux machines, Unix space machines, Mac OS X. Almost any operating system is going to have services that run in the background of some kind. So you may have to go the web, you may have to find out if this particular service on this particular server running these particular applications can be disabled without having any adverse effects.
Obviously, it’s a bit complex. Sometimes it’s trial and error. Let’s turn it off and see what happens. Sometimes that’s a good way to determine if it’s a necessary service or not. So you test it, you monitor, and you make sure that once you’ve disabled those services that everything continues to run. And the smaller number of services you have running on a computer, the better the security posture is going to be.
Practically every network device you have out there has a management interface associated with it. Your firewalls, your routers, your switches, your IDS, IPS systems, anything out there has a way to gain access, because your administrators need access to those systems. So obviously, you need the management front end. But what you don’t want to allow is the bad guys to have access to this management front end.
These systems have a lot of sensitive data on them. They’ve got to have these interfaces available to us. So we want to do some simple things like set up some passwords so that if someone does gain access or finds the IP address that we would use to authenticate to this device, that they wouldn’t have the right username or password to gain access. That’s a very simplified way.
Most larger organizations are adding additional security on top of that. Not only do you have to be coming from a particular IP address or IP address range to gain access to that management interface, but it may require additional log-ins to get access to that interface. And it may require some third party authentication. We may have to have a token generation tool.
We may have these systems send us a text message with a number on it that we then have to type in to gain access. The only way that would work is if you were the one that had the token generator and you were the one was carrying that telephone.
All of our servers have accounts on them. They have usernames. They have passwords. So we also have to think about hardening up those usernames and passwords in those accounts. But weak passwords are very, very difficult to protect against. It’s very easy for the bad guys to interactively try to log in as a particular user.
So very often, we have to have policies on our servers that if you log in more than five times with a bad password, we’ll disable the account for a certain amount of time or perhaps disable it entirely. If they gain the entire database of those passwords, even though the passwords are not stored in plain text, they’re stored as hashes generally, they can now offline do some brute force attacks against those hashes to try to determine what those passwords might be.
So we have to protect the store of those passwords as well. What we really want is our passwords to change often. And we need our passwords to be relatively complex. We want to be sure that if somebody gains access to those password files that at least the brute force attack would not generally be successful.
We’re going to try to make sure or reduce the possibility that someone would not be able a brute force any of those passwords. This isn’t always the best possible situation. Sometimes you’re not in control of this. For instance, in December of 2009, the website rockyou.com had a security breach. It was a SQL injection.
And the bad guy stole 32 million account information. So they were able to gain access to usernames and passwords. And the problem with rockyou.com is that all of those username and passwords were not hashed. They were stored in the clear, as crazy as that sounds.
So that became very easy for the bad guys to gain access to this. But here’s what’s even more interesting. They posted the entire 32 million account database to the web. So now anybody could download the torrent, download the file directly, and be able to look through all 32 million accounts. It was obviously very embarrassing for rockyou.com, and it also created a number of security concerns for everyone else, because unfortunately, so many people use the same username and password wherever they might go on the web.
But what this did allow us to do is to perform some analysis of these usernames and passwords to see where are we having problems with these password policies that we have in place. A company called Imperva did a study of these passwords. And you can access the study itself at imperva.com. Here’s the download link for that PDF file.
What they found as they went through these millions and millions and millions of accounts is that 30% of the passwords were six characters or less. And in the rockyou.com case, the minimum requirement was five. So people were just barely going over the minimum requirement. 30% of them, six characters or less.
Obviously the smaller the number of letters in a password, the easier it is to do a brute force attack. 60% of the passwords were from a limited set of alphanumeric characters. There were no special characters in there. There was nothing that was outside the realm of what you would find a through z and zero through nine. And obviously, that makes it even easier for the bad guys to do a brute force attack.
50% of the passwords were names, slang, trivial things, or dictionary words. And in those cases, it becomes exceptionally easy to do a brute force attack. You want to do anything but this. You want to have very different passwords that are much stronger than words you might find in a dictionary.
The most common password– 123456. 290,000 of these users, the password was 123456. There were 79,000 users it was 12345. That’s even worse. And of course, 76,000 users were– they made this one very hard– 123456789. 61,000 users had password as their password. Doesn’t seem quite obvious does it.
And iloveyou came in, the last one here, 51,622. And of course, there’s many more. They listed out the huge frequency in this download PDF file– very interesting. But it does point to how we have to be diligent about making sure that we have strong passwords and that we’re auditing our systems to be sure that our passwords were strong.
It’s very, very common for the security team to grab their password files and do their own brute force attack. How hard is it for us to find the usernames and passwords on these systems and determine are we really putting safe passwords, very difficult to find passwords on our systems? When we install an operating system, it usually installs a default set of accounts.
But we may not want all of those accounts to be on our system. After all, if we have an account, there is a possibility that someone could use that account to run programs or log into the computer. So if we were to disable or even remove accounts we don’t want, we would then be making our systems just a little bit more secure and harden them up just a little bit more.
In the case of Windows, there’s usually a guest account that’s installed, even if it’s not enabled by default. Linux or Unix has a number of accounts that can get installed or put into our system when we first install the operating system. But not all of these are necessary.
We may want to go through this list and start disabling or start removing some of those accounts. In fact, there’s some of the accounts that maybe we just don’t want any interactive logins whatsoever. You may need that account to be able to run different batch files or different processes on the computer. But you want to be sure that if somebody was to gain the username and password, that they would not be able to log in.
So that could be an additional piece that you can add on to help make your operating system just a little bit more secure and a little bit more hardened.