ModSecurity Trustwave

ModSecurity: Roadmap

This page lists our plans for the future versions of ModSecurity.

Version 2.6

  • Enhancements
    • Enhance persistent storage:
      • Allow relative changes to counters to be atomic.
      • Optimize storage and retrieval.
    • Enhance audit log sanitization:
      • Allow partial data sanitization.
      • Allow the RESPONSE_BODY to be sanitized.
    • Enhance external auditing/alerting (mlogc):
      • Optimize data queuing to lower RAM usage.
      • Allow sensor metrics to be sent to the console.
      • Add connection throttling which can be dictated by the console.
    • Allow for more flexibility when writing complex rules:
      • Add the ability to determine which targets previously matched.
      • Straighten out how non-disruptive actions work with chained rules.
  • Performance
    • Add a high performance IP address/network matching operator capable of large lists.
    • Further tune the detection engine.
    • Enhance the detection engine cache with faster lookups.
    • Expose more performance metrics through the audit log.
  • Ease of Use
    • Enhance the build process:
      • Allow static linking of dependencies on UNIX like OSes.
      • Allow better support for non-gcc compilers.
    • Allow for fully automate updates of the Core Rules (and others).
  • Arbitrary Character Sets
    • Introduce decoding and validating of various character sets.
    • Allow for enhancing and expanding decoding in future versions.
  • Documentation
    • Write more/better examples.
    • Enhance ModSecurity internals documentation.
    • Better document the different modes of operation.

Version 3.0 and Beyond

  • Portability. Focus on portability, making ModSecurity able to work with web servers other than Apache.
  • Release an IIS/ISA version of ModSecurity.
  • Learning. ModSecurity works well when you know exactly what you want to do. We want to expand what it's capable of so it can help in situations where manual configuration is not an option.
  • Configuration reload without restart.
  • Code modularity. We want to make it possible for others to contribute new functionality to ModSecurity without having to learn everything about its internals.
  • Define data formats, which will allow related products to build on top of what ModSecurity already provides.
  • Scripting. Improve performance of the scripting implementation (Lua) and further integrate scripting into the engine.
  • Rule writing in C, for when you need that extra bit of flexibility and performance.

Version-Independent Tasks

  • Better reverse proxy deployment documentation. Embedded deployment is just one option. Coupled with Apache configured in reverse proxy mode, ModSecurity turns into a network-based web application firewall.
  • Pre-configured VMware images based around Apache and ModSecurity will make it easier for new users to start playing with the technology.
  • Best practices and cookbook-style documentation. We understand better documentation is needed to make full use of ModSecurity.