ADMIN

Nuts and bolts
ModSecurity
SecRule &ARGS "!@eq 1"
SecRule ARGS_NAMES "!^statid$"
SecRule ARGS:statID "!^\d{1,3}$"
Three lines embedded in an Apache
location container state that valid
user requests for the statements_
full.asp file are only allowed to
have one argument (first rule) called
statid (second rule) with numbers
of one to three digits (third rule) as
their parameters. Any requests that
do not follow this pattern are cleaned
up by the default action, as defined in
SecDefaultAction. This would effectively
prevent an attacker exploiting
the SQL injection vulnerability.
No Inside Information
ModSecurity also filters outgoing
data, especially server responses to
incoming requests. The PHP programming
language throws error messages
such as this:
Fatal error: Connecting to MySQL server
'dbserv.example.com' failed
Although you can disable PHP error
messages in responses, Google still
lists a bunch of websites where PHP
error messages reveal many juicy details
of applications. This information
is very useful to an attacker, because
it can help them understand the internal
workings and structure of a web
application and attack it in a more
targeted way. To tell ModSecurity to
catch PHP error messages and prevent
them from being sent to users,
you can define a rule like this:
SecRule RESPONSE_BODY "Fatal error:"
RESPONSE_BODY refers to the content
of the server response to the client,
Listing 3: GeoIP Access
01 LoadModule geoip_module modules/mod_geoip.so
02 LoadModule security2_module modules/mod_security2.so
03 GeoIPEnable On
04 GeoIPDBFile /usr/tmp/GeoLiteCity.dat
05 SecRuleEngine On
06 SecGeoLookupDb /usr/tmp/GeoLiteCity.dat
07 SecRule REMOTE_ADDR "@geoLookup"
"chain,drop,msg:'Connection attempt from .CN!'"
08 SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"
and although it is not particularly elegant,
it does indicate what potential
you have. With a carefully crafted
regular expression, you can use the
same technique to prevent credit card
numbers from being revealed by, for
example, a compromised application
in the aftermath of a successful SQL
injection attack.
The Chinese Wall in Reverse
Another advanced scenario for Mod-
Security involves cooperating with
the GeoIP provider, Maxmind. GeoIP
locates users geographically on the
basis of their IP address, which
means you can restrict access to a
website to a specific region, such as
Pennsylvania – if you have a site in
Pennsylvanian Dutch that nobody
else would understand – or block
a country entirely. To do this, you
would install the mod_geoip2 module
on Apache 2, along with the GeoIP
software and GeoLiteCity.dat geographical
database [11].
Imagine a mechanical engineering
company in Germany’s Swabian
region that is afraid of industrial
espionage from the Far East; in this
case, they could use the configuration
in Listing 3 to prevent access
from China – if the people in China
didn’t spoof their origins. The last
two lines form a filter rule chain. Line
6 locates the geographical region for
the requesting IP address, then line
7 dumps the request and a message
into the logfile if the request comes
from China. This might not be politically
correct, but it is technically effective.
Full Insurance Coverage
ModSecurity has an enormous feature
scope, and it can take some time to
understand it completely. But if you
go to the trouble to plum the depths
of the module, it will pay dividends
with comprehensive methods that
give you additional protection against
attacks on web applications.
Thankfully, the prebuilt rulesets
make it easier to get started. And, the
vendor behind the project offers commercial
products and services such
as training. Armed with ModSecurity,
administrators can sit up tall in their
saddles, even if attackers are trying to
make their horses bolt.
n
Info
[1] OWASP Best Practices: Use of Web Application
Firewalls: [http:// www. owasp. org/​
index. php/ Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls]
[2] ModSecurity: [http:// modsecurity. org]
[3] ModSecurity Reference Manual:
[http:// modsecurity. org/ documentation/​
modsecurity‐apache/ 2. 5. 10/​
html‐multipage]
[4] ModSecurity Processing Phases: [http://​
www. modsecurity. org/ documentation/​
modsecurity‐apache/ 2. 5. 0/​
html‐multipage/ processing‐phases. html]
[5] ModSecurity Actions: [http:// www.​
modsecurity. org/ documentation/​
modsecurity‐apache/ 1. 9. 3/​
html‐multipage/ 05‐actions. html]
[6] ModSecurity Variables: [http:// www.​
modsecurity. org/ documentation/​
modsecurity‐apache/ 2. 1. 0/​
html‐multipage/ 05‐variables. html]
[7] Nikto: [http:// cirt. net/ nikto2]
[8] OWASP ModSecurity Core Rule Set Project:
[http:// www. owasp. org/ index. php/​
Category:OWASP_ModSecurity_Core_Rule_
Set_Project]
[9] ModSecurity blog, “Virtual Patching During
Incident Response: United Nations
Defacement”: [http:// blog. modsecurity.​
org/ 2007/ 08/ 27/]
[10] Talks by the UN General Secretary:
[http:// www. un. org/ apps/ news/ infocus/​
sgspeeches/]
[11] “Apache ModSecurity with GeoIP blocking
country specific traffic: ModSecurity +
GeoIP” by Suvabrata Mukherjee: [http://​
linuxhelp123. wordpress. com/ 2008/ 12/ 11/​
apache]
The Author
Sebastian Wolfgarten works as an IT Security
Expert with the European Central Bank as an
advisor, manager, and auditor of internal projects
designed to improve the security of the
IT infrastructure. Before this, he spent several
years working for Ernst & Young AG in Germany,
and as an Advisor for Information Security in
Ireland. He has also worked as an IT security
expert with T-Mobile Germany.
90 Admin 01 www.admin-magazine.com