Getting Started with ModSecurity Rules and the Transition to ModSecurity 3

By /

Introduction

As the digital world expands, so too does the need for robust and reliable security measures. One essential tool in the arsenal of every web administrator is a Web Application Firewall (WAF). A WAF is designed to protect web applications by monitoring and filtering HTTP traffic between a web application and the Internet. Amongst the numerous options available, ModSecurity has emerged as a popular open-source WAF solution due to its versatility and comprehensive rule sets.

ModSecurity enables real-time web application monitoring, logging, and access control. It uses a set of rules to decide which traffic to let through to your application and which to block. But what are these rules, and how are they crafted?

Common Techniques for Writing ModSecurity Rules

Let’s delve into some of the common techniques used when creating ModSecurity rules:

URI Matching: URI matching is used to apply rules to specific pages or sets of pages on your application. For instance, you might want to protect your login page from brute force attacks, so you would use URI matching to apply rules only to requests aiming at your login page.

Here is a simple rule to block POST requests to a login page:

SecRule REQUEST_URI "@beginsWith /login.php" \
"chain,id:'1000',deny"
SecRule REQUEST_METHOD "@streq POST"

User-Agent Matching: The User-Agent HTTP header field provides information about the software used by the original client. This is typically used by HTTP servers to serve appropriate content for different software. However, this information can also be used to block or limit requests from specific clients, as some malicious requests come with a specific User-Agent string.

To block requests from a specific user agent, you can use the following rule:

SecRule REQUEST_HEADERS:User-Agent "BadBot" \
"id:'1001',deny"

Counting Number of Requests: By tracking the number of requests from each IP address, you can detect and block IP addresses generating an unusually high number of requests, a typical sign of DDoS attacks or web scraping attempts.

You can use SecAction to count the number of requests and initcol to initialize a collection to hold the IP address related data. This example will block an IP if it makes more than 5 requests in a minute:

<LocationMatch "/">
    # Initialize IP address related data
    SecAction initcol:ip=%{REMOTE_ADDR},pass,nolog

    # If IP has more than 5 requests in the past minute, block
    SecRule IP:REQCOUNT "@gt 5" \
    "id:'1002',phase:2,deny,msg:'More than 5 requests in a minute.'"

    # If not blocked yet, increment the request count
    SecAction "phase:5,pass,nolog,setvar:ip.REQCOUNT=+1,expirevar:ip.REQCOUNT=60"
</LocationMatch>

IP Address Matching: You can block or limit requests based on their origin IP address. This is useful for blocking known malicious IPs, or limiting requests from specific countries or regions.

To block a specific IP address, you can use the following rule:

SecRule REMOTE_ADDR "@ipMatch 192.168.1.1" \
"id:'1003',deny"

Transition to ModSecurity 3 (LibModSecurity)

As technology evolves, so must our security tools. With the introduction of ModSecurity 3.x, also known as LibModSecurity, developers have addressed some of the limitations and issues encountered with the 2.x version. It’s important to know that ModSecurity 2.x is deprecated, meaning it’s no longer being updated or maintained.

ModSecurity 3.x offers a complete revamp of the ModSecurity architecture, improved performance, and better compatibility with modern web technologies. It is also designed to work seamlessly with NGINX and other popular web servers. The upgrade process will involve updating your ModSecurity software, revising and updating your rule sets, and extensive testing to ensure everything works as expected.

Plan your transition carefully. Use a testing environment to ensure your rules behave as expected in the new version. Collaborate with your security team to update your rule sets, considering new features and improvements available in ModSecurity 3.x. Finally, monitor your applications closely after the transition, to ensure everything is working as expected.

Conclusion

ModSecurity, with its powerful and flexible rule sets, provides robust protection for your web applications. Understanding how to craft and manage these rules is key to maximizing the potential of this versatile WAF. As you upgrade to ModSecurity 3.x, you will be able to take advantage of a more efficient, effective, and modern security solution. Stay proactive, learn continuously, and make sure your web applications are secure.

Scroll to Top