Security Advancements at the Monastery

There are a few topics I have meant to do a post on for awhile. Sometimes having too much interest and information on a topic can be a bad thing. Wanting to pull various postings and articles along with implementation instructions can be a bit time consuming. Plus, in order to demonstrate why someone might be interested in implementing a web application firewall (WAF), I envisioned a post discussing the collapse of the perimeter and addressing points made by the Jericho Forum (see the Security Roundtable podcast for June 2008 for a good discussion on the topic). Raffael Marty makes excellent points in his soon to be released book, “Applied Security Visualization“:

The crime landscape is shifting. Attacks are moving up the network stack. Network-based attacks are not the prime source of security problems anymore. The attacks today are moving into the application layer: Web 2.0, instant messenger attacks, fraud, information theft, and crime-ware are just some examples of new types of attacks that generate a load of data to be collected and analyzed. Beware! Applications are really chatty and generate alot of data.

While my current post is not about security visualization (see earlier post “Security Data Visualization“), I would like to point out that DAVIX, a live CD for data analysis and visualization, is expected to be released August 6th. That should be really cool and fun.

Since application security is a topic of interest for me, I ran into the problem of having too many topics I wanted to discuss when I started trying to write a post on ModSecurity, an open source, free WAF Apache module. Today, rather than waiting for me to integrate the information, I decided to move ahead and do the post while limiting myself to only pointing out the various sources. The reader can follow the links for a more in-depth discussion and understanding on the topic.

Why You Should Care

The Risky Business podcast has come to be one of my favorite podcasts. The host, Patrick Gray and regular guest Munir Kotadia, just cracks me up. Plus the show is informative and features great guests. This week’s show had an interview with H D Moore talking about the DNS bug. Timely and informative; what else can one ask for? The 68th episode, done at the beginning of this month, had an interview with Jeremiah Grossman concerning web application firewalls. As Patrick writes in the show notes, “it takes typical organizations around 130 days to fix sequel injection bugs in code. But you can mitigate these sorts of things with a Web app firewall, and you won’t even have to deal with the development team! Hooray!.”

In Grossman’s blog post “Can WAFs protect against business logic flaws?“, he pointed out that “WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors.” Stuart King, in his article, “Larry David and Web Application Firewalls“, builds upon this idea when he wrote:

Back to the CSO article where the point is made that we are sitting on a huge legacy of insecure code and that “we can’t rewrite history.” So, the argument is that a web application firewall mitigates the risk – note: does not solve the problem – until the code can be replaced.

How much of the risk is mitigated is open to debate, but there are lots of other things to consider too. For instance the cost of redeveloping code against the cost of purchasing and supporting a WAF. We also need to consider the value and risk profile of the product.

Today’s world consist of attackers adjusting focus from network-based attacks to the application layer. Grossman in his post “Website Security Strategies that Work” makes the claim that “9 out of 10 (or more) websites have vulnerabilities as a result of being built by those who didn’t know or appreciate the severity of today’s attacks.” There is no arguing that many organizations are sitting on a huge legacy of insecure code, much of which may have been written before the discovery of prevalent vulnerabilities such as XSS, SQL Injection, CSRF, etc. Even worse, organization often have their security groups focused on network or system security, leaving application level security to developers. Unfortunately, these developers are receiving little or no training, while remaining under pressure to produce code under short deadlines.

Andre Gironda series, starting with “Week of War on WAF’s: Day 1 — Top ten reasons to wait on WAF’s,” provides important reasons why WAFs should not be viewed as a silver bullet solution. Rich Mogull in his post “Web Application Security: We Need Web Application Firewalls To Work. Better” makes the important point:

With old school vulnerabilities we know the details of the specific vulnerability and (usually) exploit mechanism. With WAFs, we are trying to block vulnerability classes instead of specific vulnerabilities. This is a HUGE difference. The WAF doesn’t know the details of the application or any application-specific vulnerabilities, and thus is much more limited in what it can block.

Mogull goes on to state that WAFs can:

no longer be merely external boxes protecting against generic vulnerabilities; they need tighter integration into our applications. In the long term, I’ve branded this Application and Database Monitoring and Protection (ADMP) as we create a dedicated application and database security stack that links from the browser on the front end, to the DB server on the back.

ADMPs, or if you prefer WAFs + Database Activity Monitoring (WAFs+DAM), would be another step in the evolution of WAFs. As Ivan Ristic, creator of ModSecurity, points out in his blog post “What’s the Score of the Game?“:

I feel that one of areas where organizations are failing, with regards to web application security, is that there is a lack of communication between the following three groups: Development teams (who are running source code reviews), InfoSec teams (who are running vulnerability scans) and Operational Security teams (who are running web application firewalls). These three teams each have unique perspectives on the vulnerabilities of the webapps and they should share their data with each other.

Nicely stated. No one is arguing that writing secure code is not the answer. If organization began adapting secure systems development lifecycle (SDLC) models into their business operation, many security problems would go away. Building secure software will require changes in the current development culture, which will include people, processes, and technology. No small task.

Gunnar Peterson has a nice post, “WAF and XSG Risk and Effectiveness at 20,000 feet” where he discusses modeling of combination of risk and effectiveness to identify areas of focus. As Peterson points out in another post, “WAFs are not as static as network firewalls…Instead WAFs collaborate much more directly with development, which is another growth opportunity for security industry.”

This post is going to stay focused on WAFs. With it taking on average 130 days to fix sequel injection bugs, organizations need something they can implement today. WAFs have an important role to play in adding a layer of security and monitoring to a defense in depth security approach. WAFs will evolve. They are in the process of evolving now. Understanding the fundamental ideas and going through the implementation of an open source solution starts us on the path of better understanding of future technologies.

An Implementation Using ModSecurity

Building on previous posts concerning “An Apache Implementation“, “PHP Implementation“, and “Apache and OpenSSL“, we have an Apache web server setup to build upon. For additional details, please get Ivan Ristic’s book, “Apache Security.” It really is a must have book for anyone serious about running an Apache web server. Ristic also maintains the ModSecurity website and blog, which serves as a great source for up-to-date information on ModSecurity.

The Apache module mod_unique_id needs to be installed for ModSecurity to work properly. This module was not installed when we configured Apache. At that time, we did not know we needed it. While it can be somewhat inconvenient, for security reasons it is best not to install modules not needed.

1. Stop Apache Server.

# /usr/local/apache/bin/apachectl stop

2. Install mod_unique_id Module.

For non Mac OS X, do the following:

root# cd /usr/local/src/httpd-2.2.8
/usr/local/src/httpd-2.2.8 root# make clean
/usr/local/src/httpd-2.2.8 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
./configure --prefix=/usr/local/apache \
--enable-rewrite \
--enable-so \
--disable-imap \
--disable-userdir --with-mpm=worker --enable-ssl --enable-unique-id --enable-unique-id
/usr/local/src/httpd-2.2.8 root# make
/usr/local/src/httpd-2.2.8 root# make install

For Mac OS X, please do:

root# cd /usr/local/src/httpd-2.2.8
/usr/local/src/httpd-2.2.8 root# make clean
/usr/local/src/httpd-2.2.8 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
./configure --prefix=/usr/local/apache --enable-rewrite \
--enable-so --disable-imap --disable-userdir \
--with-mpm=worker --enable-ssl --enable-unique-id
/usr/local/src/httpd-2.2.8 root# make
/usr/local/src/httpd-2.2.8 root# make install

3. Install PCRE.

Only under Mac OS X did I have to install Perl Compatible Regular Expressions (PCRE). You may be able to skip this step, depending on your OS.

root# cd /usr/local/src
/usr/local/src root# wget http://downloads.sourceforge.net/pcre/pcre-7.7.tar.gz
/usr/local/src root# tar xzf pcre-7.7.tar.gz
/usr/local/src root# cd pcre-7.7
/usr/local/src/pcre-7.7 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
./configure
/usr/local/src/pcre-7.7 root# make
/usr/local/src/pcre-7.7 root# make test
/usr/local/src/pcre-7.7 root# make install

4. Install the latest version of libxml2 or Lua.

To quote wikipedia, libxml is “a library for parsing XML documents” and Lua is “a lightweight, reflective, imperative and procedural programming language, designed as a scripting language with extensible semantics as a primary goal.” ModSecurity requires dynamic libraries which are not built by default in the source distribution. Binary distribution is recommended.

I will go through configuration and installation of libxml2 from source and the binary installation of lua under Mac OS X. There is a good chance if you are running a different OS, the libraries will have already been installed.

root# cd  /usr/local/src/
/usr/local/src root# wget ftp://xmlsoft.org/libxml2/libxml2-2.6.32.tar.gz
/usr/local/src root# tar xzf libxml2-2.6.32.tar.gz
/usr/local/src root# cd libxml2-2.6.32
/usr/local/src/cd libxml2-2.6.32 root#  CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
/usr/local/src/cd libxml2-2.6.32 root# ./configure
/usr/local/src/cd libxml2-2.6.32 root# make
/usr/local/src/cd libxml2-2.6.32 root# make install
/usr/local/src/cd libxml2-2.6.32 root# cd ..
/usr/local/src root# wget http://luaforge.net/frs/download.php/3097/lua5_1_3_Darwin811x86_lib.tar.gz
/usr/local/src root# mkdir lua
/usr/local/src root# cd lua
/usr/local/src/lua root# tar xzf lua5_1_3_Darwin811x86_lib.tar.gz
/usr/local/src/lua root# cp liblua5.1.* /usr/local/lib
/usr/local/src/lua root# cp include/* /usr/local/include

5. Download, unpack, configure, and compile ModSecurity.

If you are interested in connecting a ModSecurity sensor to the central audit log repository, you will want to build the ModSecurity Log Collector below with the command “make mlogc”. Install instructions can be found under apache2/mlogc-src directory. That step will not be included below.

root# cd  /usr/local/src/
/usr/local/src root# wget http://www.modsecurity.org/download/modsecurity-apache_2.5.5.tar.gz
/usr/local/src root# tar xzf modsecurity-apache_2.5.5.tar.gz
/usr/local/src root# cd modsecurity-apache_2.5.5
/usr/local/src/modsecurity-apache_2.5.5 root# cd apache2

For non Mac OS X, configure with the command:

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# ./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-apr=/usr/local/apache/bin \
--with-apu=/usr/local/apache/bin

For Mac OS X, use the command:

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
./configure --with-apxs=/usr/local/apache/bin/apxs

Continue to compile and install with the commands:

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# make
/usr/local/src/modsecurity-apache_2.5.5/apache2 root# make test
/usr/local/src/modsecurity-apache_2.5.5/apache2 root# make install
/usr/local/src/modsecurity-apache_2.5.5/apache2 root# ls -la /usr/local/apache/modules

6. Configure Apache and ModSecurity.

We must now edit the httpd.conf file in order to load libxml2 or lua5.1 modules before the ModSecurity module.

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# vi /usr/local/apache/conf/httpd.conf

Add the lines for non Mac OS X:

#
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
#
LoadModule security2_module modules/mod_security2.so

For Mac OS X, add the lines:

#
LoadFile /usr/local/lib/libxml2.2.dylib
LoadFile /usr/local/lib/liblua5.1.so
#
LoadModule security2_module modules/mod_security2.so

Create the ModSecurity configuration file. There is a file modsecurity.conf-minimal present in the /usr/local/src/modsecurity-apache_2.5.5 that can be used. There is also a a Core Rule Set that was included in the /usr/local/src/modsecurity-apache_2.5.5/rules directory courtesy of Breach Security Inc. To quote the README file, “The Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.” Under the rules subdirectory, there a directory “optional” which contains additional possible rules. It is left to the reader which configuration files they may want to include, though it might be wise to start with the minimal and make sure the Apache runs without problems. Then add configurations files as desired.

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# cd ..
/usr/local/src/modsecurity-apache_2.5.5 root# cp  modsecurity.conf-minimal /usr/local/apache/conf/modsecurity.conf
/usr/local/src/modsecurity-apache_2.5.5 root# cp  rules/*.conf /usr/local/apache/conf/

Include the modsecurity.conf, and additional ModSecurity configurations file, in the Apache httpd.conf file.

/usr/local/src/modsecurity-apache_2.5.5 root# vi /usr/local/apache/conf/httpd.conf

Add the line:

Include /usr/local/apache/conf/modsecurity.conf
#Include /usr/local/apache/conf/modsecurity_crs_10_config.conf
#Include /usr/local/apache/conf/modsecurity_crs_21_protocol_anomalies.conf
#Include /usr/local/apache/conf/modsecurity_crs_23_request_limits.conf
#Include /usr/local/apache/conf/modsecurity_crs_30_http_policy.conf
#Include /usr/local/apache/conf/modsecurity_crs_35_bad_robots.conf
#Include /usr/local/apache/conf/modsecurity_crs_40_generic_attacks.conf
#Include /usr/local/apache/conf/modsecurity_crs_45_trojans.conf
#Include /usr/local/apache/conf/modsecurity_crs_50_outbound.conf

Edit /usr/local/apache/conf/modsecurity.conf. The modifications will be very dependent on your environment. See resources listed in the Additional Information section to help with configuration. The default configuration saves the log files relative to the configuration file directory. Change this to where the apache logs are currently being saved.

/usr/local/src/modsecurity-apache_2.5.5 root# vi /usr/local/apache/conf/modsecurity.conf

Change the values to:

SecAuditLog /var/www/logs/modsec_audit.log
SecDebugLog /var/www/logs/modsec_debug.log

Let’s create null files with the correct permissions for Apache.

/usr/local/src/modsecurity-apache_2.5.5 root# touch  /var/www/logs/modsec_audit.log
/usr/local/src/modsecurity-apache_2.5.5 root# chown httpd.httpd /var/www/logs/modsec_audit.log
/usr/local/src/modsecurity-apache_2.5.5 root# touch  /var/www/logs/modsec_debug.log
/usr/local/src/modsecurity-apache_2.5.5 root# chown httpd.httpd /var/www/logs/modsec_debug.log

7. Start Apache.

Check that the configuration file is correct and start up Apache.

/usr/local/src/modsecurity-apache_2.5.5 root# /usr/local/apache/bin/apachectl configtest
Syntax OK
/usr/local/src/modsecurity-apache_2.5.5 root# /usr/local/apache/bin/apachectl start

Check if ModSecurity if configured into running Apache server.

/usr/local/src/modsecurity-apache_2.5.5 root# cat /var/www/logs/error_log | grep ModSecurity
[Thu Jul 31 18:24:59 2008] [notice] ModSecurity for Apache/2.5.5 (http://www.modsecurity.org/) configured.

Additional Information

This post is only to get the basics down. The above information was taken from the ModSecurity documentation install section for version 2.5.5. A great deal more information is available at the ModSecurity blog site and in the book “Apache Security“.

Concluding Remarks

Ivan Ristic and Ofer Shezaf are working on an interesting paper, “Enough With Default Allow in Web Applications!” This paper demonstrates how WAFs are evolving. To quote the paper:

The default allow deployment model, which is commonly used to implement and deploy web applications, is the cause of numerous security problems. We propose a method of modeling web applications in a platform-agnostic way to adopt a default deny model instead, removing several classes of vulnerability altogether and significantly reducing the attack surface of many others. Our approach is best adopted during development, but can be nearly as efficient as an afterthought, or when used at deployment time. What they are looking to do is create a protection layer between the web servers and applications which would increase security and turn applications into verifiable components with external contracts that can be enforced.

Ristic mentions in his post the planned release of “an open source profiling tool (which I will announce next week) to help with the third use case and automate the creation of positive security models (also known as the learning feature of web application firewalls).” Breach Security has also teamed up with WhiteHat Security to add the ability to their Sentinel scanning service to automatically create custom ModSecurity rules for certain classes of vulnerabilities that are found in your web applications. This is the kind of evolution that is required in security and makes ModSecurity such an interesting software package.