Hello all.

I was lately wondering the following...
Most of the clients I have in the shared hosting I was forced to disable on their domain mod security because all the time they were triggering some rule by false.
Even though I have disabled some of mod security rules because they were too strict like the redactor and the antispam.

I was wondering do you experience the same thing-issue ?

A few questions, who's modsecurity rules are you using, what version are they, and what version of mod_security do you have installed?

I have asl licenses. The modesecurity rules are the asl - atomic ones as far as the rules and package version.

But since todays website use so many different and complex scripts there are many times conflicts with websites.

Mostly I see conflicts with Joomla plugins and some forum plugins such as vbulletin.
Most of my clients though (8 out of 10) use joomla

Offcourse modsecurity it has also protected real well some websites and I have actually seen that.
But I can't turn my back to the fact that many clients experience issues and block themselves out of the server.

Have you tried to report a false positives? They usually get fixed within a business day...

We are also seeing an increasing number of complaints from customers, due to the increase in popularity of WordPress, Joomla and Drupal and other CMSes, about the mod_sec rules causing them problems, especially with Plugins.

The main problem we face is that our competitors do not run with mod_sec. Even our technical customers occasionally say things like "well, I'll get a cheaper account with BigCompanyXHostingLtd because I know I won't have any problems with them".

Part of the problem is that it is hard for them to see the advantage of mod_sec even though it is clear to us hosting people. Nobody they know will ever have had their site defaced, or hijacked to spread malware, so they can't conceive of what it would be like for them to be innundated with phone calls from angry customers whose PCs are now owned by spammers or criminal gangs.

The other part of the problem is the length of time it can take to resolve the problem. Although it can be a matter of only a few hours between a false positive being reported and a rule update being issued to address it, the customer will have to retest and may trigger a related rule, and if they don't have a static IP and we've not temporarily whitelisted them then they get annoyed about being shunned (again).

We've discussed this type of thing on the forum in the past, and if I recall correctly I suggested a "log only" option. Basically customer has false positive. Hosting company reports the false positive by clicking on the appropriate button. Hosting company optionally switches the rule in question to "log only" at that point, or waits until a rule fix has been issued and then does so. Hosting company then gets the customer to try again. If nothing gets logged we know we are safe to switch back to fully enabling that rule.

Of course this adds complications, reductions in security, and the potential to forget and leave the rule in log-only mode.

The bottom line is that I'd rather lose a few customers because they are unhappy with mod_security than lose scores of customers and loads of sleep if, as a result of not having mod_sec, the server gets owned.

A quick glance at our mod_sec logs shows that our systems get attacked almost every minute of every day. Admittedly only a very very few of those attacks would succeed without mod_sec because a 99.999% of them are random or opportunistic, but it only takes one badly written script and one lucky skiddie or "scriminal" ("ccriminal" - Cyber Criminal - doesn't sound as good as "scriminal" ) to ruin not just your day but potentially your week, month or even your year.

I do wish there was a better solution to all this, but I just can't think of a practical one. I can think of a really cool impractical one, however, involving the breeding of millions of radioactive flying turtles trained to seek out the bad guys and bite them in their dangly bits.

Faris.

Sounds really, really good. Do you have them up for ordering on your web page? Any Black Friday deals? Deal or no deal, I'll buy a bunch right away!

Heh, I love it, so the best defense is a good offense eh? My wheels are turning.

The log-only idea is an excellent one, and we're adding that in. And I feel your pain, we definitely don't want anyone have any problems with the rules - its your box, and we want you to be able to do whatever you want. So I like the idea of a "learning" mode, if you will, put a domain (or a box) in a log only mode so you can see if there are any false positives.

With that said, are there any in particular that are causing issues, and anything anyone can report? We can get out a fix in some cases in a few minutes. So, please report your false positives, we do try to test on as many platforms and with as many applications as we can, this is a LOT of software and we clearly arent able to test everything so theres regretably going to be the occassional false positive. Our goal is to have 0 false positives, and they are priority 1 for us with support - if you report it, it gets top billing.

We do browse quite a bit to try and find everything we think everyone uses, but if you guys could tell us that would help to sort out whats worth spending time testing. That might help us with our testing to have a better sense of what folks are using specifically.

I will tell you we run every rule on every system we run, and we use Joomla too - so we're just as focused on making sure there aren't any issues and we definitely will never put out a rule we wont use on every box we have. We're in for a penny and in for a pound. .

A variation on a theme: The biggest problems we see are with the generic SQL injection and generic XSS rules.

I wonder if it might be an idea to split such generic rules into two categories. Rules that cannot possibly cause false positives, and those that potentially might? Obviously I don't know if this is practical or not, or even ones that can't possibly cause false positives are ever to be found in the generic rules.

(if any of the above is even remotely sensible and you do ever split them, please make sure that the ones that might cause false positives retain the existing rule number so that if they are disabled by someone they will stay disabled)

What about full rule whitelisting by IP? ......... I know this is already basically possible but if you use it you are on your own with no support. So how about limiting it so that the main admin of a site with an "awkward" script installed could have their static IP whitelisted in this way but only *for their own site*. That would allow them to do what they want without fear of something not working or being shunned.

Rule that are triggered would still be logged, but not blocked. False positives could then be reported, making the rules better for everybody else.I don't see a serious downside to this, but then I'm one of the good guys and don't think like the bad guys do.

Better yet, a button they can hit in the control panel that checked their current IP and whitelists them for 20 minutes (again only for their own site) - long enough for them to do what they need to do without fear of problems. Again I think this was discussed in the past but I seem to remember it was considered too dangerous.

(dashing between family events so quick incomplete post)

So let us know how this jives, in the 3.0 GUI we're add in a rule manager, which will let you set thee mode for each event, and by vhost. So you can say block/log (current behavior), drop/log (stealthy, nothing is returned), proxy/log (send to something else), redirect/log (send to a special page), log only, and all of the above with no logging (do this, but dont tell me you did it). You'll be able to set this by vhost too.

So I thought on rules that end users should be "allowed" to disable should only be rules that can never compromise the whole box, so spam rules make sense, XSS maybe. SQL injection probably not a good idea, too likely to own the whole box - something I need to think about.

the mod_security project completely removed the ability to change rules at a user level from modsecurity years ago (the old htaccess option in 1.9.x) because bad guys can just get an account, turn off modsec, and own the box - so if we added in the ability to do that we'd want to make sure users are clearly informed that this shouldnt be done unless you trust the user (and trust them not to get their credentials stolen!).

OK, resume party, love the feedback, gotta run and eat more turkey!

Still chewing through older posts and found this one. What I'd like (and I suggested this elsewhere) is a mini-ASL panel (preferably in Plesk but possibly standalone) where I can tell my customer "go here and see all that ASL does for you. Find anything wrong? Pass it to me."

So my customer logs in and see events for his sites. He finds a false positive and flags it as such. This lets me know "Hey, user X had a problem with this rule." I log into my panel, see his report and I can forward it to ASL directly, reject it, or turn that rule off for him.

Win for hosting people because now end users can see what value ASL provides (instead of "Why did the #@&$ server block me again!") and don't have to comb through their customers' logs.
Win for hosting clients, who can see the blocked activity by site and flag FPs easily.
Win for Atomicorp, who has less frustrated resellers and more FP data.

Remember that clients can already check their error_log and see the mod_security events in there. They can then forward any false positives to you.

But sure, clients probably don't like looking at error_log files as much as they like clicking buttons.

Great idea Highland, we were actually discussing doing just this a few weeks ago. We just have to work out the mechanics.

Sorry for bring up an old thread, but we do have the same issue as many of the people above. I have dropped an email into support but i was interested in what others may think.

We have many clients who hit security rules, and have no idea about error_logs and the such, to them they are getting thrown of the server for no reason whatsoever and there impression is that the server is unreliable and therefor they go looking for a new host. We all know that getting business is hard, so loosing a client simply because they have hit a security rule is tough.

Ive been looking through the modsecurity documentation and came across the "redirect" action, this can be easily used to make it so that when someone triggers a security rule it will take them to a page on a different server that tells them whatever you want, ie just a small html file saying "You have hit a security rule, please contact support - your access to the server has been blocked due to this"

All you need to do is to alter the rule to have this redirect in it.

If we take a sample rule from eg

/etc/httpd/modsecurity.d/50_asl_rootkits.conf



change this to eg


Then give apache a restart, you can then trigger this rule by going to eg




But instead of just being confronted with a server not responded, you would in this case go to googles homepage, which of course could be any webpage that we elect.

Having some user variable in /etc/asl/config where this is configurable and then it being used to inject into the rules after an "asl -u" i personally think would save us loosing a lot of customers and would be highly informative.

Would like to know others views on this?

--
Ian
34SP.com

I've considered it, but decided against it.

Basically I didn't want website visitors who accidentally trigger a rule to see a page saying "You have triggered a security precaution -- please contact us", nor do I want the bad guys to know they have triggered something.

I did try this when playing with RBL-based rules (Tor exit nodes, for example) and was happy to do it for that.

Faris.

I do agree that informing visitors could lead to more abuse - but the amount of people we have who are leaving due to thinking we have unstable servers rather than contacting us does make it that something needs to be done.

Rules such as 340147 and 350147 are sometimes prime problems, a user triggers one of these quite easily, we report a FP, it gets fixed then the opposite rule gets triggered and we have to go through the process again. But of course this only happens if a customer contacts us, some people just think the server is totally unstable and then up and leave to a new host which really gives us a bad name as we find a lot of business is from recommendations.

So i do believe something is needed to inform the users, the whole idea of having it as a variable in the asl config is that this could easily be set to NULL and not send any redirect out, if people chose not to use it.

How do you deal with people thinking your servers are unstable when they go through a spate of hitting rules without telling you?