/dev/null /var/Linux

I got asked what steps I would take beyond the mandatory “deny all but specific ports with iptables” which we have addressed in our previous iptables articles. Since I believe in information sharing, here is a quick cheat sheet, which will work on any Linux server. Don’t copy-paste however, you should understand first what you are doing.Note: some of these scripts or parts of them have been collected from online resources, such as the Gentoo Security handbook etc.

hardened linux

  1. If it is a Webserver, then the first step is to check that the DocumentRoot(s) are set correctly and have the permissions set correctly . You don’t want to have permission 777 on a public webdirectory.
  2. This also means you should check for worldreadable files and folders which are generally not wanted. To get lists of world writable directories just enter
    find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \;

    and for files:
    find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \;

    As with all the commands you can output via the >> redirect to a text file so you can read it later.
  3. Next step is to check the system for SETUID files.These files are programs that are executed as root automatically. You should have no such programs and if you do, you should get rid of them. To do that, just run a small find script such as:
    find / -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \;

    If you add a 2>/dev/null >suidfiles.txt at the end you can get them all listed in a text file which you can then parse or read.
  4. Review the /etc/passwd and the /etc/group files to see if you recognize anything suspicious or if you can account for all usernames and groups memberships.
  5. Check if Apache , Bind or any other services are indeed running with a non-privledged user. And if they are running chrooted. Chroot is a good practise though sometimes it is not as hard as it may look to break out of the chroot.
  6. Verify that your sshd_config indeed has AllowRootLogin set to NO. You should never log in with root remotely, always use su or sudo.
  7. Check what services are really needed and turn the rest off. For example, why does a server need a GUI running? If you run VMWare server remotely you might need the VMWare console, which needs Xlibs but not a full blown GUI.
  8. Download and run chkrootkit from http://www.chkrootkit.org/
  9. Install CLAMAV , even if you do not share Windows files. Eventually you will put Windows files there. It is always good to have Anti virus. On-the-fly scan might not be necessary, once a day scanning via cron might jsut be enough.clamav
  10. Verify that automatic updates are running but not installing. Always have cron mail you firstabout what packages need to be updated. Once you have checked the list you can log in and run the command apt-get-upgrade or yum upgrade or emerge …. on your own.

This is a quick list of things to do. This will not give you a bulletproof server, you could still install tripwire and AIDE, but this will nail your server down quite heavily already and if you have it running on the public internet this will DEFINITELY make it much more secure and stable.

Once it is then operationala nd you have everything as you want it, you can then play with SE Policies and/or IDS systems etc.

Technorati Tags: , , , , , , , , , , ,
Digg!

Popularity: 3% [?]