Apache Security Tips

Apache Security Tips

README

I am a Security Analyst, and all the time in my work I found many request attempts searching vulnerabilities in web applications hosted by the company where I work; so I decided to write a simple Ruby script parser which will allow me to view the Apache2 Logs easily, and then, try to identify the fingerprint of the attackers. Also I advise of some Apache2 Security Tricks, that prevent common hacking attempts.

The Apache Software Foundation’s goal is to build a secure, efficient and extensible HTTP server as standards-compliant open source software. The result has long been the number one web server on the Internet. It features support for HTTPS, virtual hosting, CGI, SSI, IPv6, easy scripting and database integration, request/response filtering, many flexible authentication schemes, and more.

Unfortunately, the problem with the security in Apache servers is in the configuration made by the server administrators, some of them let the default settings unchanged and make it easy to hackers attack the web-applications served by the hosting where they work.

Well, maybe you couldn’t change the configuration that I will explain in this post, but if you understand the next settings you’ll be in capacity to request an specific administrator ticket, a hosting change for your company or maybe (why not) hack their servers.

Explanation

We will use here two tools very useful in a real auditory process: curl and nikto, these tools let us know interesting information of a web-server configuration not only in Apache servers but in NGINX servers, Lighttpd, Apache Tomcat and maybe others (I haven’t tested these tools in all server’s engines obviously). Well, try to execute this command to show basic information of my domain: curl --head www.cixtor.com; this will send a HEAD request and it will display an output like this:

$ curl --head 'http://cixtor.com/'
  HTTP/1.1 200 OK
  Date: Sat, 28 Jul 2012 20:57:34 GMT
  Server: Apache/2.2.14 (Ubuntu) PHP/5.3.2-1ubuntu4.17 with Suhosin-Patch
  Vary: Accept-Encoding
  Content-Type: text/html;charset=UTF8

Assume us that I don’t have any DocumentIndex file in my public web folder, this will provoke a document Index of / file listing, this is bad in some cases and only useful for FTP directories where you want to share files. In my case and assuming that I don’t want to put a default index file inside all the folders in my web-application, I will restrict the Indexing through the AccessFileName a file called generally .htaccess: Options -Indexes

Limit the list of HTTP methods allowed to request to your web-application, in a production environment you should only accept POST and GET requests and just in case OPTIONS for some JSONP requests.

# /home/cixtor/public_html/.htaccess
Options -Indexes

Order deny,allow
Deny from all
<Limit POST, GET>
    Allow from all
</Limit>

Change the ServerSignature parameter value in the Apache security configuration file to disallow the shown of the version and modules compiled/configured with the web-server, this file is generally located (in a Debian server) in this path /etc/apache2/conf.d/security, also in this file disable the TRACE method (typcally only used for debugging) and put the ServerTokens in production mode.

# /etc/apache2/conf.d/security
ServerSignature EMail
TraceEnable Off
ServerTokens Prod

To remove the display of the PHP version configured to work with the Apache server you’ll need to set in off the parameter expose_php configured in the php.ini file, use this command to know what configuration file are being used by your PHP interpreter: php -i | grep -i 'php.ini'

# /etc/php5/apache2/php.ini
expose_php = Off

With these basic settings (and after the restart of the service of your web-server with service apache2 restart or service httpd restart in CentOS machines) the security of your Apache web-server won’t be compromised so easily, and will give you more time when a hacker is checking the server searching vulnerabilities… I say more time because all the requests made to your server are saved in a log file that you can review to detect an attack.

Also check Ruby Apache2 Log-Viewer

Do you have a project idea? Let's make it together!