WAF: limited granularity is wearing on my nerves.

Hi Jon,

with issues like you are having I would recommend creating a support case while waiting for some of the wiz kids to read your post.

Ian

Yeah. Thanks man..

I've been down a road with support with other nonstandard tweaks to this thing.

Now all I need is to get someone to pick up the GD phone.. This hold music becomes corrosive after 50 mins.

My last go around brought me up to the manager in charge of product development.

Hopefully L1 will be stateside.

VK ? GL en 73.

Hi Jon,

3yay, not active, wife prefers holidays to amateur gear.

 Hey  FloSupport would you please investigate.

Thank you

Ian

Basically hard to troubleshoot, because if you tweak the database or other stuff, you basically revoke your entire support on XG... Thats most likely the point.

You should not call for such support incidents, instead open a Mail with details, what you trying to archive. But as told in my previous statement, it is most likely not the case, that somebody can help you because you will revoke the support by tweaking the XG.

Can anyone here please tell me where ID: 95097 System Command Injection would fall in the categories? or which category RFI Attacks fall under?

This question should be answerable by Support.

So basically open a Case with this question and some example logs of your reverseproxy.log.

Thanks for the advice. it's not my first rodeo with this XG and Supports ability to 'support' it.

My inquiry was more of a fact finding mission because the devs lock this thing down and obfuscate where things are defined.

I know that somewhere in the DB there is a list of rule ID's vs categories.

I just thought I'd ask to see if anyone already knew the answer I'm seeking. 

This is not your basic dentist office, or supermarket XG deployment.

We have two data centers running HA XG's at each site.

Unfortunately we tap out the arbitrary limits set by the developers on several occasions and the ability to tweak these settings are restricted which is extremely hindering our ability to properly configure our WAF implementation.

 BTW, Support didn't have the answer to my question. I received an "I'm not sure but you could try..." I know what I can try, I needed a definitive answer and if possible a list for reference.

Hi Jon Bruno 

The best way to fix your issue is to monitor the reverseproxy.log file for the specific host/website you are using.  Then when it reports that it blocks traffic that is supposed to be legit, you will need to add the ID to your protection policy to be bypassed.  You can then use individual protection policies on each WAF rule.

In terms of answering your question around mapping rule IDs to categories, this is not easily achieved and would require manually looking into the database at various tables and then manually mapping it on an Excel sheet.  What is the end goal for this?  What is the use case scenario?

To list all of them here is not ideal as the list is quite long.

If you would like a list of tables within the database where this data is pulled from, please DM me and will provide you the command.

If you would like more control on the WAF component, then please submit your ideas to us by going to https://ideas.sophos.com and submit it there.

Thanks!

In the spirit of thread continuity, here is my use case.

Suppose you have a false trigger on a rule, this rule may have been triggered by some less than best coding practices, or perhaps by a data stream that was misinterpreted by the scanner.

Lets use a streaming .pdf file for example, this could trigger SQL injection attempt alarms.. oh and it must be under 1mb in size because of an arbitrarily 1mb limit is set in “sec_request_body_no_files_limit"

The XG currently allows you to skip rules by adding the filter rule ID to the skips list.

While this may be satisfactory to some this also exposes your environment to an added vulnerability because the rule that you just excluded is now globally skipped.

Of course in my example we could simply define the uri in question and click on the skip SQL Injection box.. problem solved... right?

well, not really.. yes and no.. the .pdf file will stream no without tripping the filter rule, but what if the false positive is based on a rule that doesn't easily fall into the 11 categories listed?

Lets look at a couple of OWASP riue ID's,

For example, 970003 is another rule that is fired if SQL Error Leakage is detected.

This could potentially be loosely associated with the SQL Injection attacks group but since there isn’t anything saying that it is or is not.

should we assume that it is just because the term ‘SQL’ is in the message...that's all we have to go by..

Ok, let’s go further and consider ID: 981001, This is an Iframe injection detection. (OWASP considers its category OWASP_CRS/OWASP_CRS/MALICIOUS_IFRAME)

Would this be listed under the ambiguous “Generic attacks” category or “Protocol Violations”, or how about “Protocol Anomalies”?

There isn't enough information available that can provide the definitive answer.. 

While the kb article https://community.sophos.com/kb/en-us/121114 outlines the rules files used, although it does not give us a listing of which owasp rules are handled under the umbrella of each category.

 I suppose I should actually just dump all of the modsecurity_crs*.conf files individually and figure it out from there, previously my cat *.conf into my putty log provided me with the rules but not the individual file names that I could use to associate them with.

-jon

Ok so here's what I have done..

First I copied all of the rule files to my local machine with pscp (pscp -scp -unsafe admin@x.x.x.x:/content/waf/2.7.3/* C:\Users\Username\Desktop\Rule_Files\ )

I then added the "conf" extension to my windows search indexing options and selected that the search tool "Always search filenames and contents"

this now allows me to simply search the rule ID and the search result will be the file name that the rule is defined in giving me the category I need.

i.e. 958291 results in modsecurity_crs_protocol_violations.conf

This will work for the category index.. still doesn't fix the granularity issue, but a win is a win no matter how small.