Web Application Defender's Cookbook

Recipe 14-4: Restricting Geolocation Access Through Defense Condition (DefCon) Level Changes

This recipe shows you how to use ModSecurity to restrict which clients may access the application based on their geographic location.

Ingredients

• ModSecurity
  • SecGeoLookupDb directive
  • @geoLookup operator
  • setvar action

Manual DefCon Level Geolocation Restrictions

A vast majority of organizations are global and allow clients to access their applications from any geographic location around the world. When your application comes under attack, however, you may be forced to restrict access to specific regions. This type of response is useful when the organization wants to initiate a more restrictive Defense Condition Level when under a direct attack. The following rule shows an example of restricting geolocation access to U.S. clients when the DefCon level is set to 1:

SecAction "phase:1,t:none,nolog,pass,setvar:tx.defcon_level=1"
 
SecGeoLookupDb /path/to/apache/conf/base_rules/GeoLiteCity.dat
 
SecRule REMOTE_ADDR "@geoLookup" "phase:1,t:none,pass,nolog"
 
SecRule GEO:COUNTRY_CODE3 "!@streq USA" "chain,phase:1,t:none,
log,deny,msg:'Client IP not from USA'"
  SecRule TX:DEFCON_LEVEL "@streq 1"

This example works, but there’s a big challenge in effectively using the concept of DefCon level response actions with ModSecurity rules. You would have to initiate an Apache restart/reload for this new DefCon level variable data to be used. This becomes a real scaling challenge if you are protecting ...