mod_security - Why does SMF even trigger it?

[jarradofs]

I am currently working with my webhost to work out why mod_security is being triggered by a vanilla no-mods SMF install.

This is the specific error:
[Sun Sep 22 16:40:46 2013] [error] [client 134.7.248.132] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "500"] [id "340162"] [rev "290"] [msg "Atomicorp.com WAF Rules: URL detected as argument, possible RFI attempt detected"] [data "TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required. [hostname "mydomain.com"] [uri "/index.php"] [unique_id "bs52qgoHQBIABCFIJX0AAAAM"]

Looking at this error I have been able to determine that its triggering because the rule ID of 340162 happens when "This rule works by detecting the use of a URL as an argument," somewhere within index.php.

If we look at the ruleset from Atomic Corp (10_asl_rules.conf), the rule in particular that is being violated seems to be tied to this:
updates.atomicorp.com/channels/rules/delayed/modsec/10_asl_rules.conf
#SecRule ARGS "!@pmFromFile trusted-domains.conf" chain
(I wont post the whole chain)
#SecRule MATCHED_VARS "!@rx ://%{SERVER_NAME}/" "t:none,t:urlDecodeUni,t:lowercase"

My host is happy to work with me on this and try and work out what is going on. I tried using the .htaccess and I am having some variable success with it (seems to invoke sometimes but at other times, the rule seems to trigger again oddly).

But back to my original query - why is the SMF index.php even triggering this rule to begin with? My host would like to know (as would I) to try and work out if perhaps a rule needs to be adjusted but without any understanding of the underlying logic about what is causing the supposed RFI - they are stumped.

Thanks all

[Burke ♞ Knight]

Having problems with mod_security?

[Kindred]

because mod_security is the stupidest thing to have ever been installed by any host?

[jarradofs]

Yeah thanks for that guys.

Unfortunately, I have read through those threads, and whilst answers like "mod_security is stupid" are great and all, that doesn't answer my query of what is the programming logic in index.php that would make a ruleset (that I have provided a link for so you can actually read it) think that either a URL is being used as an argument or how it would appear that a remote file is trying to be included.

I don't disagree that using an apache module to control other vendors bad programming is ridiculous, but in the world of the lowest common denominator you do have to agree that no web host wants their servers being compromised because someone is a lazy git with their code.

Unlike most hosts, mine is actually willing to work with me on this - but they want to know what is happening in the programming logic to try and see if they can match anything with their logs and maybe write an exclusion for the behaviour.

[Colin]

Mod security is composed of an array of generic rules to prevent things such as forcing HTTP compliance. Generic rules don't work well for thousands of different environments and scripts. Unfortunately many web hosts fail to understand this and insist that mod security should not be triggered unless there is an issue with the script. However, false positives will happen. They are bound to happen simply because the core rules are incredibly generic. So, how do we make them "less generic"? Well, ModSecurity is intended to be configured on a per application basis. You can configure ModSecurity to use "Detection Only" mode which will highlight what rules are being triggered then you can disable a rule per ID. Now, in order to do any of this you need to have root access to your server. Since you are approaching your host about mod_security I am assuming that you don't have root access. Long story short, kindly ask your host to disable it.

[jarradofs]

Since you are approaching your host about mod_security I am assuming that you don't have root access. Long story short, kindly ask your host to disable it.

Correct. I have enquired but they have already rebuffed disabling it.
They have advised they would consider adapting rules - but they want to know what in index.php is triggering the rule to begin with before they make any changes.
Hence my post here asking what in the programming logic could be triggering the rule ID, of which I have provided what the rule looks for, and also a link back to the rules conf file of the rule that is being triggered.

Long story short - what happens inside index.php that makes a ******ty module think a foreign remote file is being included?

[Colin]

Jarradofs,

Give this a try if you wouldn't mind. Create a file called ".htaccess". Paste the following code into the file and upload it to the root of where SMF is installed.

Code Select Expand


<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>


Finally, try loading your SMF instance. If this doesn't work I can work with you (and your host) further.

[jarradofs]

Hi Colin

Tried that. Makes no difference. Not sure why. I added the .htaccess and waited a few hours and things seemed to work, but switching to a different machine the problem reoccurred.

The hosts logfiles are crap as well which isn't helping.

I might just reloading the install again from scratch with the .htaccess present in the root directory before doing the install and seeing what happens.

I'd really like to know more about the programming logic from one of the developers but your assistance is greatly appreciated.

[Colin]

Truthfully, I don't know what rule is being triggered because I don't use it. If your host wants to see what is being triggered, tell them to access your SMF instance with mod_sec detection only mode enabled.

[GL700Wing]

I've encountered the same problem a few times (and sometimes my host breaks it again after they've fixed it!) and all I had to do was get them to specifically allow me to disable SecFilterEngine - you don't need all of mod_security disabled.

I've been told that having SecFilterEngine enabled can cause problems when *naughty* words words like sextant, Essex, sexist, sextuplet, etc are used in posts.

[kat]

I've even known "Hot water" to trigger it, coz of the highlighted bit.

It really can be THAT pathetic.

[Arantor]

It would be nice to know what you're trying to do when the rule is triggered, like what URL you were on.

mod_security isn't, in itself, bad. It's the rulesets that get thrown at it, which usually are.

[jarradofs]

It would be nice to know what you're trying to do when the rule is triggered, like what URL you were on.

mod_security isn't, in itself, bad. It's the rulesets that get thrown at it, which usually are.

[Sun Sep 22 16:40:46 2013] [error] [client 134.7.248.132] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "500"] [id "340162"] [rev "290"] [msg "Atomicorp.com WAF Rules: URL detected as argument, possible RFI attempt detected"] [data "TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required. [hostname "mydomain.com"] [uri "/index.php"] [unique_id "bs52qgoHQBIABCFIJX0AAAAM"]

I've omitted by domain here.

Everything you should want/need is in the OP (or that was my intent)

[GL700Wing]

I know you've posted information from your server log file but what action are you doing that triggers the mod_security error condition?

On my forums I found that the following actions that could trigger this error condition:
1.  Use the Set Smiley Order function on to change the position of smileys - I would get an error message when I clicked the location to which I wanted the smiley moved; and
2.  When I tried to modify the details of an existing board category.

Depending on which forum I was managing I'd get either a "Error 403: You are not allowed to view this site." or a "FORBIDDEN:  You don't have permission to access /forum/index.php on this server." error.

[jarradofs]

At times the error is triggering just loading the page.
Sometimes it would happen when trying to browse to another section of the forum (ie go into the admin panel etc).
I have a feeling its something to do with sessions personally.

[Kindred]

could be... maybe it is SO STUPID that the random letters combine to be s-e-x and mod_security throws a fit

[GL700Wing]

I'm wondering if there is a combination of letters in the OP's domain name that is causing the issue - it would be interesting to know if just disabling the SecFilterEngine component of mod_security resolves the issue.

[Arantor]

The rule does indeed show it is complaining about a match against request_headers.host which is where the domain name would be listed.

Which is why I asked what URL you were on - with the hopes you'd supply a full URL for us to examine.

As far as the other issues GL700Wing has mentioned, I've seen those throw errors with mod_security but I can't see *why*. The normal criteria won't be triggered with that, so we'd need to know which rule it was and then maybe to be able to change the URL to avoid it.

[jarradofs]

As per the OP.
Copy of the rules:
updates.atomicorp.com/channels/rules/delayed/modsec/10_asl_rules.conf

The part of the conf file that is relevant
#SecRule ARGS "!@pmFromFile trusted-domains.conf" chain
(I wont post the whole chain... it's phenomenally long)
#SecRule MATCHED_VARS "!@rx ://%{SERVER_NAME}/" "t:none,t:urlDecodeUni,t:lowercase"

The specific ID of the rule triggered:
340162
Which does "This rule works by detecting the use of a URL as an argument."

I am guessing that maybe something within index.php and the session doesn't quite decode back to what it is expecting to based on some kind of checksum, and that's why it thinks a remote file is being included but I simply don't know enough about how this is done in index.php

Also, it's not the domain. I have tried to run SMF on subdomains on the same host to no avail for other projects.

Cheers

[Kindred]

so, it really does sound like a host problem since SMF runs just fine on hundreds of other hosts.

[Arantor]

Well, you previously posted up there a different rule of which the relevant segment is:

Code Select Expand

Match of "beginsWith %{request_headers.host}

Which suggests it is the URL.

I don't know what to tell you, you're still not providing enough information to be able to actually identify what the problem is.

[jarradofs]

[Sun Sep 22 16:40:46 2013] [error] [client 134.7.248.132] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "500"] [id "340162"] [rev "290"] [msg "Atomicorp.com WAF Rules: URL detected as argument, possible RFI attempt detected"] [data "TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required. [hostname "mydomain.com"] [uri "/index.php"] [unique_id "bs52qgoHQBIABCFIJX0AAAAM"]

That's the entire error from the log - as posted in the OP.
This is from trying to access the site and just browse it when logged in. Not trying to add packages/make a post anything like that. And then I would get white screens of death afterwards.
I don't know if this is related, but I would get errors suggesting that the varchar(32) limit for the value session in the table smf_log_online was too short - or rather the data was too long, occasionally as well.

[Arantor]

You know, you could have just posted the URL you had issues with... would have cut down a lot of the back and forth in this debate and would be one more thing to be able to rule out since that still clearly says request_headers.host in it... if you don't want to discuss it publicly, you could send me a private message with it in. On the basis of what you've provided so far, the domain name is actually the most likely problem...

As far as smf_log_online is concerned, the standard session length is 32 characters, and we've never seen it be generated as anything other than that yet...

[jarradofs]

Please check your PMs.

Thanks for your assistance.

[Arantor]

I read it, I replied, I await further information to actually be able to try to diagnose your problem.

[jarradofs]

Thank you Arantor for pointing me in the right direction regarding domain name.

I sent this off to my webhost and they returned the following:

"Our Web Admin combed through the logs for the server itself and it appears that there is a script on this server that is attempting to gain shell access via the PHP function escapeshellarg(). Although there may be benign uses for this command (like executing a directory listing) it can be used to run more nefarious commands on the server so it is blocked wholesale and they will not override the block.

The specific file where the command is located is httpdocs/Sources/Subs.php, and it appears that is is being used to perform an IP address lookup. You may want to see if there is a way to disable this function from within SMF, or if they have a workaround for this feature."

Oddly this script is only triggering for a domain name with the word "civilian" in it as a vanilla SMF install running on a subdomain "test.otherdomain.tld" fails to generate an error whereas "civilian.otherdomain.tld" did have a problem - which is something I am going to go back to my host on.

In the meantime - devs have any idea regarding what has been said here or ways around this problem?

It almost sounds like there is 2 issues: the domain name itself is triggering one rule, and then the PHP function another and in combination it's breaking the forum.

[Arantor]

You can disable hostname lookups from the admin panel (I forget exactly where it is, but using the search in the admin panel for 'disable hostname lookups' will find it), which makes banning less effective since you can then not ban by hostname.

[jarradofs]

Thanks Arantor. I will have a look for this.

[GL700Wing]

You can disable hostname lookups from the admin panel (I forget exactly where it is ...

Admin -> Configuration -> General -> Server Settings and uncheck 'Disable hostname lookups'

[Arantor]

That's what the admin panel search is for