[Bot Management policy and WAF policy - which runs first?]

Fantastic!  Thanks @Marcelo Oguma de Souza1709152865!  And the two documents are incredibly helpful!

[Bot Management policy and WAF policy - which runs first?]

Hope this is an easy one to answer.  I've looked through documentation on both subjects but couldn't find an answer (or was just not looking hard enough). 

 

So I've got both Bot Management and WAF features enabled on a device.  Let's say I have a Bot Management policy that is bound default globally and has a policy expression of "true".  And I've got a WAF policy bound to a VIP with an expression of "true".  Which will run first?  The Bot Management policy or the WAF policy?  I would imagine the Bot protection would run first to sort of screen the deluge of requests that come from bots of all types?  What if the WAF policy is also bound default globally with an expression of "true"?  Or does that even matter with the run order?

[How do I tell if I'm using a "WASC 1.0" or "WASC 2.0" WAF signature types?]

This is probably a stupid question but I'm not too terribly proficient with Citrix ADC WAF.  My question is how do I tell if I'm using WASC 1.0 or WASC 2.0 signatures?  

I ask because we had a cybersecurity firm run a series of penetration tests on a number of our public facing applications.  They came up with a bunch of items that need to be fixed.  A bunch of the minor and medium risks found were remedied with some rewrite policies, cleaning up weak ciphers, securing NetScaler cookies, and setting the "Secure" and "HttpOnly" flags on server response cookies. 

 

The one major issue that they found is that there are no "anti-automation" protections in place.  Their suggestion was to make sure we have WAF protection (I did not have the lb vservers on any WAF policies at the time of penetration testing).  Well, I've got WAF protection now for the apps but I'm wondering if that's enough.  I can't find any documentation locally about any "anti-automation" protection. 

 

But then I found this article:  https://docs.citrix.com/en-us/citrix-adc/12-1/application-firewall/appendixes/signatures-whitehat.html  

 

It states that the "WASC 2.0 signature types" can counter the "anti-automation" vulnerabilities.  But I have no idea what to look for unfortunately because I'm not that well versed in Citrix ADC WAF.  Will invest in some training when I get free time.

 

I also am not sure if I should put a set of rate limiters on the vulnerable vservers.  (Another thing I don't know much about but intend to investigate.)

 

Firmware is 12.1

Common security checks that set to block are "Buffer Overflow", "Credit Card", "HTML Cross-Site Scripting", and "HTML SQL Injection".

WAF Signature is 102

[Replacing URI path on LB vserver (after being directed to LB vserver by a CS vserver)?]

On 8/21/2022 at 11:10 AM, Stefan Wielers said:

Hi,

 

check this:

using: http.REQ.URL.PATH.GET(1)

 

add rewrite action rw_pol_replace_aaa_with_xxx replace "http.REQ.URL.PATH.GET(1)" "\"xxx\""
add rewrite policy rw_pol_replace_aaa_with_xxx 'HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH("/aaa")' rw_pol_replace_aaa_with_xxx

 

 

 

Sorry for taking so long to reply - I've been bogged down with tons of project work as of late.  But in event, you're policy seems to do the trick.  Thanks Stefan!  

[Replacing URI path on LB vserver (after being directed to LB vserver by a CS vserver)?]

Wondering how I would I go about replacing a portion of the URI path from one thing to another.

 

example:  https://hostname.com/aaa/test to https://hostname.com/xxx/test.  

 

I have a content switching vserver that has a content switching policy set to look for "aaa" in the URI path and send them to a load balanced virtual server.   But the backend server that the load balanced vserver uses doesn't house the path "aaa" (and the devs can't change it).  The server houses the path "xxx".  Thus the need to swap out "/aaa" with "/xxx" in the path.

 

I thought if by setting up the following rewrite action and policy and attaching it to the LB vserver, that it would do what I need:

• add rewrite action rw_act_replace_aaa_with_xxx replace HTTP.REQ.URL.PATH "\"/xxx\""
• add rewrite policy rw_pol_replace_aaa_with_xxx "HTTP.REQ.URL.PATH.STARTSWITH(\"/aaa\")" rw_pol_replace_aaa_with_xxx

 

The CS vserver works just fine.  It is properly sending users to the correct LB vserver.  I can also see the rewrite policy and action getting hits.  It's just that when the LB server gets the request, the rewrite action doesn't seem to be re-writing like it should.  It seems to be shuffling it along with the request-URI "/aaa" intact.

 

Any help you could offer me would be greatly appreciated.