In the desktop world, people tend to feel good about their system’s security when they have the latest anti-virus and anti-spyware installed and keep their applications up-to-date. Those of us who compute for a living know that this is nothing close to resembling a “secure” state. But it’s the best option for non-technical people at this time.

Servers, on the other hand, exist in a more hostile environment than desktop machines, which is why keeping them secure requires skilled professionals. This means not only doing things like keeping applications patched and up-to-date, but also grasping the underlying principles of system security. Doing that allows us to make informed and skillful decisions for our unique systems—because no one knows our servers as well as we do.

Let’s look at a simple example using file permissions. Let’s say you installed a CGI (Common Gateway Interface) application, such as some blog software, and you’re having trouble getting it to work. You’ve decided the problem is the permissions on the configuration file. In this case, user “rasto” is the owner of the file. You try chmodding it 755 and it works like this:

-rwxr-xr-x 1 rasto rasto 216 May 27 16:11 configuration.ini

Now that it works, you’re ready to move to your next project. But there’s a possible security problem here. As you can see, you have left the configuration file Readable and Executable by Other. There is almost certainly no reason for that because CGI scripts are typically run as the owner of the file. There is potentially no reason for users of the same group (or other random users of the system) to be able to Read this configuration file. After all, some configuration files contain database passwords. If I have access to another user on this system, I could simply “cat” the configuration file and get trivial access to your data!

So the trick is to find the least permissions required to run this script. With a little work, you may discover that it runs just fine with 700:

-rwx------ 1 rasto rasto 216 May 27 16:11 configuration.ini

By taking a little extra time, you have made your system much more secure. “Default Deny” means deny everything that is not explicitly required. The beautiful thing about this policy is that you can remove vulnerabilities that you neither comprehend nor even know about. Instead of making a list of “bad” things you essentially make a list of “good” things, and allow only those things to happen. You don’t even have to realize that someone could read the file because you’ve made it a policy to always allow the least amount of access possible to all things.

Another example might be to prune your php.ini to get rid of any expanded capabilities not required by PHP scripts running on your system. If a zero-day vulnerability arises in PHP that affects one of the things you’ve disallowed, it simply won’t affect you because you’ve disabled it by default.

Another scenario might be to remove packages from your system that are not being used. If someone tries to inject some Ruby code into your system, it won’t run without Ruby present. If you’re not using it, get rid of it, and it can’t be used against you.

Note: It’s very easy to be wrong about what is not being used on your system—you can definitely break things this way—I suggest a go-slow approach, particularly in regards to built-in packages.

The important thing is the concept. I hope you can see now why a Default Deny policy is a powerful tool to help keep your system more secure.