I consider myself to be reasonably good with IT, however I am relatively fresh at server and system administration. I am a web developer for my company and I have been charged with setting up and migrating to a new VPS to get away from the shared hosting my company has been on for ages.

In this process, I have spent almost a week now hardening the server (security became an issue, which is why we're moving in the first place) and have gone over and above to harden the server. I've installed and configured ConfigServer Firewall, hardened SSH, only private keys, all the good stuff. But I found a program called grsecurity that looks promising, but I guess I'm just curious as to whether or not it's overkill?

Are there things that grsecurity offers that I really need? Or is it something that I can do without? I read something about how it prevents buffer overflows and other things, however I am just curious as to whether this is worthwhile, as I don't want to add so many moving parts to the security of this server that I end up falling on my face.

I appreciate any feedback you can give me, or links to tutorials/information that you may have!

For what it's worth, the server environment is as follows:

  • Linode VPS 2048
  • CentOS 6.3
  • PHP 5.4.5
  • ConfigServer Firewall

Again, I appreciate whatever feedback you can offer me! I trust this community implicitly, and I know you guys know what you're talking about!

  • Installing PHP on a public-facing VPS is begging for trouble. Use docker or rkt containers to further isolate apps from rooting the box. Also, reduce the attack surface (ie grsec, custom compile kernel removing all but required features, remove junk services, secure configuration (secure secure shell), etc.) Be sure to keep up on security updates esp. kernel patches. Samhain can also be helpful.
    – dhchdhd
    Mar 27, 2017 at 20:29

2 Answers 2


grsecurity (a.k.a. grsec) isn't really a program - it's a hardening suite for Linux.

It includes the following:

  • A fully comprehensive Role-Based Access Security (RBAC) system.
  • grsec-hardened kernel patches.
  • Enhanced PaX implementation.
  • chroot restrictions (misc features to prevent malware from escaping a chroot jail)
  • General system security improvements.

These features are designed to prevent shellcode from being successful on the system. The restrictions in chroot and other system features help prevent untrusted processes (e.g. httpd) from performing tasks they shouldn't.

Here's a few examples of practical improvements:

  • Prevention of ptrace and other IPC mechanisms between processes that shouldn't be talking to each other.
  • Forensics capabilities via /proc/[pid]/ipaddr
  • httpd can be placed in chroot jail with highly restrictive permissions (no kill, no pid/sid set, sysctl writes, etc. outside of chroot)
  • Full fine-grained auditing of processes, users, groups and other entities.
  • Ability to completely hide kernel-mode processes from user-mode.

The most difficult and powerful part of configuring grsec is the RBAC system. It relies on you to properly and fully configure the privileges and abilities of certain processes. By default, this is a fairly restrictive set. This can often crash and kill certain processes, often with no obvious reason. However, if you tune it correctly, it's an incredible security measure.

It's great for high security scenarios, and I highly suggest installing grsec with RBAC disabled first to give it a go. Set up a proper chroot for your services (httpd at least, preferably SQL / mail daemons too) so that the entire system won't get pwned due to a vulnerability in a single daemon.

There's way too much to cover in a single answer, so I suggest you read through the grsec wikibook.

As to whether you need it - it depends. It's complex to configure (includes a kernel recompile from source, plus a lot of auto-training and manual config editing) and will take a significant amount of time to fully set up, but the result is that you gain a huge amount of resistance against remote code execution vulnerabilities in service daemons and the kernel itself. Figure out how much time you want to dedicate to protecting yourself from such attacks, and go from there.

  • 3
    really nice answer Aug 21, 2012 at 8:10
  • This was an absolutely fantastic answer and I really, really appreciate the time you took to write it. I sort of assumed that it was quite difficult and time-consuming to set up, and having taken many steps to harden the server (firewall, disabled PHP functions, key-based SSH access on a modified port) I feel confident that GRSecurity is considerably more than I need. Edit: ( @Polynomial ) I accidentally pressed enter. I have marked your answer as accepted and I sincerely hope that your incredibly detailed description helps someone else as much as it helped me :)
    – Pierce
    Aug 27, 2012 at 4:29
  • 1
    @Pierce Thanks for taking the time to comment! Glad you found it useful. If you're not using it on your live systems, I would suggest giving grsec a try on a VM, just so you get a feel for how it's set up, in case you need to in future. It's one of those cases where there's a lot that can go wrong, so doing the whole "trial and error" thing on a time-critical or production box is never going to be fun! :P
    – Polynomial
    Aug 27, 2012 at 8:53

Related but important topic:

According to this CentOS hosted page which is about having custom kernels, "CentOS is designed to function as a complete environment. If you replace a critical component, it may very well affect how the rest of the system acts.":


See also this Stackexchange-related answer to the question "Why Centos still not using Latest kernel":


  • Unless purchasing support from grsec, anyone or shop installing grsec must have the skils and resources to deeply adapt and debug RHEL/CentOS.
    – dhchdhd
    Mar 27, 2017 at 20:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .