Introducing mod_security

Listen Print Discuss

by Ivan Ristic
11/26/2003

Running public web applications may seem like playing Russian roulette. Although achieving robust security on the Web is possible in theory, there's always a weak link in real life. It only takes one slip of the code to allow attackers unrestricted access to your data. If you have a public web application of modest complexity running, chances are good that is has some kind of security problem. Take this URL for example:

http://www.webapp.com/login.php?username=admin';DROP%20TABLE%20users--

If your application is vulnerable to SQL injection, invoking the URL above may very well delete all user data from your application. Do you make regular database backups?

Fortunately, the mod_security Apache module can protect you from this and other forms of web attacks.

Why Would You Use mod_security?

A year and a half ago, before I started working on mod_security, I used Snort to monitor my web traffic. It worked very well; I told Snort which keywords I was interested in and it alerted me every time one appeared in the data stream. But I wanted more. I wanted the freedom to specify complex rules and perform various HTTP related actions. Besides, having an IDS installed wherever a web server exists is very time consuming and expensive.

At the time I also tried the combination of mod_rewrite and mod_setenvif. Using mod_rewrite it is very easy to detect the words drop and table, and then redirect the client away from the original URL, preventing the attack. However, while that would certainly keep away less knowledgeable attackers, a determined attacker could simply invoke the same URL as above but use the POST method instead of GET. Since POST variables are not considered in the normal processing of most modules, the attack would go through.

Having established the need to build a new tool, I faced two choices: go with Java and create a full-blown reverse proxy and application gateway application, or create an Apache module, building on top of a large amount of existing code. Option one would require a lot of work and probably result in something very few people would want to use (hey, I wouldn't use it either). I wanted to build something flexible and easy to use, so I chose the latter. I've never looked back.

Going back to our URL example, to prevent the "drop table" SQL injection attack with mod_security, add the following to your Apache configuration:

SecFilter "drop[[:space:]]table"

The only parameter is a regular expression to be applied to the incoming request. This seems achievable with mod_rewrite, but the difference here is that mod_security will detect and prevent attacks performed using either GET or POST. As it turns out, adding the ability to monitor POST requests was a very big problem for Apache 1.3.x since it does not support a notion of filters.

Installation and Configuration

The best way to install mod_security is to compile it from the source code (or, if you are running Apache on Windows and don't have a compiler around go to the web site and download a pre-compiled dll):

$ /path/to/apache/bin/apxs -cia mod_security.c
# /path/to/apache/bin/apachectl stop
# /path/to/apache/bin/apachectl start

Before you do that you need to add few lines to the configuration file:

<IfModule mod_security.c>
    # Turn the filtering engine On or Off
    SecFilterEngine On
    
    # Make sure that URL encoding is valid
    SecFilterCheckURLEncoding On
    
    # Unicode encoding check
    SecFilterCheckUnicodeEncoding Off
    
    # Only allow bytes from this range
    SecFilterForceByteRange 0 255
    
    # Only log suspicious requests
    SecAuditEngine RelevantOnly
    
    # The name of the audit log file
    SecAuditLog logs/audit_log
    # Debug level set to a minimum
    SecFilterDebugLog logs/modsec_debug_log    
    SecFilterDebugLevel 0
    
    # Should mod_security inspect POST payloads
    SecFilterScanPOST On
    
    # By default log and deny suspicious requests
    # with HTTP status 500
    SecFilterDefaultAction "deny,log,status:500"
    
</IfModule>

I've left the comments in the code so it should be pretty evident what directives do. This configuration will activate mod_security but it won't do much. It is always a good idea to start with a relaxed configuration and build into a more restrictive one.

So What Does this Do?

Even with the relaxed configuration, mod_security will still provide two benefits. First, it will perform a series of anti-evasive techniques and will canonicalize the input. This will help later when you start adding filtering rules to the configuration. Imagine you want to prevent people from executing a ps binary on the server, using a regular expression such as /bin/ps ax. This expression would catch simple invocations but perhaps not /bin//ps ax or /bin/ps%20ax or /bin/./ps ax. Here is a list of what mod_security does here:

Remove multiple forward slashes (//).
Remove self-referenced directories (./).
Treat \ and / equally (on Windows only).
Perform URL decoding.
Replace null bytes (%00) with spaces.

I am also thinking about replacing all consecutive white space characters with spaces, but I am not yet sure about it.

The other benefit comes from certain built-in checks:

URL encoding validation.
Unicode encoding validation.
Byte range verification, where only certain character values are allowed as part of a request.

Actions

Whenever a rule match occurs a series of actions is performed. The default action list (configured through SecDefaultAction) is used in most cases. It is also possible to specify per-rule actions by supplying a second parameter to SecFilter or a third parameter to SecFilterSelective. Supported actions are:

deny, deny the request
allow, stop rule processing and allow the request
status:nnn, respond with a HTTP status nnn
redirect:url, redirect the request to the absolute URL url
exec:cmd, execute a script cmd
log, log the request to the error log
nolog, do not log the request
pass, ignore the current rule match and go to the next rule
pause:nnn, stall the request for nnn milliseconds. Be very careful with this action; one Apache instance will be busy stalling the request. You could actually help the attackers in creating a denial of service attack.

Other actions affect the flow of the rules, similarly to how mod_rewrite works:

chain, go to evaluate the next rule in the chain. When one rule fails to trigger an alert the remaining rules from the chain will be skipped.
skipnext:n, skip the next n rules.

Filtering Rules

Rules come in two flavors. In the simplest form,

SecFilter keyword

will apply the keyword (a regular expression) to the first line of the incoming request (the one that looks like GET /index.php HTTP/1.0) and to the POST payload if it exists. It is a pretty broad rule whose purpose is mostly to be used as a first step when rules are introduced in articles like this one. You should instead use:

SecFilterSelective "variable list separated with |" keyword

as it allows much better control over what should be analysed (and spends less CPU cycles doing it). Instead of continuing to bore you with the syntax I will now present a series of interesting examples. Let them serve as inspiration; the most useful rules usually come from dealing with real-world problems.

This rule will allow all requests from a single IP address (representing my workstation) through. No other rules will be processed. Since such requests do not represent attacks this rule match will not be logged:

SecFilterSelective REMOTE_ADDR "^IP_ADDRESS_HERE$" nolog,allow

This rule allows me full access from my laptop when I am on the road. Because I don't know what your IP address will be, access is granted to all clients having a string Blend 42 in the User-Agent field. This is poor protection on its own but can be pretty interesting on top of some other authentication method.

SecFilterSelective HTTP_USER_AGENT "Blend 42"

This rule prevents SQL injection in a cookie. If a cookie is present, the request can proceed only if the cookie only contains one to nine digits.

SecFilterSelective COOKIE_sessionid "!^(|[0-9]{1,9})$"

This rule requires HTTP_USER_AGENT and HTTP_HOST headers in every request. Attackers often investigate using simple tools (even telnet) and don't send all headers as browsers do. Such requests can be rejected, logged, and monitored.

SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"

This rule rejects file uploads. This is simple but effective protection, rejecting requests based on the content type used for file upload.

SecFilterSelective "HTTP_CONTENT_TYPE" multipart/form-data

This rule logs requests without an Accept header to examine them later; again, manual requests frequently do not include all HTTP headers. The Keep-Alive header is another good candidate.

SecFilterSelective "HTTP_ACCEPT" "^$" log,pass

This rule will send me an email when the boss forgets his password again. We have two rules here. The first will trigger only when one specific file is requested (the one showing the "Login failed" message. The second rule will then check to see if the username used was ceo. If it was, it will then execute an external script.

SecFilterSelective REQUEST_URI "login_failed\.php" chain
SecFilterSelective ARG_username "^ceo$" log,exec:/home/apache/bin/notagain.pl

This rule sends Google back home by redirecting Googlebot somewhere else, based on the User-Agent header. It does not log rule matches.

SecFilter HTTP_USER_AGENT "Google" nolog,redirect:http://www.google.com

This rule checks all variables for JavaScript, allowing it in a variable named html. Disallowing JavaScript in all variables can be very difficult for some applications (most notably CMS tools). By using this rule we disallow JavaScript in all variables except in the one named html, where we know it can appear.

SecFilter "ARGS|!ARG_html" "<[:space:]*script"

Finally, this example shows how you can have multiple mod_security configurations. This means you can tailor rules for a specific application. Note the usage of the directive SecFilterInheritance. With it we tell mod_security to disregard all rules from the parent context and start with a clean slate.

<Location /anotherapp/>
    SecFilterForceByteRange 32 126
    # Use this directive not to inherit rules from the parent context   
    SecFilterInheritance Off
    
    # Developers often have special variables, which they use
    # to turn the debugging mode on. These two rules will
    # allow the use of a variable "debug" but only coming from
    # the internal network
    SecFilterSelective REMOTE_ADDR "!^192.168.254." chain
    SecFilterSelective ARG_debug "!^$"
</Location>

Performance Considerations

I have never had any performance problems with mod_security. In my performance tests the speed difference was around 10 percent. However, the practical performance penalty is smaller. On real web sites, a single page request may provoke many static requests for images, style sheets, and JavaScript libraries. Mod_security is smart enough not to look at those only if you tell it not to:

SecFilter DynamicOnly

The bottleneck is always in the IO operations. Make sure that the debugging mode is never turned on on a production server, and avoid using the full audit logging mode unless you really need to. In the configuration above, mod_security is configured to only log relevant requests, e.g., those that have triggered a filter.

Other Features

Internal `chroot`

If you have ever tried to chroot a web server you probably know that it is sometimes a complex task. With mod_security the complexity goes away. You are one configuration directive away from a chrooted server:

SecChrootPath /chroot/home/web/apache

The only requirement is that the web server path in the chroot be the same as the path outside of the chroot (in the example above, /home/web/apache). In addition to making chrooting very easy, this approach will allow you to have a chroot that contains only data files without binaries. This advantage comes from the fact that the chroot call is executed internally, after all the dynamic libraries are loaded and log files opened.

Changing Server Signature

Attackers and automated scripts frequently learn about the server and the version from the "Server" HTTP header that is delivered with every response. You can change only change this by changing the Apache source code, but you can also use this directive. (You should use this feature only if you're running Apache 1.x. Module mod_headers included with Apache 2.x should be able to intercept outgoing headers, and change them on the fly):

SecServerSignature "Microsoft-IIS/5.0"

What Next?

Although I compared mod_security to Snort at the beginning of this article, mod_security is just another tool in your security belt. It works best together with an IDS operating on a network level. Its biggest advantage is in filling the gap between the web server and the application, allowing you to protect your applications without actually touching the source code.

While you are reading this article I am busy working on a couple of new and very interesting features. First of all, I want to complete multipart/form-data encoding support. Once that is done, you will be able to intercept file uploads and run checks on files (using external binaries), with an option to reject them for any reason. Even more interesting is a feature called a "Application Armour," a special form of application lockdown where for each script you will be able to specify and verify every incoming parameter (you won't need to do it manually, don't worry).

In the meantime, please send me your comments and requirements to influence the way mod_security develops.

References

Ivan Ristic is a Web security specialist and the author of ModSecurity, an open source intrusion detection and prevention engine for web applications, and the author of O'Reilly's Apache Security.

Return to Apache DevCenter.

Have a question about the features or uses of mod_security? Ask Ivan here.
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 34 of 34.

mod_security configuration
2009-07-06 12:59:17 paes [Reply | View]

Hello, I am getting this error and I dont know how to bypass mod_security in order this program works.
Is there a way? an .htaccess or so?

thank you in advance.

[Mon Jul 06 16:28:49 2009] [error] [client 2XX.1XX.XX.XXX] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "689"] [id "340162"] [rev "162"] [msg "Remote File Injection attempt in ARGS (AE)"] [data ""] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/" against "MATCHED_VAR" required. [hostname "www.xxxxxxxx.com"] [uri "/agenda/admin/components/SettingsGeneralAction.php"] [unique_id "g-PHScgxmGQAAFyzTREAAAAH"]

mod_security configuration
2009-07-06 12:58:47 paes [Reply | View]

Hello, I am getting this error and I dont know how to bypass mod_security in order this program works.
Is there a way? an .htaccess or so?

thank you in advance.

[Mon Jul 06 16:28:49 2009] [error] [client 2XX.1XX.XX.XXX] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "689"] [id "340162"] [rev "162"] [msg "Remote File Injection attempt in ARGS (AE)"] [data ""] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/" against "MATCHED_VAR" required. [hostname "www.xxxxxxxx.com"] [uri "/agenda/admin/components/SettingsGeneralAction.php"] [unique_id "g-PHScgxmGQAAFyzTREAAAAH"]

Mod_Security2 Configuration
2008-09-27 15:59:39 selecta [Reply | View]

Can you please guide me in using the SecRule to prevent especially SQL injection attacks. I am a new learner to Mod_Security

Mod_Security2 Configuration
2008-10-03 11:25:05 Ivan Ristic | [Reply | View]

You don't have to look far: a set of rules designed to detect SQL injection are already included with ModSecurity through the bundled Core Rules package.

Problem with host
2007-10-18 07:42:24 dogheart [Reply | View]

I've been getting an error (404, not 406 for some reason) from an admin script on a site I'm developing on a shared server. The user edits the contents of a page in a large textarea, which is POSTed to the server and, unless they click 'cancel', processed in the MySQL database. Certain pages have been triggering the error consistently and it's been baffling me for months. I've finally got out of the host's support department this entry (edited for privacy) from their log:

"(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\\\(.*from)" at ARGS:page_text. ... [msg "Generic SQL injection protection"]

...and they pointed me to the mod_security page for reference.

Before I go back and shout at them, isn't this a misapplication of mod_security? It seems to me that there can be no way of telling when a user is perfectly innocently going to type something like '... select ... from ...'. Not only that but their regex is suspect because in a couple of my cases it's catching 'selecting'. It's also catching instances where the 'select' and the 'from' are several lines apart, and yet I've always understood the regex '.' to stand for any character apart from a newline - no?

Other than jumping through hoops with JavaScript - which goes against the grain anyway as non-JS-enabled users will still get trapped - there's nothing I can do to intervene between the data being POSTed and its being trapped by mod_security... is there?

I'd be grateful for any advice as to what I should say to the host. It's their 'new' (well, newish) platform that this site is running on, and I suspect they've only recently installed mod_security.

problem turning off rule selectively
2007-10-07 12:56:51 SalemDesign [Reply | View]

I am implementing a PHP web application on a shared hosting environment. The hosting service has implemented mod_security.

Unfortunately, some of the PHP in the app (a fairly popular shopping cart) is triggering mod_security when I try and save any settings in the cart admin interface.

With mod_security running, any time I try and save a change in the shopping cart admin interface, I get a 406 Not Acceptable error message.

And when I asked the hosting sevice to look in the logs, they found the following:

mod_security-action: 406
mod_security-message: Access denied with code 406. Pattern match "/bin/" at POST_PAYLOAD

And turning off mod_security using "SecFilterEngine off" allows us to save settings without any problem.

We didn't want to turn off mod_security entirely so we tried:

SecFilterEngine on
SecFilterSelective "POST_PAYLOAD" "/bin/" "allow,nolog"

But we still got the 406 Not Acceptable message.

The hosting service suggested:

SecFilterEngine on
SecFilterSelective ARGS "/bin/" "allow,nolog"
SecFilterSelective ARGS "/usr/bin/" "allow,nolog"

But than didn't work either. Obviously you cannot debug individual implementations but if you can see anything in our syntax that is incorrect, it would be appreciated. Or if there is some reason why this would not work in .htaccess?

TIA,
Doug/SalemDesign

mod security versions ass/ apache version
2007-07-31 07:13:47 Safari-DM [Reply | View]

Is there a table listing with the following information:
(1) mod security version
(2) apache version (1) is used with
(3) availability of (1) and (2) for HP-UX and Windows
(4) Download site where (3) may be found.

mod_security with OAS
2006-11-15 07:33:08 mclaugb [Reply | View]

Hi.

Can anyone confirm if mod_security works against Oracle Application Server v9.0.4?

Thanks,

Brian

mod_security2 and SecRule
2006-10-31 08:45:33 monicat [Reply | View]

Any body know how to get SecRule to work with mod_security2.c ? I kept on getting this error message when I start my apache-2.2.3 server:
...
[truong@gendev-lnx 2.2.3]$ ./restart
Syntax error on line 41 of /home/truong/apache/2.2.3/conf/hole/mod_security2.conf:
Internal Error: Failed to add rule to the ruleset.
httpd not running, trying to start
...

And here is line 41 of my mod_security.conf file:
...
39 # Turn on Rule Engine
40 SecRuleEngine On
41 SecRule REQUEST_URI dirty
...

Is there something I have to turn on (e.g SecFilterEngine On) ?

Thanks for your help.

mod_security2 and SecRule
2006-10-31 08:55:03 Ivan Ristic | [Reply | View]

Hmm, your configuration works for me here. Can I suggest you try two things? First upgrade to 2.0.4-dev1 and try again. If that does not work please join us on the mod-security-users mailing list (see here https://lists.sourceforge.net/lists/listinfo/mod-security-users).

Re: My SecRule does not work on mod_security2.c
2006-11-02 07:31:07 monicat [Reply | View]

Ivan, I search at the site you suggested but did not find any solution to my problem.I'm not sure if it help if I include the entire configuration file. Please see below:

<IfModule mod_security2.c>
#
# Basic configuration options
#
# Server masking is optional
SecServerSignature "Microsoft-IIS/5.0"

# Maximum request body size we will
# accept for buffering
SecRequestBodyAccess On
SecRequestBodyLimit 131072
# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072

# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyAccess Off
SecResponseBodyLimit 524288

# Debug log
SecDebugLog logs/modsec_debug.log
SecDebugLogLevel 9

# The audit engine works independently and
# can be turned On of Off on the per-server or
# on the per-directory basis
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial

# The name of the audit log file
SecAuditLog logs/modsec_audit.log

# Default action set
SecDefaultAction "deny,log,auditlog,status:403"

# Turn on Rule Engine
SecRuleEngine On
SecRule REQUEST_URI dirty

# Refuse to accept POST requests that do
# not specify request body length
# SecRule REQUEST_METHOD ^POST$ chain
# SecRule REQUEST_HEADER:Content-Length ^$
</IfModule>

Any help is appreciated.
- Monicat

issue with mod_security2
2006-10-30 10:31:56 monicat [Reply | View]

Hi, I install/compile mod_securiy Version 2.0.2 as a DSO to work with apache-2.2.3 and I could not get mod_security to work.

After untar the the tar ball,
$cd modsecurity-apache_2.0.2/apache2

Edit the Makefile to update tpp_dir to my apache tree:
top_dir = /home/truong/apache/2.2.3

Then I do the make but got error complain about file pcre.h missing so I copy the /usr/include/pcre/pcre.h into modsecurity-apache_2.0.2/apache2 and redo the make and it works fine. I stop apache and go ahead and did the make install. Add this line into httpd.conf:
...
LoadFile /usr/lib/libxml2.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
...
Include conf/hole/mod_security2.conf
...
And create a security's confile as follow:

$ cat conf/hole/mod_security2.conf
<IfModule mod_security.c>
# Server masking is optional
SecServerSignature "Microsoft-IIS/5.0"
</IfModule>

restart the server and access some bogus file but the Server Signature still said "Apache/2.2.3 (Unix) Server at gendev-lnx Port 9090" instead of "Microsoft-IIS/5.0".

I think there is something wrong with the way I compile mod_security or something is not working right on my linux system (
Linux gendev-lnx 2.4.21-37.0.1.ELhugemem #1 SMP Wed Jan 11 18:35:52 EST 2006 i686 i686 i386 GNU/Linux)
because mod_security did not work at all even thought the apache's server did indidate this in the errorlog:
....
[Mon Oct 30 12:57:10 2006] [notice] ModSecurity for Apache 2.0.2 configured
[Mon Oct 30 12:57:12 2006] [notice] Apache/2.2.3 (Unix) configured -- resuming normal operations
...
Anyone have any other to test mod_security to see if it working correctly?

issue with mod_security2
2006-10-30 12:29:38 monicat [Reply | View]

I found the fix for this:

Change <IfModule mod_security.c>
to
<IfModule mod_security2.c>

and it works like a charm!
- Monica

issue with mod_security2
2007-02-05 02:09:07 shuvo70 [Reply | View]

Hi

I have installed modsecurity-apache2-2.0.3-1 rpm at centos-4.4 server. my apache version is httpd-2.0.52-28.ent.centos4
i cant see any log at /var/log/modsec_audit.log can you please tell what is wrong.

here is the basic configuration file under /etc/httpd/conf.d/modsecurity.conf

<IfModule mod_security.c>
#SecRuleEngine On
SecFilterEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off
SecFilterCheckCookieFormat On
SecFilterScanPOST On
SecFilterForceByteRange 0 255
SecUploadDir /tmp
SecUploadKeepFiles Off
SecAuditEngine RelevantOnly
SecAuditLog /var/log/httpd/modsec_audit.log
SecFilterDebugLog /var/log/httpd/modsec_debug.log
SecFilterDebugLevel 0
SecFilterDefaultAction "deny,log,status:406"
SecFilterSelective REMOTE_ADDR "^127.0.0.1$" nolog,allow
</IfModule>

i tried to change as per your mail ifModule mod_security2.c but that time httpd cant start.

what could be the problem

issue with mod_security2
2007-02-07 11:26:00 Ivan Ristic | [Reply | View]

That configuration is for ModSecurity 1.9.x. ModSecurity 2.x uses different syntax. There's an example configuration included with distribution, along with the manual. BTW, you are more likely to get answers on the mod-security-users list.

filettering php shell Scripts
2006-02-21 09:58:35 ALDWLYA [Reply | View]

dear sirs,

is there any way , idea , function ... to put it into a .htaccess file .. to check a file content when somone request that file from the web ????

If somone hacked a web site and uploade a PHP shell ... of course he will request it via

the web like http://site.com/phpshell.php

here i want to someting to check that phpshell contente ... if it finde a shell script ..

it's prevent it displaying via the web .. if itsn't a shell script .. it's allow for its request and display the file content ..

waiting foe early replay ..

and I'm so sorry for my bad English

thanks & best regards ..

filettering php shell Scripts
2006-02-24 09:05:09 Ivan Ristic | [Reply | View]

Inspecting a file before it is executed shouldn't be difficult. The best approach is probably to use a custom Apache module configured to execute just before PHP (in your case) execution takes place. It would scan the target script and refuse to run if it detects something inappropriate.

Relationship with gateway? Embedded firewall vs. gateway
2004-12-22 16:07:13 Meshfire [Reply | View]

I am thinking the pros and cons of embedded web application firewalls vs. web application security gateway firewalls. Embedded firewalls are on the same machine as the servers, so a crash or some problem will affect the servers directly, while gateway firewalls are on a separate machine so the crash will not affect the Web servers. Also, a gateway can be plugged and play, but embedded firewalls still need to be installed, which is extra burden. -by Meshfire

Relationship with gateway? Embedded firewall vs. gateway
2005-01-24 12:50:07 vippi-va-voom [Reply | View]

>while gateway firewalls are on a separate machine so the crash will not affect the Web servers.

The gateway/firewall will stop the http server no matter where it is, when it crashes. It does affect the web server, though indirectly.

Tracking stateful session information is important for Web application security firewall appliance
2004-12-18 16:00:19 Meshfire [Reply | View]

because some users may log in and stay online for a long time, and the stateful session data may accumulate to a large size. Also, I think Web application firewalls for LAMP (linux apache Perhl/PHP/Python) is also worth working on for security since many companies are use LAMP by Meshfire .

Brave work! ----- from Roboo
2003-12-11 17:08:49 anonymous2 [Reply | View]

I think you just focus on C/C++ version. There are too many Java servers and you have to write many plug-ins for them if you support Java, then you do not have enough time to split. - Roboo

Brave work! ----- from Roboo
2003-12-15 16:29:27 anonymous2 [Reply | View]

Interesting. How do you justify that demand for Java version is little? Supposedly the Java application servers are the mojority in enterprise applications. The list if long: WebLogic, WebSphere, iAS, SunONE, Tomcat, ... -Roboo

Brave work! ----- from Roboo
2003-12-12 06:11:17 Ivan Ristic | [Reply | View]

As a matter of fact some time ago I built a proof of concept version of ModSecurity in Java. In some respects it is better than the original (eg more modular, supports stateful actions). The good thing about Java is that request filters are a part of the core Servlet specification, therefore ModSecurity/Java works on all Java Web servers equally.

Because there was very little interest for a Java version of ModSecurity I never posted it on the site. Eventually, I probably will, but at the moment I am still adding features to the original.

Brave work! ----- from Roboo
2003-12-15 19:08:00 anonymous2 [Reply | View]

Interesting. How do you justify that demand for Java version is little? Supposedly the Java application servers are the mojority in enterprise applications. The list if long: WebLogic, WebSphere, iAS, SunONE, Tomcat, ... -Roboo

Brave work! ----- from Roboo
2003-12-20 07:17:43 Ivan Ristic | [Reply | View]

I think it is just that Java people don't know ModSecurity for Java exist :) I'll post what I have online in the next month or so and we'll see.

small typo in the article
2003-12-03 07:21:46 anonymous2 [Reply | View]

I tried the configuration exemple, and I found that there is a little mistake :

SecFilterUnicodeEncoding

should be

SecFilterCheckUnicodeEncoding ...

small typo in the article
2003-12-12 10:03:52 chromatic | [Reply | View]

You're right! Thanks, it's fixed now.

This looks good
2003-12-02 13:25:59 anonymous2 [Reply | View]

A job well done but I am having problem with it on my own server. I just copied the examples and put the dll in my modules directory and set path to it in httpd.conf and when I tested it the staff could not load and I got this error -

Can't locate API module structure `mod_security' in file E:/www/Apache2/modules/
mod_security.dll: No error
Press any key to continue . . .

This looks good
2004-01-25 23:26:39 tvdv [Reply | View]

It is LoadModule security_module NOT mod_security.
because the exported API is defined a security_module.

This looks good
2003-12-02 13:52:45 Ivan Ristic | [Reply | View]

You are probably using a wrong DLL. There are two binaries in the Windows distribution, one for Apache 1 and the other for Apache 2. Try the other one. If it's not that - send me an email and I'll look into the problem.

bad application design shouldn't drive new development
2003-12-01 01:02:04 anonymous2 [Reply | View]

While this seems like a nice tool which might have some good uses, the example that is given in the beginning is a very bad one. It is based on the fact that an application has a way to tunnel SQL statements to the DB. It is badly designed. One should fix/redesign the app instead of building something around it.

gr.

Bart van der Ouderaa

bad application design shouldn't drive new development
2003-12-01 02:00:43 Ivan Ristic | [Reply | View]

I agree completely. One should always try to fix/enhance the application and not rely on other security layers, such as mod_security, for protection. I see mod_security as a protection layer operated by people other than original software developers. From their point of view, software is a black box. Their task is to do everything they can to minimize the risk of a security breach. The example you mentioned is, unfortunate as that may be, a representative of a quality of the code widely available today.

bad application design shouldn't drive new development
2003-12-08 06:08:02 anonymous2 [Reply | View]

I'd rather dump an app that passes SQL queries as GET/POST parameters rather than try to protect exploiting that... who knows how many other bugs are in it.

As for canonizing paths a better approach would be to reject these with HTTP 500. I actually do that in the apps in a more user friendly way but if I don't have the source for something I'd rather show my visitors a HTTP 500 page.

Wonderful module
2003-11-28 04:27:56 anonymous2 [Reply | View]

I'm using this and I absolutely love it, very flexible, still learning all the tricks, a valuable addition to the arsenal. Nice documentation. Would be wonderful if the Apache 2.0 installation could be clarified/simplified.

Meint