ModSecurity Rules

[Angel78]

Does anyone knows how to use this rule with ModSecurity 2 (blocking clls to ftp and http to disable file downloads).

SecFilterSelective REQUEST_URI "=(http|ftp|ftps|https)\:/"

I'm currently using the default rule set from Cpanel (ModSecurity 2)

thank you.

[sv70]

look here:

http://www.gotroot.com/mod_security+rules

[Angel78]

does anyone has a 2.0 rule that does this?

SecFilterSelective REQUEST_URI "=(http|ftp|ftps|https)\:/"


thank you.

[thobarn]

The line you posted can be translated as (there are other possible ways)

v1.x

SecFilterSelective REQUEST_URI "=(http|ftp|ftps|https)\:/"

v2.x

SecRule REQUEST_URI "=(?:ht|f)tps?:"

However, this snippet is NOT a valid mod_security v2 rule, i.e. it cannot be used by itself. This rule catches every request that starts with http:, https: ftp: or ftps:, pretty much everything arrives at your server and this is probably not what you really want

You are not giving enough information to reconstruct the filter you are referring to as a v2 rule. Either post the entire filter or describe what are you trying to achieve with the rule please.

Also required is some action to take when this rule is matched. For example, the complete rule may read something like:

SecRule REQUEST_URI "=(?:ht|f)tps?:" \
	"t:lowercase,phase:2,log,deny,status:403,id:'2',msg:'Why you are catching this',severity:4,tag:'give the tag a name'"

The second line of the rule is entirely speculative.

I use t:lowercase transformation because In Mod 1.x, SecFilterSelective was case insensitive. In Mod 2.x, the case of data is not altered unless the lowercase transformation function is used.

I catch the request in phase 2, where you want to catch depends on what you are trying to catch

I log and deny access, you may want to also audit log, or even allow access, depends on what you are trying to do

I return a status 403 Forbidden, again depends on what you are trying to do

I gave it an id:2, but there is a prescribed way to assign ids to rules, some ids are reserved

msg:... will display in logs

severity:4 is again arbitrary, depends on what you are trying to do

tag:... will display in logs

[Angel78]

thank you so much for your response.

The aim of the rule was to catch all those http://www.domain.com/index.php?acti...test.htm...etc where they try to inject/downlaod some code from other servers.

[thobarn]

I see. I must make a correction to previous snippet I posted. I noticed the equal sign when I saw the rule in context in your last msg..

it should read:

SecRule REQUEST_URI "=(?:ht|f)tps?:"

sorry if this caused any problems.

[mikegotroot]

As an aside, URI injections are covered in the gotroot.com rules, so if you want to protect yourself against those attacks our rules should cover you really well. They are also written to minimize false positives, such as self referenced URLs and include lots of exceptions for tons of popular applications (something neither the modsecurity.org nor cpanel rules do).

Also, if our rules break any application use we will fix it in our rules the same day. We don't expect end users to be able to tune the rules themselves (although if you can, more power to you! *grin*) - our motto is Security For Everyone.

[mtindor]

Mike,

So.... tell me. The question that really needs answered is this:

If I install the gotroot.com rules on a Cpanel server that predominantly runs a simple sites, custom-coded sites, and a smattering of Joomla and Wordpress (as well as Frontpage...yikes), am I going to get a shitload of false positives right out of the box?

You have made the claim that you guys are reactive when it comes to problems that customers face with false positives, whereby you will resolve the conflict that your rules are having with the legitimate app. However, are you proactive from the start to make sure that these rules are very _unlikely_ to cause problems out-of-the-box on a Cpanel shared hosting server?

I'm not being a jackass - but before I go and yet install another set of rules when the ones I have used for 3-4 years have worked fine thus far, I'd like to know what I"m getting myself into.

Are your rules Cpanel-friendly?

Mike

[mikegotroot]

Thanks for the questions. I'm happy to respond and if you need any additional information please let me know. Now onto your specific questions:

If I install the gotroot.com rules on a Cpanel server that predominantly runs a simple sites, custom-coded sites, and a smattering of Joomla and Wordpress (as well as Frontpage...yikes), am I going to get a shitload of false positives right out of the box?

For anything thats a known application we can test (Joomla, PHPBB, SugarCRM, etc.) no you should not get an FPs. For something you coded yourself, NO ONE can quarantee a WAF won't possibly interfere with that. Theres no way for us to proactively test for every case, but we do have lots of customers with custom apps and over the years we have done lots of work to reduce the changes of an FP occuring. A web application firewall, as you know, is a very invasive piece of software so there is always the chance of an FP. If anyone tells you otherwise, they are lying or are clueless. :-)

Thats why we make support so important, if something doesnt work - we will fix it immediately. You can tune it yourself, and with modsec thats fairly straightforward but we don't assume our customers are security experts. If you ask our customers I think you'll find that we do in fact respond very rapidly - usually within an hour with a full fix. If its during normal hours on the East Coast we usually get an update out with an hour or two.

Plus, we've been putting out modsec rules longer that ANYONE. Longer even than breach (the modsecurity.org guys). We were putting our rules years before Breach bought modsecurity so our rules are based on years of experience way beyond anyone elses with WAF rules. Plus, our IPS guys were part of the company (WheelGroup) that invented IDS back in the 90s - so they know intrusion protection and they understand the importance of minimizing false positives. And finally, our company was founded by two of the Plesk founders, so control panels are extremely important to us. We understand your industry and are fanatical about supporting the hosting industry.

You have made the claim that you guys are reactive when it comes to problems that customers face with false positives, whereby you will resolve the conflict that your rules are having with the legitimate app. However, are you proactive from the start to make sure that these rules are very _unlikely_ to cause problems out-of-the-box on a Cpanel shared hosting server?

Yes we proactively test everything, and we run every rule on every system we have - we do not disable any rules on our systems - if it doesnt work we always fix it, we never disable it. And its always been that way, gotroot.com runs every rule and has always run every rule - no exceptions. We force our team to make sure every rule works on every system every time - no matter what. Security For Everyone. And if our rules do cause a problem, we'll even log into your box and fix any issues for you, without charging you extra. We care that much about our work - you get our rules we will make them work for you. Everyone wins. Whats not to like about that?

I'm not being a jackass - but before I go and yet install another set of rules when the ones I have used for 3-4 years have worked fine thus far, I'd like to know what I"m getting myself into.

No offense taken. I would say one thing with WAFs, its important to remember that false positives are important, believe me I know how important they are. I get in heated debates all the time with my peers in the security industry about the critical importance of NEVER blocking legitimate traffic. Its an availability attack on your OWN users! So FPs are vitally critical to us - we do not shrug our shoulders and tell our customers to fix it themselves, tune it themselves and so on. Thats our job and thats what you pay us for. We will make it work - period. Its good for you and its good for us because everytime we learn about an issue that ensures it will never happen to anyone else again. So I understand your concern, and if you would like to try out our rules for free before you buy just shoot us an email - we do that all the time because you know once you try our work you'll become a customer.

One other though on rules, also beware that if you rules work for you that are not experiencing any False Negatives - missing attacks - I'm sure you are more than aware of the importance of that too, and know that we place equal emphasis on keeping up with the latest threats. If your current setup isnt stopping todays attacks, then you are missing attacks. We keep up with the latest research because we are a security firm this is what we do. We stand behind our work, we support it and we maintain it. And if you don't like our rules, we'll give you your money back.

Are your rules Cpanel-friendly?

Yes, we have cpanel customers now, the only warning I have for any cpanel customer is to make sure you are using the latest modsecurity 2.5.9 (lots of important fixes in 2.5.9) - other than that no worries. And if something doesn't work for you - like I said we will fix it, we'll even log into your box and do it for you if you ask. Now go find a security or even a software company that will do that for you and not charge you for it. :-)

Also, in case anyone was wondering we've been business for eight years and have Defense, Intel, Federal, Commercial, Hosting, Power, Nuclear, Regulatory, Law Enforcement, Think Tank, non-profit customers, etc. using our WAF technology. You can check out our parent website in my sig (Prometheus Global) if you have other questions about the company.