There are many techniques that we can use to make our operating systems less vulnerable to attack. In this video, you’ll learn about operating system vulnerabilities and the methods that the bad guys use to take advantage of these vulnerabilities.
<< Previous: Zero-Day AttacksNext: Anti-Malware Software >>
The default installation of an operating system is probably not going to provide you with the security posture you’re looking for. You need to do a little more work to make your operating system as secure as possible. And we call this process hardening the operating system.
It’s usually not just one thing or two things. There’s usually a group of things that should be considered as best practices when you’re trying to make your operating system as secure as possible. This is also something that you always have to keep working on. You don’t just harden your operating system, and you’re done. There’s constant maintenance that has to be done. There’s weekly updates, monthly patches. There may be updates that occur without any type of warning. And all of these have to be applied to the operating system to maintain its security.
In fact, it’s not just about patches. It can also be about the way that you set up the operating system. You make one tiny configuration change and open a particular network share up to have a broader set of permissions than you wanted, and now, suddenly, you have a security problem on your hands. So you have to consider how you’re going to secure the operating system from many different perspectives, and you have to stay up on what the latest patches might be.
One way to make your operating system a bit more secure is to disable any services that you don’t need. Well, what services are really unnecessary? With Windows XP, there were almost 90 services that were installed by default. In Windows 7, that number was over 130 different services. It can be difficult to piece through all of those services and know exactly which ones are OK to run and which ones can be disabled.
Every service, of course, has the potential to provide us with a security issue because they might all have vulnerabilities inside of them. We just haven’t found what those vulnerabilities are yet.
Normally, our monthly patches from Microsoft, from Apple, from the Linux consortiums, they will help us resolve these types of security issues, but it’s the zero day problems, the ones that we don’t know about, that are our biggest security concern. This is, of course, going to require a lot of research to determine which one of these services do I turn off? Which one of these services stay on? There are a lot of different sources out on the internet to gather these details, and very often, the manufacturer of the operating system can give you a lot more specifics over what services are required and which ones can be optionally disabled.
If you’re still not sure what services should be disabled, you could always try turning some off to see what happens. Turn off a service. Run your applications. Print some things. Make sure your file transfers work properly, and maybe that particular service can remain off. But if you run into a problem, you may need to re-enable that service. It may take some time to go through your entire service list, but this at least gives you a strategy for finding and disabling those unnecessary services.
Another potential for operating system vulnerabilities is any place there might be open ports. These services that we run on our computer open ports up to the network to allow access for others to come into our system. You can see that this web server, for example, has an open port UDP 53, TCP 80, and TCP 443, and that’s because this web server is providing DNS services over UDP 53 and providing web services over TCP 80 and TCP 443.
Now, normally, that’s absolutely acceptable, especially if you want to provide those services to the rest of the network. But if any of those services is unnecessary, they should be disabled, and sometimes a service itself has a vulnerability, and the way that vulnerability is accessed is through these open ports.
If there are any devices on your network, then eventually they’re going to need to be patched. These might be your computers, your servers, and even the operating systems running inside of your infrastructure devices. There’s usually a change control process you would follow to make sure that these updates go smoothly. You plan the update, you perform the update, and then you have a back up plan in case there’s a problem with the update. You should always plan for problems, and that way, you always know what to do if you run into any issues.
Between the time that a patch is released and the time that it is installed, there’s usually a delay. The length of this delay is really up to you. You have to take this patch, install it on your own systems, test it, and make sure that it doesn’t create a problem for your operating systems or your applications. And then you roll it out to the rest of the organization.
Some systems, though, don’t like to be touched. Maybe the operating system running on this device doesn’t have any type of support. Maybe the application itself is so old, the company isn’t even around any longer to provide support, and you’re concerned that changing anything on that computer is going to cause that application to stop working. Even rebooting the system has a number of issues associated with it. It’d be better if the system just kept running and kept running, and you wouldn’t have to touch anything.
That, of course, is a pipe dream. We still have to have patches and updates and provide security for all of the systems on our network, so there needs to be a plan in place. Maybe you have constant images being made of these legacy systems. That way, if you perform an update, you can always revert back with a complete reimaging of the operating system.
If you’re communicating to a device that’s over the network, you would ideally be using a set of protocols that encrypt the data. You don’t want to send in the clear information across the network. It is so easy to gather information that’s being sent over a wired or wireless networks these days, so you want to have some encryption method in place. This is not a simple thing to implement. It requires some planning, a certificate authority. You need certificates put on your web servers, but that hard work is going to result in a very secure channel between the devices on your network.
This in the clear information is so easy to gather, especially on wireless networks. We use so many open wireless networks in coffee shops and hotels, in conference centers, that you want to be very careful about what you’re sending over those particular networks. You need to always consider that there may be somebody listening in on the conversations that are going out over the network, and if you do that, you’ll be much more aware of what you’re sending, and you’ll be much more apt to have an encrypted channel between you and the other device.
We’re creating a username and password for a particular service. Those credentials have to be stored somewhere. Generally, the username is stored in plain text. My name will be there and readable in that database, but the password will not. Ideally, the password is never going to be stored in plain text. It’s going to be encrypted or hashed in some way. Generally, information is added to the password, and all of that information is then hashed so that you have this extra salt that’s added to the hash. Having the salt in place makes it harder for somebody to perform a brute force against that hash to determine what the password might be.
If you’re wondering if someone is storing your password in plain text, one way that you can tell is if you’re asking for a password reset, and you get an email that has your password inside of it in plain text. Then you know that particular password is insecure. It’s being stored somewhere in this plain text format, because you can’t reverse engineer a hash. A hash is a one way function, and, of course, sending me the hash doesn’t help me. A secure password reset would send you a link into your email that then takes you back to that service to update and change your password information.
A plain text password should never be sent over any electronic medium. If you’re finding that you’re receiving emails with your password inside of it, or you’re the one sending the emails with the password inside of it, you need to find a different way to communicate that information to the end user.
If you have a packet analyzer, and you’re gathering information from a wired or wireless network, there’s a lot of information that’s being sent in the clear. There’s a number of protocols that you could use to protect this information instead of sending it in a way that anybody would be able to read. For example, a communication protocol that you would not want to use over network is this relatively old SLIP, or serial line interface protocol. We don’t do a lot of serial line communication, and this is a protocol that we definitely don’t want to use on our modern networks.
If you want an example of a more modern protocol you should not be using, then you can see Telnet is a good example. That’s a terminal communication, and everything sent over that terminal communication using Telnet is all in the clear.
We also have in the clear communication to our web servers inside of our browser if we’re only using HTTP. Sometimes, this information is perfectly acceptable to send in the clear. But if you’re performing anything that needs security, do not want to be using HTTP.
File transfers can also be a good place to gather details, and some insecure file transfers can be done by FTP and TFTP.
And lastly, on the network management side, SNMP is all in the clear, so SNMP version 1 and SNMP version 2 should not be used on a network if you are at all concerned about the security.
A type of security concern that we don’t often think about are radiofrequency emissions. Everything we have on our computer is sending RF signals. We have sounds from the computer, from our monitors, the keyboards and wireless devices that we’re using. Everything has some type of RF associated with it.
You’ll sometimes hear the code word Tempest associated with this. Tempest is a National Security Agency specification and a NATO certification. This is one that these organizations are very concerned about, because they want to be sure that your networks and your devices are as secure as possible. So they have standards for minimizing the amount of radio frequency emissions coming from your computer.
Here’s an example of just some of the things that you can do to minimize the amount of radiofrequency emissions. One is to shield the devices that you’re using. You can shield inside of the computers, and you can shield the cables that you happen to be using. Maybe you separate the information going over these network cables, where you have one cable sending classified information and another one that would send unclassified information. It’s common to have are classified networks run on a fiber network since those have such little amounts of RF associated with them.
You can also add filters to the cables you’re using to prevent some of this RF, and maybe you move away from walls, since it’s through the walls that you’re able to hear a lot of these radio frequencies coming through. If you can minimize how close people can get to the computers, then you’re minimizing their chance of hearing any of these RF emissions.