Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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!

share|improve this question

1 Answer 1

up vote 9 down vote accepted

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.

share|improve this answer
2  
really nice answer –  Mark Hillick Aug 21 '12 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 '12 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 '12 at 8:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.