I was looking around for a way to harden a fresh install of centos 5.4, and I came across this:

http://74.125.155.132/search?q=cache...ient=firefox-a

Is there any obvious flaws that should keep me from using it on a new install?

Hi There,

There are plenty of better sources out there e.g

http://www.nsa.gov/ia/_files/factshe...phlet-i731.pdf

I wouldn't trust the script you have mentioned. It's not that great. I would recommned you spending some time looking around more. There is alot of basic steps missing from that script and its actions are questionable.

Is this for home or the office, as your security poilicy might list the requirements.

1 members found this post helpful.

FragInHell you're right. I've looked at the source you provided, and even that is missing a lot. E.g. denyhosts/fail2ban isn't mentioned anywhere. Also, it doesn't suggest that ssh port be changed from the default 22.

Like you said, the ultimate solution is to look around and extract bits from each guide.

Take what you need from each guide to create your own policy hardening rules. Also keep to trusted sources as much as possible.
This is what I have mainly in mine, hope that helps some. I dont have fail2ban/custom firewall rules. Let me know if you find anything useful!

# 2 User Policy

* 2.1 Type of Access
* 2.2 Monitoring of Access.
* 2.3 Password Policy
* 2.4 Action: Enable Password Aging and length.
* 2.5 Action: Enable Strong Passwords.
* 2.6 Action: Enable Password History.

# 3 Administration

* 3.1 Availability of Access
* 3.2 Type Of Access
* 3.3 Monitoring of Access
* 3.4 Root Password Policy
* 3.5 Use of Root
* 3.6 Action: Set Default timeout for Sudo
* 3.7 Action: Alerts for bad password / invalid user account / invalid hosts / no permissions for Sudo

# 4 Physical Access.

* 4.1 Action: Case Lock.
* 4.2 Action: Security Lock.
* 4.3 Action: System BIOS Password.
* 4.4 Action: Disable CTL + ALT + DEL
* 4.5 Action: Enable Shell Timeout.
* 4.6 Action: Boot Loader Password.

# 5 Reporting / Monitoring

* 5.1 Action: Search for Compliers
* 5.2 Action: Check password file for all accounts with UID 0
* 5.3 Action: Enable Process Accounting.
* 5.4 Action: Report Using Process Accounting.
* 5.5 Action : Enable Audit Daemon Process
* 5.6 Action : Setup Watch flags on all /etc files

# 6 File System Access

* 6.1 Action: Disable Execution bit in /tmp
* 6.2 Action: set /tmp as its own filesystem
* 6.3 Action: World-Writable Directories Should Have Their Sticky Bit Set
* 6.4 Action: Find Unauthorized World-Writable Files
* 6.5 Action: Un-authorized SUID/SGID System Executables
* 6.6 Action: Files with no owner

# 7 System Core Dumps

* 7.1 Action: Check for Crash Dump Files.
* 7.2 Action: Setup Crash Dumps to use /tmp only

# 8 SELINUX

* 8.1 Action: Enable Security Environment Linux

# 9 RootKit Detectors

* 9.1 Action: Root kit Hunter
* 9.2 Action: Searches for known root kits. using chkrootkit

# 10 Network Services

* 10.1 Action: Disable IPv6
* 10.2 Action: Enable Advanced TCP security
* 10.3 Action: Custom Banner
* 10.4 Action: Enable Basic Firewall (IPTABLES)
* 10.5 Action: Allow SSH Protocol 2 only
* 10.6 Action: Disable Root Login
* 10.7 Action: Display Login Banner
* 10.8 Action: Setup Logging
* 10.9 Action: Setup Strict Mode
* 10.10 Action: Allow X forwarding
* 10.11 Action: Cups is installed by default with SAMBA - disable
* 10.12 Action: NFSv4 Secure Sharing to Host Name/IP only
* 10.13 Action: Disables Anonymous FTP on vfstd
* 10.14 Action: Displays Login Banner on vfstd
* 10.15 Action: Chroot’s users on vfstd

# 11 Scheduling Services

* 11.1 Action: Locks Cron to system Accounts only
* 11.2 Action: Locks AT to system accounts

1 members found this post helpful.

brilliant list, but could you say a bit more about that item; I would have expected 'disable weak passwords' or 'detect weak passwords and disable user account' or something rather than action to enable strong passwords.

and

do you specifically de-install rootkit detectors and password strength indicators (you know who I mean) between applications, which seems like the 'safety-first' approach?

2.5 - Well you can't really disable weak passwords, since a root user can set any password. The only way to check that of course is to take a copy of the password and shadow files and try and crack them, but this is time consuming process. There's other issues as such running/install these tools, or moving password/shadow files around etc, introduce other issues in its own right.
Instead I use PAM to enforce a mixture of upper/lower case, numbers and special characters that must be set in order to try and create a stronger password. Also to remember the x many previous passwords.

9 - So tools like rkhunter and chkrootkit/ tripwire etc are installed from first build to help keep some confidence in the system. Its easy to trust one tool too much I use a combination of these to get the "big picture" if you like.

With pam_passwdqc(8), you can optionally force root to comply with the password strength policies. Of course, root can change PAM's configuration, but if you have a rogue sysadmin with root on the system, you have bigger problems.

Also, on systems I've inherited, if I had questions about password strength I have simply forced a one-time password change using chage(1). When changing passwords, the users' selections were run through pam_passwdqc's requirements.

FragInHell - i'm looking at using auditd slightly more extensively (ie beyond RHEL 5.x default configuration). I noticed you say you put watch flags in. Any chance you have a link for something that covers it in more detail (sensible example wise)?

My reading of the manpage has resulted in some decent stuff, but I'd love a second opinion before i start churning out useless rules .

Oh and while we're at it, how do you do items 11.x in your list? I haven't looked at it at all ... though i'll do some googling now

I use auditd to watch everything in /etc. This way I can tie down users that have sudo access login and change system files (for example DBA's! ) This guide got me started. I have a script that basically adds a set of watch rules to everything in /etc
http://www.cyberciti.biz/tips/linux-...to-a-file.html

11 - /etc/cron.allow and /etc/cron.deny. The same for AT.

1 members found this post helpful.

cron - of course ... duh

Thanks for the link on auditd.

How vulnerable am I, if I turn SELinux off?

There are certain applications that don't work well with it on, and I don't have the skills to write proper policies to give those apps the proper permissions.

Is selinux being off a deal breaker for a server online?

It depends on a variety of things:

Firstly, which mode are you running SELinux in?
If you are running Permissive, eg:
Then you really don't loose anything besides error messages that confuse some users. I once had a user call complaining SELinux is stopping their stuff from working and that i please turn it off, i told them that i couldn't turn it off because it isn't on. Permissive shows you what errors you would be getting but lets anything pass. Some see it as a tool to prototype your setup, but really, when you are running enforcing you will get "errors" and everything will be working just peachy.

So if you are getting this:
You are on, and it's on

Secondly, the policy you are using is also important, there are three main onces, targeted, strict and MLS?
Targeted is the default enabled one that comes with RHEL / CentOS, it is concerned with dealing with known services. So if you get Apache from the distro vendor it will work great, if you compile it yourself it may work, but odds are you will find something do, somethings don't - I haven't tried but i've heard horror stories. The problem is that the targeted policy knows about file locations. For instance if you run:

it tells you what the files in certain locations will be set to. Now it's been a while since i read the doco, but it depends how the file is put in these locations and so things can go funky real quick. A copy is different to a move (as intuitive as it sounds, it will throw you at times) :
Point is targeted can only help you IF you are running all vendor services that are all SELinux enabled. For the longest time (and i don't know if they've fixed it now) Red Hat Cluster Suite was not SE Linux compliant ... so the surviving node couldn't take over a resource because the malfunctioning node's service didn't have the authority to give the resource up. Fencing also didn't help ... in short if you mix the two, make sure you do plenty of testing.

If you aren't running services that are SELinux aware (or really, that SELinux isn't aware off) you either need to write your own policy (not as hard as it sounds, at least to get working ... getting it right can be an art). Because: if apache on a trageted policy gets compromised you're fine (relatively) apache is confined to its own thing so it can't disable your mysql (of course the attacker can get creative). If however you are NOT running Apache that complies with the policy, the service will run as "unconfined" much like any other user:
So if the unconfined apache is compromised you have a rogue user, which is where all the neat DOS things come into effect about unprivileged users elevating their privilege and being targeted only known services are targeted and users are not.

MLS on the other hand is concerned with targeting users (more so than processes). I forget what the exact effect of the policy is ... though from memory X doesn't work anymore (though that could be the strict policy only ... from memory its MLS and strict), lord knows why you'd have X running on your server. MLS adds sensitivity and classification fields to files (processes etc) and thus has a hierarchy of read / write access , which breaks down into "read down, write up" look up "Bell-LaPadula Model"...

Lastly, strict - it's harsh, but pretty awesome. Everything is confined, it's the paranoid's paradise. A lot more involved to setup - suddenly root is no longer all powerful (MLS doesn't necessarily have that issue ... it's more flexible still, though again i haven't played with MLS a great deal).

So does it matter if you turn SELinux off? Maybe - if you are running a stock standard system running only vendor supplied packages (ie everything goes where the policy thinks it should be) then disabling it has an impact. Enforcing Targeted vs disabled or permissive means you are hypothetically vulnerable: there will always be another security bug in a service. Your firewall doesn't stop people accessing your service ... it merely reduces the number of threats (though that is debatable). Your application level configuration can only do so much (same with tcpwrappers) fact is outsiders will access the service because that's why you enabled the service. SELinux means if an attacker compromises the service they can't wreak too much havoc though they can still do plenty of harm. They can likely delete files, corrupt data etc, but only the data relevant to your service, because that is the context SELinux enforces on them.

All the layers of security you have: network firewall, on-host firewall, tcpwrappers, application configuration are null and void if you have an unpatched service (and like i said, odds even if it's patched there is something). SELinux is like the difference between the windows and unix discretionary access controls - in windows most people run as admin, so they can delete anything. If they are just a "user" then they can destroy their own stuff. SELinux is the same thing but takes it one step further - they can destroy their own stuff, but only if they are allowed to. That's not to say you can't compromise your SELinux policy by giving a service user access to `rm -rf /valuable/data`.

As a desktop user it shouldn't make a lot of difference ... but it all depends on your overall hardening of your system. Of course this assumes you're not hosting services on your desktop ... if there's nothing to compromise SELinux won't do much for you (although ... it can ... it all depends )

2 members found this post helpful.

Selinux is a tricky beast, there are a number of tools you can also used from permissive mode to create policies with, get information etc, for example SETtroubleShoot helps look at Selinux messages.
https://fedorahosted.org/setroublesh...t%20User%20FAQ
I guess the point is when do you use SElinux. We have a large number of Oracle Servers, for this SElinux is disabled, they are on the application network and are considered in a "safe" zone.
Where it pay off is on systems that run risk type services where the standard polices have already been created, DNS / DHCP / Apache / FTP etc. SElinux adds yet another layer of protection for these servers that sit in a DMZ or high risk network.

Thanks all for your enlightening answers.

chakkerz, how did you learn selinux? Did you take classes, or did you read a book/tutorial?

I understand the selinux package interferes with vpopmail and vqadmin's abilitiy to function correctly. So it's recommended to turn off selinux.

Is it possible to write selinux policies for programs like vpopmail, vqadmin? Or do they have to be selinux compliant first?

Two things:
SELinux by example is excellent at teaching you how SELinux works, but it's not very practical - see
http://www.amazon.com/SELinux-Exampl...1526463&sr=8-1

I wrote the three star review on there, so that give you more info about my take on it.

Secondly, the RHS429 course "Red Hat Enterprise SELinux Policy Administration" (offered by Red Hat) is excellent. It is very practical and prepares you very well for using it, it benefited a lot from me having read the other book two weeks prior.

The final thing that really helps (and sadly i haven't had enough of this) is using it. I consulted for AusCERT and have a few servers running it (surprisingly smoothly). And a few that aren't running it because they have services on them that were not built with SELinux in mind :S . SELinux works best on a system that's using it from the start, retrofitting it ... is problematic.

1 members found this post helpful.