Mod-Security
As you may have noticed, I am security person who use open-source technology to achieve security for my clients. So will give few basic recommendations regarding my favorite WAF tool.(it’s actually more than a WAF)
Modsecurity has 5 phases. 2 in Request 2 in Response and 1 in logging. Request and Response phase, you have full control to activate rules on. Logging you have no blocking control to activate, Which is normal behavior. So, you have 4 phases to work with modsecurity and logging phase you can give instruction about what to log.
Giving a detailed description of modsecurity is a book length task. This been an article will concentrate on most applied concept modsecurity with OWASP rule set.
GiBu GeorGe
Warning; Modsecurity 2.9.x works best with Apache, The latest version which is 3.x is created with improved integration with IIS and Nginx. If you are using IIS and Nginx use 3.x version. For this, article modsecurity version is 2.9.2 which is default for “Ubuntu 18.04” and OWASP rules(which is a dependency package for modsecurity) is version 3.2.
Installed modsecurity? Default doesn’t do anything. It has a global kill switch which can be set main configuration(modsecurity.conf) which is named
“SecRuleEngine DetectionOnly”
To disable the kill switch
SecRuleEngine On
For other configuration documentation, read through the modsecurity.conf, it is sort of “well documented”.
For the default rule action(behavior). If a rule, doesn’t specify an action can be set with.
SecDefaultAction "phase:1,log,auditlog,pass" SecDefaultAction "phase:2,log,auditlog,pass"
This default action can be overridden by rules or while using virtual patching, override is the default way of OWASP rule enforcement.
Third-Party Rules
Rules as I mentioned, OWASP rules is a dependency for Ubuntu modsecurity package. That means update of rules set is in the hands of package maintainer. This brings in uncertainty, If update happens and rules changes. I don’t like any unknown in my environment. So, what I would recommend is to downloading the rules from the OWASP git and loading the rules in Apache. Keep update of the rules under your change management.
Load the CRS setup which is main configuration file for OWASP rules(this includes should come first before rules include)
Include /etc/modsecurity/crs/crs-setup.conf
Now load the rules with wildcard or you can specify rule if you want granular control
Include /etc/modsecurity/rules/*.conf
You can use IncludeOptional to be safe. But I always use include as modsecurity is mandatory as far as I am concerned.
If everything works as expect for a week or so, Change SecRuleEngine from DetectionOnly mode to On in modsecurity.conf. If you don’t want CRS rules to block yet, still want to enable SecRuleEngine, Maybe want to test non CRS rules? You can set Anomaly scoring threshold to higher in crs-setup.conf.
SecAction \ "id:900110,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.inbound_anomaly_score_threshold=500,\ setvar:tx.outbound_anomaly_score_threshold=500"
Visibility on block, deny or any other action configured in the rules. In simple setup cases is, by using OSSEC modsecurity rule to sent email when a rule is matched. But make sure active response is not enabled or else OSSEC will block the client IP with iptables. You can configure modsecurity to change the logging so OSSEC can’t understand but sent the email any way. For centralized logging method modsecurity have a robust mcollect option.
Whitelisting CRS rules, CRS way
CRS provides 2 files with “.example” which can be used for whitelisting. Choice of naming used is important.
REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
This conf file is processed before any other rules. We can use ctl: to remove rules on runtime.
Basic rule
SecRule REQUEST_FILENAME "@endsWith /admin/comment.do" \
"id:3500,\
phase:2,\
pass,\
t:none,\
nolog,\
ctl:ruleRemoveTargetByTag=OWASP_CRS;ARGS:notes,\
ver:'AICDAD/0.0.1'"
RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
This conf file is processed after other rules.
# Remove Drupal App Specific Rulset SecRuleRemoveById 9001200-9001299 # Remove WordPress App Specific Ruleset SecRuleRemoveById 9002000-9002900 # Remove NextCloud App Specific Ruleset SecRuleRemoveById 9003000-9003500 # Remove Dokuwiki App Specific Ruleset SecRuleRemoveById 9004000-9004380 # Remove cPanel App Specific Ruleset SecRuleRemoveById 9005000-9005100 # Remove XenForo App Specific Ruleset SecRuleRemoveById 9006000-9006950 # Safe Allowlist SecRuleUpdateTargetByTag "OWASP_CRS" "!ARGS:g-recaptcha-response"
I would not recommend using CRS blindly. Yes, do take the logic and regular expression and others from CRS and implement it in own rules, In which every aspect of application it is protection is known, logged, tracked using persistence storage, geolocation, counters, environments. I am every time awed by the flexibility and control modsecurity give me.
Where I use CRS is in my few honey pot machines which is spread around geographical location, as a complement to my threat intelligence network.
GiBu GeorGe