How to prevent zero day attacks

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

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 separating the power of the service that has been compromised into it own "Box".

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.

Whitelist, don't blacklist

You're describing a blacklist approach. A whitelist approach would be much safer.

An exclusive club will never try to list everyone who can't come in; they will list everyone who can come in and exclude those not on the list.

Similarly, trying to list everything that shouldn't access a machine is doomed. Restricting access to a short list of programs/IP addresses/users would be more effective.

Of course, like anything else, this involves some trade-offs. Specifically, a whitelist is massively inconvenient and requires constant maintenance.

To go even further in the tradeoff, you can get great security by disconnecting the machine from the network.

Detection is Easier (and More Reliable) Than Prevention

By definition you cannot prevent a zero day attack. As others have pointed out, you can do a lot to reduce the impact of a zero day attack, and you should, but that is not the end of the story.

Let me point out that in addition, you should devote resources to detecting when an attack has occurred, what the attacker did, and how the attacker did it. Comprehensive and secure logging of all activities that a hacker might undertake will both make it easier to detect an attack and, more importantly, determine the damage done and remediation required to recover from the attack.

In many financial services contexts, the cost of security in terms of delays and overhead in executing transactions is so high that it makes more sense to focus resources on detecting and reversing fraudulent transactions rather than to take extensive measures designed to prevent them in the first place. The theory is that no amount of measures will be 100% effective, so the detection and reversal mechanisms need to be built anyway. Moreover, this approach has withstood the test of time.

Zero day doesn't mean that signature is not known. It means that there's no patch available to users of software, that closes vulnerability. So IPS is useful to protect from exploiting zero-day vulnerabilities. But you should not rely only on it. Create and follow a solid security policy, harden your servers, update software, and always have a 'Plan B'

Grsecurity or SELinux are good in helping to prevent 0 day attacks by hardening the kernel.

Quote from website "Only grsecurity provides protection against zero-day and other advanced threats that buys administrators valuable time while vulnerability fixes make their way out to distributions and production testing. "