Drupal and mod_security - Part Deux

If you have recently updated to the most recent mod_security RPM from Fedora and you are running Drupal, you've probably noticed that certain things don't work correctly. Most specifically, some of the system CSS pages and tabs look funny, and if you're using the pathauto module with the default URL aliases you are probably get a Forbidden (or HTTP 403) when you try to access your content.

It seems the new package uses the ModSecurity Core Rule Set 2.0.2 which adds a lot of new functionality and checks. It also blocks URLs with 'content' and 'system' in them which will cause CSS files not to be downloaded and some or all of your posts not to be able to be viewed.

We had to add a few exceptions to our ModSecurity local rules (in our case located in the file /etc/httpd/modsecurity.d/modsecurity_localrules.conf). Here are our Drupal specific rules:

# Drupal rules

# Drupal 6 ajax admin pages
SecRule REQUEST_URI ".*admin/build/views/ajax/.*" phase:1,log,pass,ctl:ruleEngine=Off
SecRule REQUEST_URI ".*admin/settings/gmap_location$" phase:1,log,pass,ctl:ruleEngine=Off

# Drupal System CSS pages
SecRule REQUEST_URI "/modules/system/.*" phase:1,log,pass,ctl:ruleEngine=Off

# Drupal node editing (FIXME - too loose. Tighten up)
SecRule REQUEST_URI "/node/.*/edit" phase:1,log,pass,ctl:ruleEngine=Off

# Fix some Drupal posting stuff in phpids (remove 'name' from regex)
SecRule REQUEST_BODY|REQUEST_URI_RAW|XML:/* "([^*:\s\w,.\/?+-]\s*)?(?\|])(\s*return\s*)?(?:hash|href|navigateandfind|source|pathname|close|constructor|port|protocol|assign|replace|back|forward|document|ownerdocument|window|self|parent|frames|_?content|date|cookie|innerhtml|innertext|csstext+?|outerhtml|print|moveby|resizeto|createstylesheet|stylesheets)(?(1)[^\w%\"]|(?:\s*[^@\/\s\w%,.+\-]))" "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,nolog,auditlog,msg:'Detects JavaScript object properties and methods',id:'phpids-local_17',tag:'WEB_ATTACK',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+20,setvar:tx.%{rule.id}-WEB_ATTACK-%{matched_var_name}=%{matched_var}"
SecRuleRemoveById phpids-17

# Remove tight security rule (prohibits http|ftp in comments forms)
SecRuleRemoveById 950117

NOTE: Watch the line wrapping. All the SecRules should be on one line.

These rules are probably WAY too lax and allow too much to happen so modify as appropriate to meet your security needs. Probably a better way is to only allow modifying of content from a restricted set of "known-safe" hosts and adding a SecRule based on those IP addresses (e.g. SecRule REMOTE_ADDR) so not just everyone can bypass the app firewall.

Hope this helps you out.

Happy App-firewalling,

Related Story: 

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.