Apache Configuration File Security Option

you’ll examine the security options available in the main Apache configuration file, httpd.conf. That file can be modified to secure the entire server or to configure security on a directory-by-directory basis. Directory controls secure access by the server, as well as users who connect to the web sites on the server. To explore the basics of Apache security, start with the first default active line in httpd.conf:

ServerTokens OS

This line looks deceptively simple; it limits the information displayed about a web server you navigate to a nonexistent page to the following message:

Apache/2.2.15 (Red Hat) Server at localhost Port 80

Contrast that output with what happens with a ServerTokens Full line:

Apache/2.2.15 (Red Hat) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.2

Python/2.6.5 mod_perl/2.0.4 Perl/v5.10.1 Server at localhost Port 80

In other words, with one option, outsiders can see whether modules such as Perl, Python, and PHP have been loaded, along with their version numbers. As not everyone updates their software in a perfectly timely manner, what happens when a cracker sees a version that has been compromised, your servers will face additional risks. Next, you can restrict access to the directory defined by the ServerRoot directive as shown here:

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

This configures a very restrictive set of permissions. The Options FollowSymLinks line supports the use of symbolic links for web pages. The AllowOverride None line disables any .htaccess files. The ServerRoot directive points to /etc/httpd, which contains Apache configuration files. Without the AllowOverride None line, a cracker who inserts a malicious .htaccess file can configure permissions that allows any user to change such configuration files. However, there’s an appropriate use for .htaccess files. For example, when placed in a subdirectory such as /www/html/project, then it can be used to permit access to a group, and such changes would apply only to that directory. You can improve this by limiting access to all but explicitly allowed users, by adding the following commands to the desired <Directory> container:

Order deny,allow

Deny from all

The next <Directory> container example limits access to /var/www/html, which corresponds to the default DocumentRoot directive (while these directives are divided by numerous comments, they are all in the same stanza):

<Directory /var/www/html>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

The Options directive is different; the Indexes setting allows readers to see a list of files on the web server if no index.html file is present in the specified directory. The Order and Allow lines allow all users to access the web pages on this server. Finally, the Listen directive defines the IP address and TCP/IP port for this server. For example, the default shown next means that this server will work with every computer that requests a web page from any of the IP addresses for your computer on the standard TCP/IP port, 80:

Listen 80

If more than one IP address is available on the local system, the Listen directive can be uses to limit access to one specific IP address. For example, if a system has two network cards with IP addresses 192.168.0.200 and 192.168.122.1, the following directive can help limit access to systems on the 192.168.122.0 network:

Listen 192.168.122.1:80

[ Read More ]

Apache and SELinux File Labels

Take a look at the SELinux settings associated with Apache. To review, SELinux settings, as they relate to a service, mostly fall into two categories: boolean settings and file labels. Start with the file labels.

Apache and SELinux File Labels

The default file labels for Apache configuration files are consistent, as shown in the output to the ls -Z /etc/httpd and ls -Z /var/www commands. Individual files use the same contexts as their directory. For web sites where scripts read and or append data to web forms, you’d consider the last two contexts, which support read/write (rw) and read/append (ra) access.

Create a Special Web Directory

In many cases, you’ll create dedicated directories for each virtual web site. It’s better to segregate the files for each web site in its own directory tree. But with SELinux, you can’t just create a special web directory. You’ll want to make sure that new directory at least matches the SELinux contexts of the default /var/www directory. Run the ls -Z /var/www command. Note the SELinux contexts. For most directories, the user context is system_u and the type is http_sys_content_t. For a newly created /www directory, you could just change the SELinux contexts with the following commands. The -R applies the changes recursively, so the new contexts are applied to files and subdirectories.

# chcon -R -u system_u /www/

# chcon -R -t httpd_sys_content_t /www/

Of course, if scripts are required for the associated web site, you’ll want to run the following command to make sure the SELinux changes survive a relabel:

# semanage fcontext -a -s system_u -t httpd_sys_content_t /www/

This command creates a file_contexts.local file in the /etc/selinux/targeted/ contexts/files directory. If there’s also a cgi-bin/ subdirectory, you’ll want to set up appropriate contexts for that subdirectory as well with the following command:

# semanage fcontext -a -s system_u -t httpd_sys_script_exec_t  /www/cgi-bin/

The differences in the file contexts are shown in Table

Directory	SELinux Context Type
/etc/httpd, /etc/httpd/conf, /etc/httpd/conf.d, /var/run/httpd	httpd_config_t
/usr/lib64/httpd/modules	httpd_modules_t
/var/log/httpd	httpd_log_t
/var/www, /var/www/error, /var/www/html, /var/www/icons, /var/www/manual, /var/www/usage	httpd_sys_content_t
/var/www/cgi-bin	httpd_sys_script_exec_t
n/a	httpd_sys_content_rw_t
n/a	httpd_sys_content_ra_t

[ Read More ]

Apache Port and Firewalls

With the Listen and NameVirtualHost directives, the Apache web server specifies the standard communication ports associated with both the HTTP and HTTPS protocols, 80 and 443. To allow external communication through the noted ports, you can set up both ports as trusted services in the Firewall Configuration tool. Of course, for systems where HTTP and HTTPS are configured on nonstandard ports, you’ll have to adjust the associated iptables rules accordingly. If you just open these ports indiscriminately, it allows traffic from all systems. It may be appropriate to set up a custom rule to limit access to one or more systems or networks. For example, the following custom rules allows access to every system on the 192.168.122.0 network except the one with IP address 192.168.122.150, over port 80. To review, these rules are applied to the iptables command, in order.

-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.122.150 --dport 80 -j REJECT

-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.122.0/24 --dport 80 -j ACCEPT

Similar rules may be required for port 443. Of course, that depends on the

requirements of the job.

[ Read More ]

Apache Log Files Details

Apache log files are configured in the /etc/httpd/logs directory, they’re actually stored in the /var/log/httpd directory. Standard logging information from Apache is stored in two baseline log files. Custom log files may also be configured. Such log files may have different names, depending on how virtual hosts are configured, how secure web sites are configured, and how logs are rotated.

Based on the standard Apache configuration files, access attempts are logged in the access_log file and errors are recorded in the error_log file. Standard secure log files include ssl_access_log, ssl_error_log, and ssl_request_log.

In general, it’s helpful to set up different sets of log files for different web sites. To that end, you should set up different log files for the secure versions of a web site. The traffic on a web site is important when choosing a log rotation frequency.

There are standard Apache log file formats. Four different formats: combined, common, the referrer (the web page with the link used to get to your site), and the agent (the user’s web browser). The first two LogFormat lines include a number of percent signs followed by lowercase letters. These directives determine what goes into the log.

# LogLevel: Control the number of messages logged to the error log.

# Possible values include: debug, info, notice, warn, error, crit,

# alert, emerg.

#

LogLevel warn

#

# The following directives define some format nicknames for use with

# a CustomLog directive (see below) .

#

LogFormat “%h %l $u %t \ “%r\” %>S %b \ “%{Referer}i\” \” ” combined

LogFormat “%h %l $u %t \ “%r\” %>S %b” common

LogFormat “ %{Referer}i” agent

LogFormat “ %{User-agent}i” agent

# “combinedio” includes actual counts of actual bytes received (%I) and send (%O) ; this

# requires the mod_logio module to be loaded.

# LogFormat “%h %l %u %u %t \  “%r” %?s %b \ “ %{Referer}i\” \ “%{User-Agent}i\” %I %O” combinedio

#

You can then use the CustomLog directive to select a location for the log file, such as logs/special_access_log, and the desired log file format, such as common. For more information on log files and formats, refer to http://localhost/manual/logs.html.

Some web log analyzers have specific requirements for log file formats. For example, the popular open-source tool awstats (advanced Web Stats) requires the combined log format. It will fail to run if you leave the default common format. Awstats is a great tool for graphically displaying site activity. You can download it from a site such as www.sourceforge.net.

[ Read More ]