Best Practices for setting up a Red Hat Enterprise Linux web server?

Latest response

Is there any documention or checklist for best practices when setting up a Red Hat Enterprise Linux web server?

Responses

Have you checked out the official RH documentation?

 

Chapter 14 from the RHEL Deployment Guide:  http://red.ht/iA1dge

Got a 404 error for this page.

The docs were Beta at that time - they are now GA and have a different link:

 

http://red.ht/qrzqev

 

Thanks for the update!

I'd also recommend reading the RHEL Security Guide

 

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html

 

Here is a starting point for best practices. Let's update this as a community--thanks.

--

  1. Disable un-used services.
    There are several services that are installed and enabled by default that are unnecessary for a production web server. Disable these using chkconfig, and stop them with service stop.

Examples include bluetooth, cups

  1. When installing third-party software, try to conform to the Red Hat File System Hierarchy Standard (FHS).
    Using pre-defined, uniform filesystem paths for software will result in a more manageable deployment. For example, putting libraries in /usr/lib and configuration files in /etc. Not only will people have a good idea where to look, it makes performing filesystem backups more straightforward as well.

  2. Enable SELinux and become comfortable with its use.
    There are a few SELinux booleans available to configure for use with Apache. Please see httpd_selinux(8) for additional detail.

  3. Implement production firewalling with either a software firewall (iptables), or a standalone hardware device.
    Reducing your attack surface will result in a more secure installation.

  4. Perform routine backups.
    There are several options available for perform backups of production servers. If your content is relatively static, rsync will do a good job. If you have production MySQL databases, you will want to perform routine mysqldumps and ship those off the server(s) as well.

  5. Review and follow NSA guidelines for host security.
    The National Security Agency has put together extensive documentation on securing production RHEL servers. See http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf for more details.

Phil Jensen, RHCA
Sr. Operations Engineer
Proofpoint, Inc.

Phil made some very good points.  So I'll just expand upon what he's written, I'll try to keep his numbering, but insert mine...

 

.1.  Planning and design

Talk with whomever is requesting the webserver (if it's not yourself), to determine what needs to run on the server.  AKA, does the webserver need support for php, perl, cgi, etc.  Some question to have answered before you start:

What is the desired uptime of the server?  Is it ok if the server is down 2, 4, 6 hours, etc.

Outage windows?  When will you be able to work on the server (patching, configuration changes etc.)

Redundancy?

(I'm sure there are many more, but this is a start.)

 

.2. Minimal Installation

Once you have an idea of what you want your server to look like, ONLY install what you need.  The idea is that you don't have to disable services that were never installed. With RHEL5 I typically only install the "base, core and mail-server" package groups, and then add on select packages.  This is made much easier using kickstart files.  Also, see Phil's (previous commentor's) #6: Review the NSA's hardening guidelines, CIS also has a good benchmark (they're soon to release a 2.0 version) http://benchmarks.cisecurity.org/tools2/linux/CIS_RHEL5_Benchmark_v1.1.pdf

 

.3. Repeatability

Even if you install a server via the GUI, a copy of this configuration is saved to /root/anaconda-ks.cfg.  If you ever need to rebuild this server you can use it, OR if you need to build a second webserver it will help to give you a very similar install.

 

.4. Test systems

Because of virtualization you no longer need to have a physical server dedicated to a test system.  So, you shouldn't have any reason why you don't have a test/dev equivalent for your production server.  Use this system to test the effects of configuration changes, patch updates, etc.

 

1-6. (see previous commentor)

 

7.  Apache configuration/hardening

Like in section .2, only run what you need.  Do some googling for apache 2.2 hardening, for more reading...  There's waay too much to list here, but here are the top ones to look for:

-  Only load the modules you need (comment out the LoadModule line for modules you're not using)  You could probably disable more modules, but try starting with only these: alias_module, authz_host_module, autoindex_module, dir_module, headers_module, include_module, log_config_module, mime_magic_module, mime_module, negotiation_module, setenvif_module

 

-  Set "ServerTokens" to "ServerTokens Prod"

-  Set "ServerSignature" to "ServerSignature Off"

-  Disable cgi (if not needed)

-  Disable /etc/httpd/conf.d/welcome.conf.  (Do this by commenting out all lines).  I don't recommend deleting the file, because when you update apache from RHN, it will be regenerated.  If it's commented out, the upgrade leaves it as is.

 

8. Monitoring

There are plenty of monitoring software packages available (many are free), since this is a website is going to be externally facing, it would be embarassing if it was down for days and you didn't know about it.

 

9.  Patching

Because this server will be on the internet, timely patching is critical.  I'm assuming you're running an entitled OS, so egularly apply patches/updates from RHN.  Apply critical severity patches ASAP (outside your normal patch window).

 

10.  DMZ

This probably should go without saying, but if this webserver is available on the internet.  Have it placed in a dmz.  NEVER make a server on your internal network available from the internet.  Because if that server get's hacked, the attackers now have a doorway into your network.