# Ideal Security Solution.

## JohnerH

Good Afternoon All,

Here's my idea, I have an old Dual PII 400 server with more then enough RAM and Ethernet cards to make a pretty good and decent router/dns/mail/firewall server.

Now here's where I hit the wall.

To start off when it comes to security I'm a utter noob, at the moment I have a belkin router doing all my routing and firewalling.

Although the thing is good I'd like to further enhance my knowledge in this field and thereby transforming this old piece of hardware into something useful again... 

I believe I have more then enough space to accommodate all of this, having around 80gb of disk.

Now what's the easiest way to go about the security? Do I dive in completely in to SELinux like I have? It's just I'm finding it hard to understand it's concepts, or better yet I'm having trouble finding good noobs references to it.

My bigger aim will be to become proficient in all things with security but I'd like to know how to go about this....

So, SELinux? Pax/GRSecurity? RSBAC?

All of em' together?

How to go about it? How to install it ?

I'm sorry to be a pain and I'd like to thank anyone in advance for any help on this,

J

----------

## desultory

 *JohnerH wrote:*   

> Now what's the easiest way to go about the security? Do I dive in completely in to SELinux like I have? It's just I'm finding it hard to understand it's concepts, or better yet I'm having trouble finding good noobs references to it.
> 
> My bigger aim will be to become proficient in all things with security but I'd like to know how to go about this....

 Even if you decide to actually secure the system in some other way, I suggest that you emerge -av app-admin/bastille and read through all of the prompts and explanations it given when you run bastille.

 *JohnerH wrote:*   

> I'm sorry to be a pain and I'd like to thank anyone in advance for any help on this,

 Better now than after the system has been compromised.

----------

## depontius

What kinds of changes does Bastille actually do to your system. Letting some program muck with my system as root kind of scares me. I'd really feel safer if it gave me an audit list, and then let me make the changes, and re-run the audit.

----------

## Jeremy_Z

Was it not for "educational" purposes i would suggest another distro such as Engarde, but that would save too many hours of fun.

There are some documentation on gentoo (surprise surprise http://www.gentoo.org/proj/en/hardened/ ), check for gentoo hardened. This is much easier when you consider at before installation so you can make a clean install and tackle issues one at a time.

Once you get your hardened PaX PIE SSP Pepperoni gentoo system, you still have to choose grsecurity, RSBAC or SELinux.

On that i would say that SELinux is maybe more supported and not that difficult to customize.

----------

## JohnerH

 *Jeremy_Z wrote:*   

> Was it not for "educational" purposes i would suggest another distro such as Engarde, but that would save too many hours of fun.
> 
> There are some documentation on gentoo (surprise surprise http://www.gentoo.org/proj/en/hardened/ ), check for gentoo hardened. This is much easier when you consider at before installation so you can make a clean install and tackle issues one at a time.
> 
> Once you get your hardened PaX PIE SSP Pepperoni gentoo system, you still have to choose grsecurity, RSBAC or SELinux.
> ...

 

Yeah, I definitely want be a hardcore gentooer... After all, all I know of linux is because of gentoo, so I wouldn't be fair to myself to defect it for an "easier" option.

I did in fact try and install SElinux first time around (yes I have tried to do this more then once now) but I didn't do it after the  "PaX PIE SSP" install. I did get stock pretty much after booting it for the first time. The whole policy thing and the fact I had to alter so many files ended up with me ultimately borking up my system even before I started it. 

The thing is I not only have I to install the security but I have to look in to things like BIND (I have a network at home) and iptables (or ipchains?). I did try and follow the gentoo hardened project and although they make a really good decent attempt to describe everything when it boils down to noobers like myself I still didn't get the concepts.

Hence, my post...

So in your opinion, I would have to go on the lines of,

Stage 1 + 2 with hardened/Selinux profile, then get PAX PIE SSP and then tackle SELinux?

Is that the best way? If so, anyone know of any docs out there for people like me?

Again thank you....

----------

## Jeremy_Z

Yes. 

From my understanding you basically need PAX and SELinux in the kernel, and PIE/SSP comes from the hardened profile. For stage i do not know what is available for hardened, you could convert a normal stage 2/3 to hardened, but you will still need to recompile everything so that would just be like a stage1 (timewise).

And at this point you do not want SELinux in enforcing mode.

Once you get the base system with no glitch of either Pax or SELinux, you can install the server application and their SELinux policies one by one.

----------

## desultory

 *depontius wrote:*   

> What kinds of changes does Bastille actually do to your system.

 Unless changes are approved, bastille does not change the system configuration. If changes are allowed, bastille can (among other things) set file permissions (such as restricting potentially unsafe programs from being run by users which are insufficiently trusted), configure packet filtering (using iptables or ipchains) and configure logging of security related events (both local and those encountered by the packet filter). Again, bastille is valuable not only as a tool to configure a system but also as a tool to educate its users about how to do so themselves.

 *depontius wrote:*   

> Letting some program muck with my system as root kind of scares me.

 In general, that is entirely justified.

 *depontius wrote:*   

> I'd really feel safer if it gave me an audit list, and then let me make the changes, and re-run the audit.

 I have not used bastille to audit existing security measures. For file permissions and the like it should be usable; for more complex systems such as logging and packet filtering, I can only suggest trying  and reporting back your results. If you want security audits for externally exposed network interfaces, as a basic audit, I suggest that you try "ShieldsUP!" at http://www.grc.com/ which performs a port scan from the internet side of your connection and reports on the state of each scanned port.

----------

## casso

I think by audit, depontius meant that bastille should return a list of possible changes it would make, much like a dry run.

I would suggest taking a totally different approach with your security. First of all, start with good, solid IP Level filtering using iptables. This will keep you occupied for at least two days when you're new to it all. After this, move on to another part of system security you wish to tackle. Choose "safe" daemons to install if you can. Daemons that don't run as root are a good choice. Ones that do should (if possible) be contained in a chroot environment.

Build your software hardened and pic enabled, which is easy with USE flags and a build from stage1 in the beginning. I would suggest to save yourself a headache that you leve SELinux, GRSecurity or RSBAC to last, or at least until you have got a fair bit done with your system. My concern would be that you have no idea why a program is working only to find that all your configuration options are correct (and you spent 9hrs checking) but that SELinux blocked something and you weren't expecting it.

Security can be a double edged sword. Just like you I want a system that is build around the idea that everything is as secure as I can forsee, and still practical. I don't want to enter 40 passwords in a normal session. I don't want a system that seems to need more maintainence that I could have ever imagined. I do want a system that supports SSO and does lost of things for me, but still is secure.

Anyone else using cryptsetup on ALL their hardisks?

----------

## depontius

 *casso wrote:*   

> I think by audit, depontius meant that bastille should return a list of possible changes it would make, much like a dry run.

 

Precisely, though if Bastille doesn't actually change anything without approval, I guess that could be an annoying audit.

 *casso wrote:*   

> I would suggest taking a totally different approach with your security. First of all, start with good, solid IP Level filtering using iptables. This will keep you occupied for at least two days when you're new to it all. After this, move on to another part of system security you wish to tackle. Choose "safe" daemons to install if you can. Daemons that don't run as root are a good choice. Ones that do should (if possible) be contained in a chroot environment.

 

Already done, on most counts. This system is also behind a router appliance. (not a base-level NAT-only router, either) Of course you've just highlighted the conundrum. Without mods, root can't be kept in a chroot, whereas ordinary users can.

 *casso wrote:*   

> Build your software hardened and pic enabled, which is easy with USE flags and a build from stage1 in the beginning. I would suggest to save yourself a headache that you leve SELinux, GRSecurity or RSBAC to last, or at least until you have got a fair bit done with your system. My concern would be that you have no idea why a program is working only to find that all your configuration options are correct (and you spent 9hrs checking) but that SELinux blocked something and you weren't expecting it.

 

This system was built hardened with SELinux. But there are no SELinux policies for Dovecot (imap) or Leafnode (nntp) so I've had to turn it off. The Targeted Policy has been coming since I set the thing up, which is why I started down this road with 2 daemons lacking policies, but still isn't here. So at this point I'm thinking of bailing for GRSecurity, but time-permitted may delay it until Targeted is here. I'm also considering other ideas like embedding. I'm just glad the system really isn't exposed, but more of a learning vehicle.

 *casso wrote:*   

> Security can be a double edged sword. Just like you I want a system that is build around the idea that everything is as secure as I can forsee, and still practical. I don't want to enter 40 passwords in a normal session. I don't want a system that seems to need more maintainence that I could have ever imagined. I do want a system that supports SSO and does lost of things for me, but still is secure.

 

I've flailed against OpenLDAP/SASL/Kerberos several times, and never really had time to learn how to make it all work. It ain't cookbook, even though there are several cookbook attempts out there. Besides, by the time a cookbook is written and put on the web, much of the software is back-level.

 *casso wrote:*   

> Anyone else using cryptsetup on ALL their hardisks?

 

Can you point me to some decent cryptsetup directions? A few months back I encrypted stuff containers on a memory key, and I've lost my directions. Is cryptsetup-LUKS compatible with cryptsetup? A bit back I was forced to change by a dependency issue.

----------

## Jeremy_Z

The point of starting with SELinux is that you can make it "learn". There are script like audit2policy to generate policies based on log messages generated by SELinux in audit mode.

This is not so hard to do, but easier if youtackle them one by one.

----------

## casso

Im glad you have managed to come so far already depontius.

A HOWTO for cryptsetup may be rather difficult to find. Another user asked me if I would be interested in writing a HOWTO on the wiki, but that flopped. I started at the LUKS Website for information on cryptsetup. I found cryptsetup-luks easy to use, although I haven't used plain cryptsetup yet. I can give you some simple directions for setting up cryptsetup-luks devices, but I would prefer to make another post so that other users may find it easier. cryptsetup-luks really is quite simple to configure and once you have it working, you shouldn't have any trouble.

I noticed you tried using LDAP+Kerberos on your network. I too have tried and managed to succeed in getting my users authenticated with Kerberos at logon, and using LDAP for a username/group backend (replaces /etc/passwd and /etc/group). Should you want help on either of these, I can again help you out. My knowledge of LDAP is not huge, but it is sufficient to get you up and running for just these sections.

I need LDAP also for Samba. The idea (eventually) is that regardless of whether the computer youi are using is Linux or Windows, your profile will be stored on a network drive under Samba, and authentication will either be via Kerberos (Linux) or NTLM/NTLMv2 (Windows). All LDAP connections should be secured via TLS, and all network connections should be secured via IPSec using X.509 certificates. That is a long way off, but hopefully I will get there.

While we are talking security, the place where my security is weakest is when using my proxy server. I know that you can use digest authentication rather than the basic authentication I am using. Has anyone got this going? I noticed somewhere on mozilla.org that firefox may have support for Kerberos authentication. Has anyone else heard of this? Any way of securing CUPS with Kerberos (not through PAM)?

----------

## Jeremy_Z

Kerberos i something i also wanted to look into, for Linux AND windows auth.

Please feel free to write some on the WIKI.

----------

## ali3nx

pax/grsec has my vote of complete confidence. SElinux does have good rbac but does not stop kernel based exploits

```
mail ~ # paxtest blackhat

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>

Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log

It may take a while for the tests to complete

Test results:

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>

Released under the GNU Public Licence version 2 or later

Mode: blackhat

Linux mail 2.6.16-hardened-r4 #1 SMP Thu Apr 27 16:43:55 PDT 2006 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

Executable anonymous mapping             : Killed

Executable bss                           : Killed

Executable data                          : Killed

Executable heap                          : Killed

Executable stack                         : Killed

Executable anonymous mapping (mprotect)  : Killed

Executable bss (mprotect)                : Killed

Executable data (mprotect)               : Killed

Executable heap (mprotect)               : Killed

Executable stack (mprotect)              : Killed

Executable shared library bss (mprotect) : Killed

Executable shared library data (mprotect): Killed

Writable text segments                   : Killed

Anonymous mapping randomisation test     : 33 bits (guessed)

Heap randomisation test (ET_EXEC)        : 40 bits (guessed)

Heap randomisation test (ET_DYN)         : 40 bits (guessed)

Main executable randomisation (ET_EXEC)  : 33 bits (guessed)

Main executable randomisation (ET_DYN)   : 33 bits (guessed)

Shared library randomisation test        : 33 bits (guessed)

Stack randomisation test (SEGMEXEC)      : No randomisation

Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)

Return to function (strcpy)              : Killed

Return to function (memcpy)              : Killed

Return to function (strcpy, RANDEXEC)    : Killed

Return to function (memcpy, RANDEXEC)    : Killed

Executable shared library bss            : Killed

Executable shared library data           : Killed

mail ~ # uptime

 19:51:17 up 264 days, 11:29,  3 users,  load average: 0.22, 0.22, 0.19

mail ~ # uname -a

Linux mail 2.6.16-hardened-r4 #1 SMP Thu Apr 27 16:43:55 PDT 2006 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux
```

----------

## Jeremy_Z

What you mean ? grsec stops kernel exploits ?

What is your experience with grsec ? supported server applications, customizing policies, etc ...

----------

## ali3nx

 *Jeremy_Z wrote:*   

> What you mean ? grsec stops kernel exploits ?
> 
> What is your experience with grsec ? supported server applications, customizing policies, etc ...

 

I try to use grsecurity with hardened gentoo on any production server I can either on a hostile network or a secured isolated vlan because when configured correctly the system virtually bulletproof. Most common forms of exploits used to compromise services found on wan networks are impossible. Some examples are stated in my previous post with the paxtest log. The wikipedia article on pax explains the benefits of pax in great detail. As a systems engineer and consultant I need to roll out reliable systems that will be there tomorrow and hardened gentoo sporting a correctly configured grsecurity setup will do just that. Database servers, web services, mission critical mailserver, trusted system for a network edge router on an unsecure network such as what your looking to achieve.... Whatever the purpose happens to be. I built a cs:s game server hosting provider in stockholm sweden using all 64bit hardened gentoo across ten servers and not one was compromised. Actually in four years only one hardened system running SElinux was compromised through the recent cacti vulnerability however due to grsecurity's audit logging that we added additionally on top of SElinux we had a full audit trace for every command the uninvited guests typed with ip addresses. The uninvited guest might get in every other solar eclipse but they will leave a full audit trail behind. It's more interesting to mention that because of pax's exploit prevention methods the attacker could not get past /var/tmp (drwx-rwx-rwx) and compromise the machine any further. Every known exploit attempt in the blackhat handbook this group managed to find left an execution log and the notice in grsec.log just how much more they could try and certainly fail   :Wink: 

----------

## ali3nx

 *Jeremy_Z wrote:*   

> Yes. 
> 
> From my understanding you basically need PAX and SELinux in the kernel, and PIE/SSP comes from the hardened profile. For stage i do not know what is available for hardened, you could convert a normal stage 2/3 to hardened, but you will still need to recompile everything so that would just be like a stage1 (timewise).
> 
> And at this point you do not want SELinux in enforcing mode.
> ...

 

With the current issues concerning gcc-4 and glibc-2.4+ not supporting ssp you MUST start building from 2006.0 stages to build a proper hardened gentoo userland. The x86 hardened stages are recommended but only ship with i386 chosts and changing the chost on a hardened server is both a major PITA and can break thread safe sanity of the toolchain. I highly advise starting with an i686 2006.0 stage3 then switching the profile to hardened if you have an x86 based system after which bootstrap and recompile the entire server. There are a few limitations to using i386 with hardened systems such as memory limitations that were made public on the well known nmap full disclosure security forums. I wish I could find the url for the advisory and explaination which I think was a comparison of win32 stackguard, openbsd's w^x and grsecurity.

----------

## JohnerH

Ok then, I got the server up and running with a hardened, SELinux profile, I installed SELinux but now I'm lost in the never ending labyrinth of config files. 

I tried to follow the guide from the hardened team but eventually got lost and now I don't think it's even working...

Can anyone shed some light as to how I'd go about getting it up and running...

BTW, I haven't done the PAX/PIE/PSS on the kernel, because to be honest I don't know how...

help?

J

----------

## depontius

 *ali3nx wrote:*   

> With the current issues concerning gcc-4 and glibc-2.4+ not supporting ssp you MUST start building from 2006.0 stages to build a proper hardened gentoo userland. The x86 hardened stages are recommended but only ship with i386 chosts and changing the chost on a hardened server is both a major PITA and can break thread safe sanity of the toolchain. I highly advise starting with an i686 2006.0 stage3 then switching the profile to hardened if you have an x86 based system after which bootstrap and recompile the entire server. There are a few limitations to using i386 with hardened systems such as memory limitations that were made public on the well known nmap full disclosure security forums. I wish I could find the url for the advisory and explaination which I think was a comparison of win32 stackguard, openbsd's w^x and grsecurity.

 

Now I read this post. I just finished building a new install. I started from the 2006.0 x86 hardened stage 3 tarball, followed the official Gentoo instructions for changing CHOST, and then went onward to "emerge system" and emerge  the stuff I wanted. Since I did the CHOST change the "right way" so early in the process, is there any reason to think I have things wrong here, or any way to check? This install is currently in a chroot-32 on an amd64 system, and finished compilation this morning. I just need to build a kernel, tweak the stuff in /etc, and wrap it all up in a "stage-4" tarball, and it'll be ready to drop on a freshly partitioned (slow) server, run grub, and go.

----------

## Xoalin

 *Jeremy_Z wrote:*   

> What you mean ? grsec stops kernel exploits ?
> 
> What is your experience with grsec ? supported server applications, customizing policies, etc ...

 

grsec has PAX and when combined with compiling everything with PIE/SSP blocks a lot of memory (kernel included) based exploits/attacks. PAX is designed as a preventive measure in blocking exploits in the kernel, userland app exploits, etc. PAX can force loading of applications randomly (even non-PIE/PIC) to make their code difficult to target, disallowing dynamically allocated memory to be executable, enforcing/disallowing exec permissions upon memory, etc, etc. Check the docs for better info ;) 

PIE/SSP are GCC compiling patches for <=gcc-3.4.6 I think... However PIE creates position independent executables, so they load randomly and are more difficult to target vulnerable regions. SSP offers protection against some memory attacks/exploits. IF a buffer is over run, the app is killed. You can write a simple C app that will over flow a buffer to test if you want ;) 

As for support, any precompiled binaries will need to have PAX settings adjusted for them in order to avoid having PAX kill it. And they will probably lack SSP/PIE and various PAX protections. Some apps may be killed if they have some bugs that over write buffers for instance, but you want them to be killed ;) 

grsec offers various kernel patches to prevent exploits, hardening of chroots, more auditing options, restricting kernel info/access (preventing access to potential access to exploits), restricting system info, etc, etc. Grsec kernel patches are good EVEN if you don't want the rbac. 

Both grsec and rsbac have pax and a learning modes for their rbac options. Now I have no idea how the various implementations compare against one another since I've never used the SElinux or rsbac.

----------

## Jeremy_Z

 *Xoalin wrote:*   

> 
> 
> grsec offers various kernel patches to prevent exploits, hardening of chroots, more auditing options, restricting kernel info/access (preventing access to potential access to exploits), restricting system info, etc, etc. Grsec kernel patches are good EVEN if you don't want the rbac. 

 

Thanks that was what i wanted to know, so grsec can be used with selinux if we use selinux rbac with grsec "kernel hardening" patch ?

If you meant PAX as part of grsec, i already know that PAX SSP,PIE can be used zith SElinux.

----------

## Xoalin

No idea how well Gre and SElinux get along with one another.

Why SElinux and the security modules over rsbac and or gre without the security modules?

----------

## konqueror

 *ali3nx wrote:*   

> There are a few limitations to using i386 with hardened systems such as memory limitations that were made public on the well known nmap full disclosure security forums. I wish I could find the url for the advisory and explaination which I think was a comparison of win32 stackguard, openbsd's w^x and grsecurity.

 

if u do find the url and info again, could u pls post here as well? I would be interested to read about the comparison. And do the points only apply for using i386 as the CHOST? or (as i guess) is it more generic?

----------

## GNUtoo

i am interested in selinux...but i don't want to configure every application

i know there is a way to make policies only for some applications such as apache

i would like to make policies on at least openssh...in order to prevent acess on the ssh logs...(because of scp/sftp i need root login)

and is it possible to log all commands for openssh without sudo?

----------

