Implement Free WAF With ModSecurity and Owasp Core rule set (CRS) v3

5 min readDec 24, 2020

Today, Installing web application firewall (WAF) is a mandatory when you publish your web application on Internet. Yes this is a must to protect your production server against cyber attack, but in fact, some of the mid to low range companies have a budget constraint to implement WAF products, so I will share to you how to implement WAF freely with Mod Security and OWASP CRS and we are gonna use Centos as Operationg System.

ENABLE EPEL RPM

First you must enable EPEL repository.

For centOS 7 Run this command:

rpm -Uvh http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm

For centOS 6:

rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

INSTALLING MOD SECURITY

Then you must install mod_security apache module with predefined rules.

Run this command :

yum install mod_security mod_security_crs

Then You should edit the mod_Security configuration file at /etc/httpd/conf.d/mod_security.conf , look for the SecRuleEngine :

On — Rules are activated
Off — Rules are Deactivated
DetectionOnly — Only Intercepts and logs Transactions

Since we want to Intercept and Block Attacks we configure it with On.

SecRuleEngine on

After this, restart Apache service :

service httpd restart

To ensure that our web application firewall is working you should see something like this in Apache error logs.

tail /var/log/httpd/error_log[Wed Aug 15 10:35:14.915226 2018] [:notice] [pid 27094] ModSecurity: APR compile                                                                                                                     d version="1.4.8"; loaded version="1.4.8"
 [Wed Aug 15 10:35:14.915232 2018] [:notice] [pid 27094] ModSecurity: PCRE compil                                                                                                                     ed version="8.32 "; loaded version="8.32 2012-11-30"
 [Wed Aug 15 10:35:14.915236 2018] [:notice] [pid 27094] ModSecurity: LUA compile                                                                                                                     d version="Lua 5.1"
 [Wed Aug 15 10:35:14.915239 2018] [:notice] [pid 27094] ModSecurity: LIBXML comp                                                                                                                     iled version="2.9.1"

Sometimes you found that secstatusengine disabled by default.

[Wed Aug 15 10:35:14.915242 2018] [:notice] [pid 27094] ModSecurity: Status engine is currently disabled, enable it by set SecStatusEngine to On.

To solve this issue add this line on your /etc/httpd/conf.d/mod_security.conf

SecStatusEngine on

Then restart your apache service

service httpd restart

Run this command again to ensure all the configuration are working :

tail /var/log/httpd/error_log[Wed Aug 15 10:38:35.479348 2018] [:notice] [pid 27622] ModSecurity: PCRE compiled version="8.32 "; loaded version="8.32 2012-11-30"
 [Wed Aug 15 10:38:35.479351 2018] [:notice] [pid 27622] ModSecurity: LUA compiled version="Lua 5.1"
 [Wed Aug 15 10:38:35.479353 2018] [:notice] [pid 27622] ModSecurity: LIBXML compiled version="2.9.1"
 [Wed Aug 15 10:38:35.479390 2018] [:notice] [pid 27622] ModSecurity: StatusEngine call: "2.9.2,Apache/2.4.6 (CentOS),1.4.8/1.4.8,8.32/8.32 2012-11-30,Lua 5.1,2.9.1,56"
 [Wed Aug 15 10:38:36.202229 2018] [:notice] [pid 27622] ModSecurity: StatusEngine call successfully sent. For more information visit: http://status.modsecurity.org/

They are some important files to remember in mod security

Mod Security Config File — /etc/httpd/conf.d/mod_security.conf
Debug Log — /var/log/httpd/modsec_debug.log
Audit log — /var/log/httpd/modsec_audit.log
Rules — /etc/httpd/modsecurity.d/activated_rules

In this step you already successfully install WAF using Mod Security, next step we also need to install Owasp Core rule set (CRS)

Installing Owasp Core rule set (CRS) v3

The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity. We can say this is the core engine of WAF, because it provides protection against many common attack categories, including SQL Injection, Cross Site Scripting, Locale File Inclusion, etc

In this scenario we use Owasp Core rules set (CRS) v3. First download CRS v3 on SpiderLabs git

sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs

The command above will create new owasp-modsecurity-crs directory, then you should move owasp-modsecurity-crs folder to modsecurity.d folder :

sudo mv owasp-modsecurity-crs /etc/httpd/modsecurity.d/

De-activate the default CRS by giving the # on the lines, then add new line of crs v3 configuration:

# New Owasp CRS v2Include modsecurity.d/owasp-modsecurity-crs/crs-setup.conf
Include modsecurity.d/owasp-modsecurity-crs/rules/*.conf# Default CRS (deactivated)
# IncludeOptional modsecurity.d/*.conf
# IncludeOptional modsecurity.d/activated_rules/*.conf

Ensure your configuration should be like this:

<IfModule mod_security2.c>
    # ModSecurity Core Rules Set configuration        Include modsecurity.d/owasp-modsecurity-crs/crs-setup.conf
        Include modsecurity.d/owasp-modsecurity-crs/rules/*.conf        #IncludeOptional modsecurity.d/*.conf
        #IncludeOptional modsecurity.d/activated_rules/*.conf    # Default recommended configuration
    SecRuleEngine On
    SecStatusEngine on    SecRequestBodyAccess On
    SecRule REQUEST_HEADERS:Content-Type "text/xml" \
         "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
    SecRequestBodyLimit 13107200
    SecRequestBodyNoFilesLimit 131072
    SecRequestBodyInMemoryLimit 131072
    SecRequestBodyLimitAction Reject
    SecRule REQBODY_ERROR "!@eq 0" \
    "id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
    SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
    "id:'200002',phase:2,t:none,log,deny,status:44,msg:'Multipart request body \
    failed strict validation: \
    PE %{REQBODY_PROCESSOR_ERROR}, \
    BQ %{MULTIPART_BOUNDARY_QUOTED}, \
    BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
    DB %{MULTIPART_DATA_BEFORE}, \
    DA %{MULTIPART_DATA_AFTER}, \
    HF %{MULTIPART_HEADER_FOLDING}, \
    LF %{MULTIPART_LF_LINE}, \
    SM %{MULTIPART_MISSING_SEMICOLON}, \
    IQ %{MULTIPART_INVALID_QUOTING}, \
    IP %{MULTIPART_INVALID_PART}, \
    IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
    FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"    SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
    "id:'200003',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"    SecPcreMatchLimit 1000
    SecPcreMatchLimitRecursion 1000    SecRule TX:/^MSC_/ "!@streq 0" \
            "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"    SecResponseBodyAccess Off
    SecDebugLog /var/log/httpd/modsec_debug.log
    SecDebugLogLevel 0
    SecAuditEngine RelevantOnly
    SecAuditLogRelevantStatus "^(?:5|4(?!04))"
    SecAuditLogParts ABIJDEFHZ
    SecAuditLogType Serial
    SecAuditLog /var/log/httpd/modsec_audit.log
    SecArgumentSeparator &
    SecCookieFormat 0
    SecTmpDir /var/lib/mod_security
    SecDataDir /var/lib/mod_security
</IfModule>

Next, you must rename crs-setup.conf.example to crs-setup.conf on owasp-modsecurity-crs folder :

sudo mv /etc/httpd/modsecurity.d/owasp-modsecurity-crs/crs-setup.conf.example /etc/httpd/modsecurity.d/owasp-modsecurity-crs/crs-setup.conf

Then if you can see all rules of CRS v3 in /etc/httpd/modsecurity.d/owasp-modsecurity-crs/rules/ directory.

If you want to disable the rules just rename it. For example :

sudo mv /etc/httpd/modsecurity.d/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf /etc/httpd/modsecurity.d/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf.disable

The command above will disable rule REQUEST-920-PROTOCOL-ENFORCEMENT. To make a change you must restart the httpd service

sudo service httpd restart

This is final step, now you can test your Modsecurity with the CRS by input some simple attack like sql injection to your web page.

And if everything fine, you will see the something like this on the response page.

Congratulations you already installing WAF on your web application server with free. This is important for you to modify the rules so it can be suitable with your web application need, because some rule maybe have a conflict with your web application, WAF may able to block your web application request / response.

OK that’s all, hope this useful for you, any questions feel free to mail me.

or contact me on my linkedin page

Implement Free WAF With ModSecurity and Owasp Core rule set (CRS) v3

ENABLE EPEL RPM

INSTALLING MOD SECURITY

Installing Owasp Core rule set (CRS) v3

Written by Mfadly N