4 reasons not to use mod-security

Apache is a great web server if for no other reason than it offers more flexibility through modules than just about any other web server. You can plug-in all sorts of modules to enhance the functionality of Apache.

But as I often say, just because you can doesn't mean you should.

One of the modules you can install is mod_security. If you aren't familiar with mod_security, essentially it's a "roll your own" web application firewall plug-in for the Apache web server.

Some of the security functions you can implement via mod_security are:

  • Simple filtering
  • Regular Expression based filtering
  • URL Encoding Validation
  • Unicode Encoding Validation
  • Auditing
  • Null byte attack prevention
  • Upload memory limits
  • Server identity masking
  • Built in Chroot support

Using mod_security you can also implement protocol security, which is an excellent idea for ensuring that holes in protocols aren't exploited. If you aren't sold on protocol security you should read up on the recent DNS vulnerability discovered by Dan Kaminsky - it's all about the protocol and has nothing to do with vulnerabilities introduced by implementation.

mod_security provides many options for validating URLs, URIs, and application data. You are, essentially, implementing a custom web application firewall using configuration directives.

If you're on this path then you probably agree that a web application firewall is a good thing, so why would I caution against using mod_security?

Well, there's four reasons, actually.

  1. It runs on every web server. This is an additional load on the servers that can be easily offloaded for a more efficient architecture. The need for partial duplication of configuration files across multiple machines can also result in the introduction of errors or extraneous configuration that is unnecessary. Running mod_security on every web server decreases capacity to serve users and applications accordingly, which may require additional servers to scale to meet demand.
  2. You have to become a security expert. You have to understand the attacks you are trying to stop in order to write a rule to prevent them. So either you become an expert or you trust a third-party to be the expert. The former takes time and that latter takes guts, as you're introducing unnecessary risk by trusting a third-party.
  3. You have to become a protocol expert. In addition to understanding all the attacks you're trying to prevent, you must become an expert in the HTTP protocol. Part of providing web application security is to sanitize and enforce the HTTP protocol to ensure it isn't abused to create a hole where none previously appeared. You also have to become an expert in Apache configuration directives, and the specific directives used to configure mod_security.
  4. The configuration must be done manually. Unless you're going to purchase a commercially supported version of mod_security, you're writing complex rules manually. You'll need to brush up on your regular expression skills if you're going to attempt this. Maintaining those rules is just as painful, as any update necessarily requires manual intervention.

Of course you could introduce an additional instance of Apache with mod_security installed that essentially proxies all requests through mod_security, thus providing a centralized security architecture, but at that point you've just introduced a huge bottleneck into your infrastructure. If you're already load-balancing multiple instances of a web site or application, then it's not likely that a single instance of Apache with mod_security is going to be able to handle the volume of requests without increasing downtime or degrading performance such that applications might as well be down because they're too painful to use.

Centralizing security can improve performance, reduce the potential avenues of risk through configuration error, and keeps your security up-to-date by providing easy access to updated signatures, patterns, and defenses against existing and emerging web application attacks. Some web application firewalls offer pre-configured templates for specific applications like Microsoft OWA, providing a simple configuration experience that belies the depth of security knowledge applied to protected the application. Web application firewalls can enable compliance with requirement 6.6 of PCI DSS

And they're built to scale, which means the scenario in which mod_security is used as a reverse proxy to protect all web servers from harm but quickly becomes a bottleneck and impediment to performance doesn't happen with purpose-built web application firewalls.

If you're considering using mod_security then you already recognize the value of and need for a web application firewall. That's great. But consider carefully where you will deploy that web application firewall, because the decision will have an impact on the performance and availability of your site and applications.

 

 

 

AddThis Feed Button Bookmark and Share

Published Jul 23, 2008
Version 1.0

Was this article helpful?

7 Comments

  • Not bashing at all. In fact, if you aren't into running a web app firewall and think mod_security is a good idea, then DO IT.

     

     

    Any security is better than no security, and mod_security can certainly be used to provide security. I'm just saying there are better options out there in terms of management, performance, and configuration, not that mod_security should never be used in any situation.

     

     

    "I would argue that a fundamental problem with current web apps is the fact that security is often shunted to people other than the ones building the application.

     

     

    So, in fact, developers *have* to understand attacks and code to mitigate them. The developers are the ones that should be accountable for any breach."

     

     

    I like this statement, and in a utopian IT department it might even work, but in the real world developers don't understand the attacks that might be launched against them. If they did, they would develop applications that were able to defend themselves, mitigating the need for any external web application security, a la mod_security or web application firewalls.
  • As a follow up, I also suggest reading through the recommended requirements for qualifying as an acceptable WAF solution for PCI DSS:

     

     

    PCI DSS 6.6 Clarification

     

     

    I do not believe Apache mod_security meets all of these guidelines.
  • Hi Ivan,

     

     

    I'm sorry that you interpret this as an "attack" on mod_security. It isn't meant to be an "attack" on the module but merely reasons against choosing it over other solutions and points to consider in the process of deciding which WAF to invest in.

     

     

    I'm a bit confused because you seem to be referencing Breach's ModSecurity as opposed to Apache mod_security. I realize ModSecurity is based on mod_security, but it is also my understanding that it is a bit more polished than the core module.

     

     

    I am happy to hear people choosing any WAF over none, but that choice should be an informed one. Sharing your opinion here helps that process and presents different views so that people can do additional research and decide which WAF best fits their environment, architecture, budget, and skill sets, which is what such conversation starters are designed to do.

     

  • @anonymouse

     

     

    At a minimum the following three recommendations do not appear to be met by mod_security.

     

     

    "Inspect web services messages, if web services are exposed to the public Internet. Typically this would include Simple Object Access Protocol (SOAP) and eXtensible Markup Language (XML), both document- and RPC-oriented models,in addition to HTTP."

     

     

    There does not appear (and Ivan can correct me if I'm wrong) to be a mechanism within mod_security for fully inspecting XML for the purposes of preventing attacks (which is the purpose of PCI DSS). Excessive nesting of elements, schema poisoning, etc...are nearly impossible to detect without the ability to parse XML and inspect it as a DOM, something that mod_security does not appear capable of providing.

     

     

    "Automatically receive and apply dynamic signature updates from a vendor or other source. In the absence of this capability, there should be procedures in place to ensure frequent update of WAF signatures or other configuration settings."

     

     

    For mod_security this support is completely absent. There does not appear to be any centralized method or procedures supported by The Apache Foundation to meet this requirement. I assume Breach has addressed this in their support model.

     

     

    "Some ecommerce applications may require FIPS hardware key store support. If this is a consideration in your environment, make sure that the WAF vendor supports this requirement in one of their systems and be aware that this feature may drastically increase the cost of the solution."

     

     

    Obviously if this is the case, then mod_security does not support this one.

     

     

    In the end, it is up to the PCI auditor to determine whether the environment is considered compliant or not, and whether the chosen WAF (if there is one) is acceptable. But given these requirements there are environments in which mod_security does not appear to fulfill the recommended guidelines for meeting PCI DSS compliance.

     

  • @anonymouse

     

     

    The PCI DSS requirements are exceedingly ambiguous. In the one case (hardware key store) it specifically mentions that *some* applications may need it, but never mentions what those applications may be or what variables constitute needing a hardware key store.

     

     

    Pertaining to the XML, they do not say "if you're serving XML/SOAP you need this", you apparently just need it. It should read more like the requirement around hardware key stores - if you're doing XML, you need to protect it. If you aren't, then don't worry about it.

     

     

    I agree with the assessment that third-party updating can be a double-edged sword. The best option, IMO, is that the vendor offer it, but allow the customer to choose *how* they are applied, if they are applied at all. This fulfills the "auto update" requirement for PCI DSS but still leaves the customer in control of their own environment.

     

     

    PCI DSS is important to those organizations that fall under it, but for those that don't, it becomes a non-issue in the decision of which WAF to purchase, of course.
  • @Ivan,

     

     

    Thanks for the clarification. I stand corrected! I have edited the post to remove the incorrect interpretation.

     

     

    Again, thanks for clarifying - it is much appreciated.

     

     

    Lori
  • I was looking for a simple alternative to mod_security, as I'm not a system administrator and found it hard to avoid "false positives" (I manage a lot of "old" websites), but this article doesn't mention anything, at least nothing open source. Reading the comments comforted me in the idea that there is no quick and easy solution for that, so the best solution is probably to get more educated on mod_security, even if it seems really daunting at first.

     

     

    Kind regards,

     

    Le blog informatique

     

    Patrick