Comments 6 Posted In Red Hat Enterprise Linux Best Practices for setting up a Red Hat Enterprise Linux web server? Latest response 2011-07-27T16:26:25+00:00 Is there any documention or checklist for best practices when setting up a Red Hat Enterprise Linux web server? JB Started 2011-05-06T22:01:23+00:00 by JBradySD Community Member 82 points Log in to join the conversation Responses Sort By Oldest Sort By Newest Red Hat Guru 3695 points 9 May 2011 3:13 AM andriusb Have you checked out the official RH documentation? Chapter 14 from the RHEL Deployment Guide: http://red.ht/iA1dge JB Community Member 82 points 11 July 2011 7:26 PM JBradySD Got a 404 error for this page. Red Hat Guru 3695 points 11 July 2011 7:33 PM andriusb The docs were Beta at that time - they are now GA and have a different link: http://red.ht/qrzqev Thanks for the update! Red Hat Pro 541 points 5 April 2012 12:07 AM Steven Ellis 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 Guru 3262 points 22 May 2011 9:15 AM Phil Jensen Community Leader Here is a starting point for best practices. Let's update this as a community--thanks. -- 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 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. 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. 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. 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. 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. ji Community Member 25 points 27 July 2011 4:26 PM jinserra 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.