Savannah W-ITS

I previously posted about using the mod_geoip Apache module to control web access via .htaccess files or server configuration adjustments (i.e. editing httpd.conf.)   Here we are adding the mod_security Apache module into the mix.

Wait!  if we can control access via mod_geoip why do we need mod_security?

The simple answer is….  you don’t need it – but it does provide some additional options for managing web server access.   The longer answer is that mod_security provides:

• additional levels of control (if desired)
• rules can actually be simpler that changing httpd.conf or creating .htaccess files where you need both ‘allow/deny’ setups as well as declaring your allowed/denied GeoIP locations

##### ##### ##### #####
SecGeoLookupDb /path-to-data/GeoIP/GeoIP.dat
##### ##### ##### #####
# these rules work in pairs - 1st rule sets the 'action'
# second rule specifies where were are looking for ('CN')
##### ##### ##### #####
# use the rule below to 'drop' all connections from 'CN'
# SecRule REMOTE_ADDR "@geoLookup" "chain,drop,msg:'BD_CNTRY: China'"
# SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"
##### ##### ##### #####
# the rule below would re-direct any connection from a
# matching COUNTRY_CODE
SecRule REMOTE_ADDR "@geoLookup" "chain,redirect:/some_special_URL/,status:403,msg:'BD_CNTRY: China'"
SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"
##### ##### ##### #####
# the rule below would LOG any connection from a
# matching COUNTRY_CODE
SecRule REMOTE_ADDR "@geoLookup" "chain,log,msg:'BD_CNTRY: China'"
SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"
####----------------------------------------------------------###

After some testing I found that mod_security was yielding some false positives when using @geolookup.  As when implementing other access related server changes testing is encouraged – with mod_security you can test by changing the rule impact to ‘log only’; you follow-up by reviewing and confirming that all is well.  In my case I found that some connections were being logged as coming from two geo-locations – clearly something is/was not correct since some connections were allowed and some denied by mod_security.  There are quite a number of possible causes for this type of issue so I will be in test-mode until satisfied with this approach.

One of the nice features of mod_security is that you can limit rules to specific contexts, i.e. to specific virtual hosts or specific locations (i.e. folders) on your server – you may also be able to limit other Apache modules in a similar fashion.  A simple example:

<Location /feedback.php>
   ##### ##### ##### #####
   # the rule below would DROP any connection to this page from a
   # matching COUNTRY_CODE
   SecRule REMOTE_ADDR "@geoLookup" "chain,drop,msg:'BD_CNTRY: China'"
   SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"
</Location>

The above limits the GeoIP access restriction to a specific page – this may make more sense than blocking all access to your site.   You could extend to this approach to all sections of your site that allow user input (but it might be simpler to add a GeoIP-tool-call to your code, i.e. write one function and simply call as needed – see related posts for a PHP example; combining GeoIP lookups with Captcha may significantly reduce your web SPAM…)

Related posts:

1. GeoIP Blocking – examples for Apache The GOOD news – using the GeoIP module (mod_geoip.c.) can...
2. Apache & mod_security – resolving false positives I recently found that some users could not access this...
3. Apache – mod_security – web application firewall ModSecurity is a web application firewall (WAF) for the Apache...
4. Apache – mod_security logging options Resolving a small problem with debug logging when using the...
5. It happened to Google – are you next? Well, it happened to Google (and a number of other...