We continue to look at apache configuration options for your RHEL server.
More apache settings
In the previous article we covered several of the settings apache uses to manage incoming connections. Let's highlight some other directives apache looks for in its config files.
Default: Not Set
The ServerName is usually a hostname or a FQDN (Fully-Qualified Domain Name).
If you followed the apache install article, you will have already set the ServerName configuration.
If you don't set the ServerName then on an Apache restart you might see the following warning:
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
To stop the warning and set the ServerName, add the following to the apache config, preferably in its own file in the apache conf/custom directory:
Remember the test slice has a hostname of "demo", which is what we're using above. Since the ServerName can determine how apache identifies its own address to clients, it's usually best to use a fully-qualified domain name here.
We'll go into more detail about this directive when we discuss virtual hosts, but for now it's good to note that this directive is first set in the main apache config. The AccessFileName describes a file that can be added to a directory to override the options set in the main configuration. You might consider disabling this directive in the main apache config file, then only enabling it in the specific virtual hosts where you will use it.
This directive describes the location where apache will log any errors by default. This is another of those directives that can be overridden at the virtual host level.
It's a good idea to review a couple of security-related settings for apache — ServerTokens and ServerSignature — in the main apache config file.
The ServerTokens setting will dictate how much information is sent in the Headers with regard to Apache version and modules in use.
The default (OS) would send something like this:
Apache/2.2.14 (Red Hat) Server
This isn't information most users will care about, and hopefully won't even see (since it's embedded in the headers, and displayed on default error messages). But more villainous types who are looking for ways to break into your server will certainly look at that output and use it to their advantage (if there were a known exploit for apache 2.2.14, for example).
Reducing the amount of information apache gives out about itself does not make the actual install any more secure but all someone has to do right now is look for an exploit in your version of Red Hat-distributed apache. Why make things easy for them?
The options for this setting are (with sample output):
Apache/2.2.14 (Red Hat) DAV/2 mod_ssl/2.2.14 OpenSSL/1.0.0-fips-beta4 Server
Apache/2.2.14 (Red Hat) Server
See how the server information gets less and less specific as you go down the list? It's up to you what level of info you want to give out, but most users will be fine just setting ServerTokens to "Prod".
Server generated pages, such as 404 pages or directory listings, can contain a footer line which includes server information (which we configured via ServerTokens), and can also include the ServerAdmin email address.
If you navigate to your server IP address and try to access a non-existent page, you will see a 404 Page not found page with the footer information For an older Ubuntu install, it would look like this:
Some browsers replace this default error page with their own - sometimes looking for a "View page source" option in those browsers will let you see the text from the original page.
The options for ServerSignature are:
Off: Produces no footer
On: Produces footer information (at a level defined by the ServerTokens setting)
Email: Adds an email link to the information (email address is defined in the vhosts file with the ServerAdmin setting)
Keep in mind that many security settings can be overridden by a virtual host file.
If you disable the ServerSignature in the "security" config file, but a virtual host file has:
Then the global setting will be overridden and a footer will still be displayed on 404 pages, etc. for any sites associated with that virtual host.
You should now have a basic idea of the main settings you can use to customize apache for your environment. Following up by looking at some other settings defined in apache's config files can be beneficial as well, just to know what's going on behind the scenes.
All that should remain now, if you're following this tutorial series, is to set up the virtual hosts for your web server.
- -- Jered