ModSecurity
 | This article needs additional citations for verification. (January 2018) |
| Original author(s) | Ivan Ristić |
|---|---|
| Developer(s) | Trustwave SpiderLabs |
| Initial release | November 2002 |
| Stable release | 3.0.4
/ 13 January 2020 |
| Repository | |
| Written in | C++ |
| Available in | English |
| License | Apache License 2.0 |
| Website | modsecurity |
ModSecurity, sometimes called Modsec, is an open-source web application firewall (WAF). Originally designed as a module for the Apache HTTP Server, it has evolved to provide an array of Hypertext Transfer Protocol request and response filtering capabilities along with other security features across a number of different platforms including Apache HTTP Server,[1][2] Microsoft IIS and Nginx.[3] It is a free software released under the Apache license 2.0.
The platform provides a rule configuration language known as 'SecRules' for real-time monitoring, logging, and filtering of Hypertext Transfer Protocol communications based on user-defined rules.
Although not its only configuration, ModSecurity is most commonly deployed to provide protections against generic classes of vulnerabilities using the OWASP ModSecurity Core Rule Set (CRS).[4] This is an open-source set of rules written in ModSecurity's SecRules language. The project is part of OWASP, the Open Web Application Security Project. Several other rule sets are also available.
To detect threats, the ModSecurity engine is deployed embedded within the webserver or as a proxy server in front of a web application. This allows the engine to scan incoming and outgoing HTTP communications to the endpoint. Dependent on the rule configuration the engine will decide how communications should be handled which includes the capability to pass, drop, redirect, return a given status code, execute a user script, and more.
History
ModSecurity was first developed by Ivan Ristić, who wrote the module with the end goal of monitoring application traffic on the Apache HTTP Server. The first version was released in November 2002 which supported Apache HTTP Server 1.3.x. Starting in 2004 Ivan created Thinking Stone to continue work on the project full-time. While working on the version 2.0 rewrite Thinking Stone was bought by Breach Security, an American-Israeli security company, in September 2006. Ivan stayed on continuing development of version 2.0 which was subsequently released in summer 2006.
Ristić and Breach Security released another major rewrite, version 2.5, with major syntactic changes in February 2008. In 2009 Ivan left Breach to found SSL Labs. Shortly after Ivan's departure from Breach Security, Trustwave Holdings acquired Breach in June 2010 and relicensed ModSecurity under the Apache license. Development continued and the new license allowed easier integration of ModSecurity into other products. As a result of this there was steady adoption of ModSecurity by various commercial products. The license change also precipitated easier porting of the software. Hence, Microsoft contributed an IIS port in August 2012 and the port for Nginx was released at Black Hat Briefings in 2012.
2017 saw the second edition of the handbook released,[5] written by Christian Folini and Ivan Ristić. It covers ModSecurity up to version 2.9.2.
Being originally an Apache module, porting ModSecurity to other platforms was time consuming and had high maintenance costs. As a result of this a complete rewrite was started in December 2015. This new iteration, libmodsecurity, changes the underlying architecture, separating ModSecurity into a standalone engine that communicates with the web server via an API. This modular architecture based WAF, which was announced for public use in January 2018[6], became libmodsecurity (ModSecurity version 3.0) and has supported connectors for Nginx and Apache.
Former Lynx browser blocking
The default rules shipped with most ModSecurity distributions are the OWASP ModSecurity Core Rule Set (CRS).[4] These rules used to block the Lynx browser as an "automated tool", returning a "406 Not Acceptable" to it unless its user-agent string was changed.[7] This inconvenienced users with blindness who work in Lynx. However, with the release of Core Rule Set 3.0 (CRS3), a Lynx user agent does not trigger any rules anymore.[citation needed]
References
- ^ "How to secure your Apache 2 server in four steps". Techrepublic.com. Retrieved 7 January 2018.
- ^ Shah, Shreeraj. "Securing Web Services with mod_security - O'Reilly Media". Onlamp.com. Retrieved 7 January 2018.
- ^ Lardinois, Frederic. "NGINX Plus's latest release puts the focus on security". Techcrunch.com. Retrieved 7 January 2018.
- ^ a b "OWASP ModSecurity Core Rule Set – The 1st Line of Defense Against Web Application Attacks". Coreruleset.org. Retrieved 7 January 2018.
- ^ ModSecurity Handbook. Retrieved 7 January 2018.
{{cite book}}:|website=ignored (help) - ^ "ModSecurity Version 3.0 Announcement". www.trustwave.com. Retrieved 12 September 2019.
- ^ "Lynx Browser? Banish 406 Not Acceptable Errors". Walt.gregg.juneau.ak.us. Retrieved 7 January 2018. This blog must be incorrect to say the motivation for the Lynx block was to stop the web server running a "Linux command", since the command to invoke Lynx does not start with a capital L as does the default user-agent string (and the block is case-sensitive).