Format string attacks remain difficult in both software and hackademic exercises as the techniques have not improved since their discovery. This session demonstrates advanced format string attack techniques designed to automate the process from creation to compromise as well as incorporate those techniques into the Metasploit framework. The audience is encouraged to bring a basic understanding of format string attacks in order to leave the presentation with the tools necessary to never write one again.
Apache is a fantastic web server. It’s easily installable on pretty much every modern operating system, it has gobs and gobs of community support, documentation and howto’s, and is very robust. What I don’t like about Apache is its kitchen sink approach to functionality. By default, lots of modules and extra configuration directives are enabled. Needless to say, the majority of these aren’t needed for a simple web server. Even with a more advanced web application, it’s best to start light. Here’s my list of the first 5 things I do when building an Apache web server:
1. Harden the OS. A rock solid web server wont stay up for long if the underlying operating system hasn’t been hardened. Make sure you are running a recent, supported operating system. Be sure that you are on a aggressive patching schedule, pick strong passwords for all accounts on the machine, and use encrypted management transports such as SSH. Consider placing the web server in a DMZ or behind a firewall, and then only allow HTTP and HTTPS to it from the Internet.
2. Get the Latest Version of Apache. There are two paths to take when installing Apache. First, you can head to http://httpd.apache.org/ and grab the latest version to build from source. Second, you can install the version in your Linux distributions package manager. Most Linux vendors backport security patches to their supported version of Apache, so even though you are getting security fixes – your version information wont necessarily match up with the latest and greatest from apache.org.
3. Hide Version Information. Hiding version information can help you keep a low profile, but it really doesn’t do much for actually securing your server. Nevertheless, it’s a simple step to take. On a Debian system with Apache installed with apt-get, it’s as simple as editing /etc/apache2/conf.d/security and changing the following lines (While you are in there, disable the Trace method as well):
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of: Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
If you are running PHP, you can also hide PHP version information by editing /etc/php5/apache2/php.ini and edit the following:
# Decides whether PHP may expose the fact that it is installed on the
# server (e.g. by adding its signature to the Web server header). It is
# no security threat in any way, but it makes it possible to determine
# whether you use PHP on your server or not.
expose_php = Off
4. Tune Your sites-enabled. Here is where the meat of your configuration lives. From here, you can set everything from directory browsing to mod_rewrite statements. This goes much deeper than the focus of this post (and may be good material for a future one). The Apache Security Tips page and Virtual Host page are great places to start.
5. Check Those Logs! Even the most secure Apache installation is crippled if you don’t know what is going on under all that fancy CSS. Make sure Apache is logging errors and access with the following directives in your sites-enabled/vhost file:
CustomLog /var/log/apache2/access.log combined
Once you have Apache logging, you need to do a couple things. First, you need to store those logs in a secure, redundant location. If your server ever crashes and takes all its logs with it, you will be clueless as to what happened. Second, you need to check the logs on a regular basis. I really like OSSEC and its integration with Apache. OSSEC can watch your Apache logs and email you when certain events trigger it.
Well there you have it. While this isn’t a end-all list of how to secure Apache, it should get you started. I know I have spent alot of late nights wrestling with Apache, so hopefully this can save you a little time.
ModSecurity. ModSecurity is a monster of a web application firewall. It comes stock with hundreds of rules to protect against common web attacks, and various communities have created their own custom rules as well. It can be a little tricky to setup and maintain, but the protection it provides is worth every minute spent on it.
Hiawatha. Looking for a lighter, more security focused web server? Try Hiawatha. Its got protection for XSS, CSRF, and SQL Injection build in. It also keeps very clean configuration files.
Have some input? Leave your favorite Apache hardening tips in the comments.