Admin Spotting for Fun and Profit

Hardening CentOS

July 9th, 2009 Posted in Linux

This is something that I’ve griped about in the past, but without taking action, griping is basically just annoying other people in an arrogant fashion. Now while I’m very good at doing this, I’d much rather do something to help people provide proper security for their systems.

To this end, I’ve started a page on the CentOS wiki (Hardening CentOS)  that will very likely turn into its own section in the future. This page uses Steve Grubb’s RHEL hardening guide, as well as the NSA’s RHEL 5 security guide as the basis for locking down the operating system in a reasonably secure fashion. I do not claim it to be all-powerful, nor will everything there apply to everyone in all instances. Take from it what you need to. What is covered on the page is the basis for locking down a system with very minimal impact to distribution standards or package changes. I’ll continue to add to this page, and break out other pages to encompass securing the distribution provided httpd, mysqld, etc as I get time.

If you find this information useful, please let me know. Comments and suggestions are warmly welcomed, so long as it’s constructive. As usual, the OMG-U-SUCK comments won’t get approved unless they’re accompanied by facts and/or evidence to support the opinion.

Once again, you can see this page at http://wiki.centos.org/HowTos/OS_Protection

  1. 14 Responses to “Hardening CentOS”

  2. By Corey Henderson on Jul 9, 2009

    If you’re going to be marking some environment variables as readonly, you might want to add this:

    echo “readonly HISTFILE” >> /etc/profile

  3. By Jim Perrin on Jul 10, 2009

    This is a good point, but as was brought up to me in irc, it may be better to do this in included files via /etc/profile.d rather than modifying the existing config. One of the tenants I wanted to stick to with this document was to minimize changes to do the distro while still providing security. Your suggestion is a good one, but I think yours (and mine) would be best placed in /etc/profile.d/security.sh or similar.

  4. By Corey Henderson on Jul 12, 2009

    In that case, replace it with this:

    echo “Idle users will be removed after 15 minutes”
    cat < /etc/profile.d/os-security.sh
    readonly TMOUT=900
    readonly HISTFILE
    EOF
    chmod +x /etc/profile.d/os-security.sh

    Anything else you want to make readonly need only be added to the list there, no more “echo” commands to append to the .sh file.

    Perhaps PATH should be added to the list? I know some users like to append stuff to their own PATH variable (such as ~/bin) but in a secure environment you really don’t want people executing their own binaries. This one is debatable.

    Maybe some other variables to include in the list are: HISTSIZE, SSH_CONNECTION, and SHELL

  5. By Corey Henderson on Jul 12, 2009

    Let me try that again, using HTML encoding:

    cat << EOF > /etc/profile.d/os-security.sh
    readonly TMOUT=900
    readonly HISTFILE
    EOF
    chmod +x /etc/profile.d/os-security.sh

  6. By AJay on Jul 13, 2009

    What about a section on limiting cron, by editing cron.allow? I was compromised a while ago and there was a script in /var/lib/cron.

  7. By Michae Fox on Jul 14, 2009

    Thanks for starting the wiki page on CentOS hardening. Just what the doctor ordered. Especially if contains up to date information.

  8. By irado on Jul 16, 2009

    there are some errors:

    #sysctl -p /etc/sysctl.conf

    error: “net.ipv4.icmp_ignore_bogus_error_messages” is an unknown key

    every key with ” redirects” keyword MUST have underscore and NOT spaces connecting the previous word and the “redirects” word.

    example:

    net.ipv4.conf.all.send redirects must be changed to:
    net.ipv4.conf.all.send_redirects

  9. By Aron Parsons on Jul 16, 2009

    Try this for PAM:

    # cd /etc/pam.d
    # cat < system-auth-local
    auth requisite pam_tally2.so unlock_time=900 onerr=fail no_magic_root
    auth include system-auth-ac

    account requisite pam_tally2.so
    account include system-auth-ac

    password include system-auth-ac

    session include system-auth-ac
    EOF

    # ln -sf system-auth-local system-auth

    This will keep authconfig from wiping out your changes in the future. Also, the pam_tally2 lines should be at the top of the auth/account sections.

  10. By Jim Perrin on Jul 16, 2009

    This is very doable. I even have a script to enumerate users and only allow root to use cron unless others are added

  11. By Ron Loftin on Jul 19, 2009

    I’ve been comparing what you suggest for system hardening with my approach, and I have a few observations about the section on modifying fstab.

    I definitely agree with limiting what the normal, unprivileged peasants can do.

    In your example, you seem to have overlooked the world-writable /dev/shm. I admit that I only noticed this recently myself, but I have made that “nodev,nosuid” along with the other places you note where the users have write access.

    Since CentOS uses udev, I give all filesystems, including root, the “nodev” options. As long as udev is doing all the device handling, I don’t seem to have any need for device files to be created on disk anywhere.

    It may be overkill, but on systems with a separate /boot filesystem, I make that “noauto” to protect the kernel. After all, the only time that /boot actually NEEDS to be mounted is during kernel installation/upgrade operations. Call me paranoid if you want. I don’t mind. ;>

    As a minor detail, my reading of the man page says that the “default” entry in the options field of fstab is unnecessary when specifying additional parameters there. It doesn’t hurt anything, and if you want it there in your example to remind the less-experienced admins that the defaults stay in place unless explicitly changed, I understand.

    Thanks for collecting this stuff in one place so folks can easily refer to it.

  12. By Amos on Jul 20, 2009

    Great work to start this page. I logged in but don’t see a way to add comments on the page so I’ll to it here:

    mod_security (available from EPEL) for http servers. Seems to be required by PCI DSS and friends.
    SE Linux – the best guide for it I found so far lives at http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/, I guess it’s close enough for CentOS 5 (could be added in an “additional resources” section).
    restricted shell – we are in a process which might end up with us using it (we hope to keep less trusted users off of our sensitive servers altogether) but it sounds like a must if you have to provide shell access.
    HISTTIMEFORMAT=’%F %T ‘ – will list (and save) history entries with timestamps, not sure how much this will help for security but maybe together with restricted shell (which can forbid change to shell variables as well as erasing of history file) you can get a VERY useful data set about what happened when, instead of a “flat list” of commands executed without a timestamp to correlate to.
    remote logging of shell commands – there are a few links I found to enable remote logging of shell commands – this way you can get a list of what a hacker did through a shell on your compromised server on a remote logging server. I’ve even heard of people who go all the way and use “screen” as their login shell, which can also log everything.

  13. By Jim Perrin on Jul 20, 2009

    As for mod_security, I absolutely agree that it should be used. The base page was strictly dealing with securing the OS though. I very briefly touched on ssh, though not to any real extent. I’ll be working on some application security pages later on. Thanks for your comments though!

  14. By JD on Jul 28, 2009

    Small correction to the iptables section – the default rules don’t open up ports 50 & 51. They open up _protocols_ 50 & 51 – IPSEC ESP & AH respectively.

    Also with regards to Sysctl options, another one to consider is :

    net.ipv4.tcp_timestamps = 0

    Makes OS detection ever so slightly harder and (probably) doesn’t break anything.

  15. By M Kobar on Aug 3, 2009

    Part of our humble SF project may be of interest:

    We have an appliance (Orange JeOS) builder for CentOS that has a sister sub-project that uses the NSA SNAC Security Guidelines via the automated NSA-lockdown tool.

    It is in its infant stage but is currently usable. Future directions include automatic app detection and a nice GUI.

    We have also compiled a detailed coverage table to show how much of the SNAC Guidelines our tool covers and how much requires manual intervention.

    Much of this security coverage is due to the limitation of packages installed and the modification of default configuration settings.

    More information on the NSA SNAC Lockdown tool can be found here:

    http://orangejeos.sourceforge.net/about-nsa-lockdown.html

    And the coverage table can be found here:

    http://orangejeos.sourceforge.net/nsa-coverage-matrix.html

    Always looking for any good ideas and feedback.

    Thanks for the CentOS Security page!

Post a Comment