Atomicorp

Hello,

I have a problem with MovableType and one of our in house workflow applicaions (which is only accessible by authorised users). triggering mod_security false positives. I'd like to disable the mod_security just for these applications and just for certain IP addresses.

The applications are:
http://www.[mydomain].com/cmsdev/public/?action=main.listJobs
http://www.[mydomain].com/cgi-bin/mt.cgi

I followed the instructions in the wiki here:
https://www.atomicorp.com/wiki/index.php/Mod_security

First I modified:
/var/www/vhosts/<DOMAINNAME>/conf/vhost.conf

Adding on the first domain:
<LocationMatch /public/cmsdev/index.php>
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"
</LocationMatch>

And on the second domain:
Adding:
<LocationMatch /cgi-bin/mt.cgi>
SecRule REMOTE_ADDR "@pmFromFile /etc/asl/whitelist" "nolog,phase:1,allow"
</LocationMatch>

I then make sure my IP address was in:
/etc/asl/whitelist

Finally I restart Apache.
/etc/init.d/httpd restart

However I'm still triggering false positives (mostly the rule that detects http:// in forms submitted) on these applications. i.e. mod_security hasn't been disabled for my IP address on these apps.

What might I be doing wrong?

Hard to say offhand, it could be anything. Whats the false positive you are getting, and what version of the rules are you running?

Hi,

Thanks for the response.

In movabletype editing templates triggers the rule that detects for 'http://' in posts. (Naturally the source code for web pages contains http:// quite often).
And similarly on our internal workflow software the same - whenever clients submit briefs that contain 'http://' it's triggered.

Basically though I would like to be able to turn off mod_security completely for certain IP addresses and for certain applications on domains. Am I following the correct procedure?

Kind regards,


Peter

Did you run /usr/local/psa/admin/bin/websrvmng -v -a (or run it for the specific domains instead of using the -a flag) after creating vhost.conf? This adds the include for vhost.conf to httpd.include so what you added actually gets used.

Ah. I hadn't but I just did now; and then restarted apache again.

Unfortunately still the same problem.

Might there be something else?

(Thanks for hanging in with me here)

OK I found this worked:
I created:
/etc/httpd/modsecurity.d/00_asl_custom_exclude.conf
with the contents
SecRule REQUEST_FILENAME "^/cmsdev/public/" "phase:1,t:none,pass,nolog,ctl:ruleEngine=Off"
and restarted apache.

However it would still be nice to only have this exclusion for certain IPs if I can.

Can you post the false positive? It might be something easily fixed in themselves.

In movabletype editing templates triggers the rule that detects for 'http://' in posts. (Naturally the source code for web pages contains http:// quite often).
And similarly on our internal workflow software the same - whenever clients submit briefs that contain 'http://' it's triggered.

If you click on the "report false positive" button in ASL Web it will send us what we need to look into this further.

We need to see the audit_log entry in its entirety. Saying it triggers on http:// doesnt really tell us anything, we know to know where in the applications submission this occurs. URLs can be malicious, so simply allowing them for MT is not a good idea - its very dangerous.

If you could post the entire audit_log entry for this or just hit the False Positive button in ASL that would send us the information needed to debug the FP.

Hello

I clicked the 'false positive' button. But nothing happened. Should there be a confirmation message or something?

Thank you,


Peter

No, there is no visual feedback (would be nice, has been requested before I believe).

Im pretty sure we have that added into SVN now

If you hit the FP button it will automatically open a case in the support portal for your account. If you system sends the FP without enough identifying information we have to manually associate the case with the account - so for some users there may be a delay.

One easy way to create this association is to make sure your support portal account has the same email address you use to send your ASL alerts. Then its really easy for the system to associate FPs with accounts.

Anyway, if you hit the FP button we got the case and put out an update. Are you still having the problem?