Publishing System Settings Logout Login Register
Protecting your server part 2
TutorialCommentsThe AuthorReport Tutorial
Tutorial Avatar
Add to Favorites
Posted on May 29th, 2012
Windows XP

Protecting your server 2 - key protection measures

Your server will be networked, probably all the time. This makes your laptops vulnerable to 'attacks', in which either the confidentiality, integrity or accessibility of your data is compromised. This series is taking an in-depth look at server security and how you can best prevent this happening. This article is going to look at the two main security controls fundamental to the theory of server protection, and analyse some possible causes for their failure. Forearmed is prepared - let's dive in.

Security Controls

Your server needs to have a security system, but how can we break down the main requirements? The two most important considerations are as follows:

1. Resolve weaknesses

Any weaknesses in server security should be addressed first. These could be physical weaknesses - if the server is stored in your home, where are you storing it? Should you put it on a table, in a drawer, in a cupboard, under the floor? Bear in mind you will need good airflow to maintain the hardware integrity. If your server is stored somewhere public, do you want to permanently attach the hard drive to the machine, leaving thieves unable to take your data? These weaknesses could be at the Operating System level - which OS will provide the fewest weaknesses to the kinds of attacks you might face? Mac OS X has a reputation for security, but a great deal of that is down to low user adoption. Windows release multiple patches (usually referred to as 'Service Patches' such as 'SP3' for Windows XP), so it's critical you apply those and keep them up to date - those patches are designed to resolve weaknesses for you. They could be at the application level - is your virus database up-to-date?

This might all seem a bit boggling, but fear not - we're going to break down these questions to the real nitty-gritty in the next article. Hopefully, though, you can isolate most of the major problems using this rule of thumb.

2. Least Privilege

The principle of 'least privilege' means that users accessing your system should have the minimum possible functionality accorded for their requirements established as a maximum boundary. That is: users should be able to do as much as they need to, and no more.

This might seem drastic, but it simplifies a lot of issues. If users are accessing your server to run a remote desktop on, do they really need to be able to customise their background? In fact, do they really need to be able to access any Control Panel (in Windows) settings at all? By operating the principle of least privilege you can save yourself a great deal of headache later on in the security process.

Problems associated with these controls

These security controls, of course, introduce inconveniences to the user - and it's usually in response to these inconveniences that the security can be compromised (willingly or not). For example, a common weakness to resolve is that anybody can log on to the server. To resolve it, most administrators create user accounts for users, and insist that they have passwords. For many users, remembering a password is an inconvenience - the threat of forgetting it is deemed greater than the tiny chance of threat that their actions might inadvertently compromise the security of the system. So, quite a few of your users will tend to write their password down. There's no way to avoid this - but, for each security measure you introduce, it is worth thinking about the effect on the user, and their likely actions. You cannot control those - try as they may, system administrators have had little luck in encouraging user compliance with reminders - however aggressive - not to write down their passwords.

Again, the principle of least privilege will introduce inconveniences to some of your users, too. Say, for example, you are operating a 'closed web', blocking some unsuitable sites. Users may hunt down and use 'proxy sites' - which of course you can close down, but users will only then head to the more nefarious sisters of those you have condemned, opening your system to attacks not possible had you allowed users higher privileges in the first place. To combat this, consider putting in many layers of privilege - we'll address this more in the next article.

The point of security controls is to offer fewer opportunities to breach your system. As you've seen, this needs to be balanced with the negative feedback loop of user non-compliance. We're going to see how we can design a system that encourages compliance from the ground up, next article.

Dig this tutorial?
Thank the author by sending him a few P2L credits!


This author is too busy writing tutorials instead of writing a personal profile!
View Full Profile Add as Friend Send PM
Pixel2Life Home Advanced Search Search Tutorial Index Publish Tutorials Community Forums Web Hosting P2L On Facebook P2L On Twitter P2L Feeds Tutorial Index Publish Tutorials Community Forums Web Hosting P2L On Facebook P2L On Twitter P2L Feeds Pixel2life Homepage Submit a Tutorial Publish a Tutorial Join our Forums P2L Marketplace Advertise on P2L P2L Website Hosting Help and FAQ Topsites Link Exchange P2L RSS Feeds P2L Sitemap Contact Us Privacy Statement Legal P2L Facebook Fanpage Follow us on Twitter P2L Studios Portal P2L Website Hosting Back to Top