Would GrSecurity be useful on a Debian based firewall ?

[evilangel]

Hi all,

At the entry point of my network, I am using a Debian server as a firewall.
It contains a Debian base system, plus OpenSSH.

Becasue of its critical location on the network, and the recent flaw in Debain's OpenSSL, i would like to harden the server.

Would GrSecurity be useful on my firewall in this case ?

Thanks

[cormander]

The useful portion of grsecurity in your case specifically would be the RBAC system. You'd specify access controls to state who can do what ... if all you ever do is login and make changes to the firewall, not running any automated crons or anything, use a small policy (very strict) and whenever you login, authenticate to the admin and make your changes.

This way if someone gets access to the system w/ a broken key, they still need a password to do anything harmful.

[evilangel]

Hi,

Even if it is a minimal system, I still have cron jobs everyday: rotation of logs (especially firewall), autoupdate of the packages....
I was more thinking of the hardening of the TCP/IP stack, and of the randomization of memory space to avoid any buffer overflow.

I can do this without setting up an RBAC policy, no ?

[cormander]

AFAIK the TCP/IP stack hardening was removed from grsecurity because recent kernels sufficiently harden them... see here for details:

viewtopic.php?f=3&t=1950&p=7925&hilit=sufficient#p7925

You can use the gradm tool to enable learning to setup policies for the log rotation and it isn't very difficult to do. As far as the automated update of packages ... I generally have my systems setup to email me when there are updates, and I apply them manually.

The buffer overflock protections (from PaX) are great, and you don't need the RBAC system for them, but if you're not using any userspace tools (other then, say, sshd) then this isn't going to do you very much good. It's best application is when used on servers with many services and daemons running, where people can potentially remotely exploit things such as mail servers, web servers, php/cgi scripts running on webservers, etc, but I'm not saying to not use it.

If you're using iptables as your firewall (which doesn't run in userspace, to my knowledge) then PaX isn't going to do you any good here unless you have the kernel address space randomization option enabled. So make sure you enable that when you build your kernel.

Hope this helps.

[evilangel]

Thanks for this quick answer.

Effectively, it seems that recent kernels are hardened enough on the networking point of view, which was important for me.
You are right also on the point that I don't use a lot of userland applications (SSHD, exim and some cron jobs).

So the main point would be settting up RBAC.
So, finally, do I really need GrSecurity ?
I mean, is there a way to enable RBAC without patching the kernel ?

Thanks

[cormander]

The RBAC system is specific to grsecurity. There are other similar programs, such as SELinux, and SMACK (if you use a recent kernel), or apparmor (if you use suse linux). Though running exim is a good enough reason (for me) to use grsecurity because it's an application that listens on the network and is a possible entry point.

[evilangel]

Though running exim is a good enough reason (for me) to use grsecurity because it's an application that listens on the network and is a possible entry point.

By saying this, you mean it is a good reason to need PaX ? To run RBAC ? ... Because, as you said, hardening TCP/IP stack is not necessary on recent kernels. So which part of GrSecurity would be interesting in such a case ?

Thanks

[cormander]

In the case of your server:

1) PaX

* will protect against possible remote exploits to sshd and exim
* will protect against possible remote iptables exploitation

2) grsecurity

* if all the proper options are set - kernel rootkits become almost impossible
* if you run exim in a chroot - successful remote exploitation of exim will still contain the hacker, even if they become the root user, they can't break out of the chroot (assuming you enabled the chroot hardening)

3) RBAC system of grsecurity

* this is your last set of defenses - if your root user does get compromised, they still only have the access you give them in the default root role w/o a password.

[evilangel]

Thanks for all these usefull information.

About PaX, is it the only tool adding memory randomisation against remote exploit ?

In fact, this question because, I find all these features really interesting (randomisation, chroot hardening, RBAC/MAC...). But I try to find a scalable way to install them.

GrSecurity need me to recompile every kernel.
As SELinux or SMACK is already present in my Debian kernels i was thinking of using it. However, it depends if I am able to reach an equivalent level of security or not.

At the moment, I have the feeling that patching with GrSecurity will provide me more than using the embedded tool.

[cormander]

Thanks for all these usefull information.

About PaX, is it the only tool adding memory randomisation against remote exploit ?

Some of the randomization is done outside PaX, for example:

CONFIG_GRKERNSEC_RANDNET gives "larger entropy pools" for additional randomness.
CONFIG_GRKERNSEC_BRUTE stops exploits that try to "guess" address space memory by detering the parent processes of children killed by PaX - a good example of how well grsecurity and PaX works together.
CONFIG_GRKERNSEC_KMEM isn't randomness but it protects kernel memory, and when combind with the right options, makes kernel rootkits practically impossible.

I may be missing something else.

In fact, this question because, I find all these features really interesting (randomisation, chroot hardening, RBAC/MAC...). But I try to find a scalable way to install them.

GrSecurity need me to recompile every kernel.

I've got some pre-compiled grsecurity kernels here:

http://www.ravencore.com/grsec/

You said you're using debian, but you can always either use alien to install them, or simply unpack them with the "rpm2cpio" utility and extract the resulting cpio archive on the / of your server.

Don't forget to run your mkinitrd utilities and update your bootloader manually if you do this.

As SELinux or SMACK is already present in my Debian kernels i was thinking of using it. However, it depends if I am able to reach an equivalent level of security or not.

SELinux and SMACK are MAC utils only, they don't do any other form of kernel hardening; you won't get anywhere near the level of security with them vs using grsecurity. What I've seen some people do is use SELinux and PaX (no grsecurity) but you still have to patch your kernel .... but SELinux is available in my kernel-pax rpm, but you lose out on some of the grsecurity -> PaX interoperability which is always nice to have.

[evilangel]

OK. I got it.
In the spirit, GrSecurity is hardening kernel to avoid compromission, where SElinux sounds more into limiting actions of a compromised host.

My aim is really to harden kernel, so I see now which solution to take.

A stupid question: where can I find the documentation of GrSecurity , as:

CONFIG_GRKERNSEC_RANDNET gives "larger entropy pools" for additional randomness.
CONFIG_GRKERNSEC_BRUTE stops exploits that try to "guess" address space memory by detering the parent processes of children killed by PaX - a good example of how well grsecurity and PaX works together.
CONFIG_GRKERNSEC_KMEM isn't randomness but it protects kernel memory, and when combind with the right options, makes kernel rootkits practically impossible.

telling me what each option is doing ?

Many thanks

[cormander]

After you download the linux kernel and patch it with grsecurity, do a "make menuconfig" and go to:

Security options -> Grsecurity

PaX options are here:

Security options -> PaX

On each option, you can select the < Help > option and it'll give the details on what that specific option does.

[evilangel]

Many thanks