Protecting your server 4 - configuring the OS

Your OS will always be running on your server. While most commercial solutions available nowadays are perfectly adequate for consumer requirements, few are ready for deployment as secure server solutions. We're going to look at a few things that you can do to maximise the security of your particular OS. This guide will work as an interface for any OS, though the implementation may differ. It broadly follows our two rules-of-thumb introduced in part 2 of this series - although you will see elements of part 3 come through as well.

Patching

To remove any loopholes in your OS is a long task, but a lot of time can be saved by applying patches. There are a few things to take in to account, though.

1. Patching does not solve all loopholes. Some will remain, and you'll need to keep reading to minimise those risks.

2. Document your patching process. It might seem tedious, but you never know who might have to apply a patch later on - or under what duress they might be required to do so. Document your process for applying a patch carefully.

3. Take your server offline until it's patched. This applies at any stage of the patching process: the second a patch is released, hackers will be aware of the loophole it's designed to close. Make sure your server is offline - or use a VPN - while you patch it.

4. Recognise that patches can reduce functionality. Particularly if your server is of complex design, patches might mess with your set-up. Check it on a single machine before rolling it out to the whole network, or make sure you've backed up your server recently and can roll-back in the case of disaster.

Ensuring least privilege

the most critical element of ensuring least privilege is disabling access to functionality that a user won't require - or, better still, not installing them at all. These can and should include:

• File sharing and printer sharing services (a notorious access loophole)

• Remote access services (unless they are securely encrypted, such as Apple Remote Desktop)

• Directory Services

• Language compilers (your users won't need to write code - or at least, remove super user privileges)

• Network management tools

• System development tools

Why do we do this? Because the safest way to ensure protection for your server is to insist on least privilege. It also ensures that any threat logging is kept to a minimum.

User accounts

User groups can be set, and users allocated to a group. In these groups you should be considering which users require 'read' access to files - can view them - and which require 'write' access to them - can create or modify them. This will likely be different for different parts of the server. By allocating appropriate read/write access to user groups, and then user accounts to appropriate groups, the principle of least privilege can be malleably maintained. Default user accounts should be disabled - there should be no accounts which aren't ultimately accountable to your system (complete mediation).

In the next section, we're going to look at host software, including anti-malware, firewalls and so on. We're also going to look at how you should go about testing the security of your server to ensure that your system is working.