Data Centers

SolutionBase: Secure your Apache server with these tips

Because Apache is the most popular Web server on the Internet, it can be a big hacker target. These tips can help you secure your Apache server.

When you're in charge of the Web server, the powers-that-be treat you like the guard at the bank: If anyone gets into the vault, they expect it to be over your dead body. There's a lot you can do to secure Web transactions at both the application and network level, but the buck still stops with you.

Maybe you're doing session tracking or using SSL. You're prepared for denial-of-service attacks and have secured your log files. You're on the ball, and nobody's getting into that Apache server without a fight. But there's still more you can do.

Keeping an eye on the cashbox

While it's important to guard the door, it's equally important to guard the valuables in your Apache server. Of course, you're watching server traffic, but you need to have one eye on the door and one eye on the server itself, in case somebody gets through without your catching them up front.

You can take a snapshot of Apache's compiled modules at any time with the command

$ apache/bin/httpd -l

Why would you want to do this? To ensure that some of your security bulwarks, such as mod_session and mod_rewrite, are in place, and to be certain that any security-specific server configuration modules are loaded.

Is the server serving? Who wants to know?

You can look at the server from the browser point of view to check its status. In the httpd.conf file, there are two URLSï¿?server-status and server-infoï¿?appended to http://localhost/ under <Location>. These directives are usually commented out (and you should normally leave it that way in order to keep server status information from being seen by users).

You can enable this feature safely with the Order directive and with Deny and Allow statements. For example, Order Deny, Allow followed by Allow from {domain} will cause any IP addresses not resolving to the given domain to be denied access to server information.

Watching your tail

You can observe server activity with the tail command, which accesses the most recent access_log and error_log entries. Used with the ï¿?f option, it can observe incoming requests in real time:

# tail ï¿?f access_log

Looking out for your variables

You can monitor CPU activity and system variables with the top utility. You can observe which active processes are running under root privileges, parent-child process relationships, etc.

Setting limits

When it comes to guarding the door, it's about more than making certain that bad guys don't get past you. You need to direct users as they enter, pointing them in the right direction and keeping them from going where they shouldn't.

You can use the <Directory> directive to control user access to server directories. By definition, this includes Web content directories, so this is one you'll make use of. The format for the directive is:

ï¿?ï¿?ï¿?ï¿?ï¿? <Directory "/usr/local/apache2" ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿? Options {options} ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿? Order Deny, Allow ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿?ï¿? Allow from {domain} ï¿?ï¿?ï¿?ï¿?ï¿? </Directory>

In addition, there are multiple options:

  • ExecCGI enables CGI scripts for the directory
  • Includes enable server-side includes
  • Indexes return a directory listing if there isn't an index.html file
  • MultiViews enable browser-dependent content

Maximum capacity

Apache generates child processes to handle increasing HTTP requests. Eventually, a flood of such requests can take down the server, as in a denial-of-service attack. To guard against this, you can use the KeepAlive directive to free up resources. Normally, KeepAlive is set to "on" in order to monitor and service persistent client sessions. By turning it off, the resources it sets aside for long-session clients are freed up.

A better way is to leave it on and set a KeepAliveTimeout {seconds} so that the feature is live but efficient. Then set a MaxClients={integer} limit, curtailing the number of possible processes (and thereby the number of possible child processes inspired by a DoS attacker). You can go still further by setting a limit on KeepAlive sessions with MaxKeepAliveRequests={integer}.

Spotting and stopping an attacker

Using the tail command, you can observe a DoS attack beginning in real time. The access log will show a rush of requests from a common IP. Seeing this, you want to restrict the attacker from your /var/www/html directory. Do so by editing httpd.conf and the appropriate <Directory> directive. Enter an Order Deny, allow directive underneath the <Directory> directive, followed by Deny from {IP of the attacker}. Run apachect1 to restart Apache, and the intruder is blocked!

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks

Free Newsletters, In your Inbox