zero-day exploits, my finest serverfault.com moment (according to the points table)

A question was asked on serverfault about responding to zero-day exploits, and I managed to pitch in with a slightly pontificating answer. 

However it caused me to hit to 200 a day reputation limit, so it seems it is definitely the sort of thing that chaps on serverfault.com like to read.

So here is my currently highest scoring answer in all its glory...

How to prevent zero day attacks

Traditionally, all anti-virus programs and IPS systems work using signature-based techniques. However, this doesn't help much to prevent zero-day attacks.
Therefore, what can be done to prevent zero-day attacks?

Answer:

I think you acknowledge an interesting sys-admin truth there, which is that

1. unless you can reduce the probability of being hacked to zero then... eventually, at some point, you are going to get hacked.

This is just a basic truth of maths and probability, that for any non-zero probability of an event. The event eventually happens...

So the 2 golden rules for reducing the impact of this "eventually hacked" event are these;

1). The principle of least privilege
You should configure services to run as a user with the least possible rights necessary to complete the service's tasks. This can contain a hacker even after they break in to a machine.
As an example, a hacker breaking into a system using a zero-day exploit of the Apache webserver service is highly likely to be limited to just the system memory and file resources that can be accessed by that process. The hacker would be able to download your html and php source files, and probably look into your mysql database, but they should not be able to get root or extend their intrusion beyond apache-accessible files.
Many default Apache webserver installations create the 'apache' user and group by default and you can easily configure the main Apache configuration file (httpd.conf) to run apache using those groups.

2). The principle of separation of privileges
If your web site only needs read-only access to the database, then create an account that only has read-only permissions, and only to that database.
SElinux is a good choice for creating context for security, app-armor is another tool. Bastille was a previous choice for hardening.
Reduce the consequence of any attack, by reducing the power of the service that has been compromised.

Silver Rules are also good.

Use the tools available. (It's highly unlikely that you can do as well as the guys who are security experts, so use their talents to protect yourself.)

1. public key encryption provides excellent security. use it. everywhere.
2. users are idiots, enforce password complexity
3. understand why you are making exceptions to the rules above. review your exceptions regularly.
4. hold someone to account for failure. it keeps you on your toes.