Responder policy doesn't hit

[Cristina Marletta Livi]

In Netscaler ADC VPX 12, we have a serious problem due to a responder policy that does not work in a certain case.
This is the scenario:
After a http to to https redirection (following https://support.citrix.com/article/CTX120664) the request is redirect to a virtual server (VIP_www.XXX.it_28.21:443).
4 responder policies are binded to virtual server VIP_www.XXX.it_28.21:443, all with action = DROP and GOTO Expression = END and an appfw policy is binded too.
The first responder policy is IP reputation policy (Expression = CLIENT.IP.SRC.IPREP_IS_MALICIOUS).
The second one blocks the access to administrative paths to all the ip except 3 specific ones. The expression is:
(HTTP.REQ.HOSTNAME.EQ("www.XXX.it") || HTTP.REQ.HOSTNAME.EQ("yy.zzz.dd.hh")) && (HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/dentroilpalazzo") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-admin")) && CLIENT.IP.SRC.EQ(ip1).NOT && CLIENT.IP.SRC.EQ(ip2).NOT && client.IP.SRC.EQ(ip3).NOT
where:
www.XXX.it is the FQDN
yy.zzz.dd.hh is public IP
ip1,ip2, ip3 are the ip enabled

A hacker has bypassed the second responder policy check, calling:
https://www.XXX.it/wp-admin/admin-post.php?page=yuzo-related-post

In log (ns.log) we find a message of violation of the HTML Cross Site Scripting in correspondence of this url (related to appfw policy), therefore the second responder policy
 was not hit.
 
Why? Are responder policies not evaluated before the appfw policy?

 

Regards,

Cristina

[Cristina Marletta Livi]

Hi.

Important information.

In the appfw profile APPFW_RFC_BYPASS is set.

The request is not RFC compliant (POST and query string).. is there an abnormal behavior of netscaler in this case?

 

[Rhonda Rowland1709152125]

2 hours ago, Cristina Marletta Livi said:

Hi.

Important information.

In the appfw profile APPFW_RFC_BYPASS is set.

The request is not RFC compliant (POST and query string).. is there an abnormal behavior of netscaler in this case?

 

 

https://docs.citrix.com/en-us/citrix-adc/13/application-firewall/profiles/enforce-http-rfc-compliance.html

Same as in 12.1.

Specific issue related to this setting (but not your issue):  https://support.citrix.com/article/CTX239367

 

The appfw has a new-ish RFC compliant check; by default if the request is NOT rfc compliant it will block the request. But this sometimes results in legitimate app traffic being blocked if the app isn't completely rfc compliant. In this case the behavior can be changed to bypass to not enforce this check. There is one global setting and another setting at the profile level.

If the request wasn't rfc compliant and set to block; then appfw should stop the request at that point, if that is one of our compliance requirements; you would usually see "malformed requests" violations in syslog.

 

I'm not aware of this setting impacting responder policies (as it shouldn't).  

 

You have two issues:

1) a xss attack that was identified by appfw and not blocked, because profile is not yet configured to take active protections. But this would have stopped the attack.

2) a confusing scenario where the request looks like it should have been caught by the responder policy, even if not handled by Appfw and we're not sure why that isn't going into effect as the usual causes of this issue don't seem to be the problem.  But I'll take a second look at the policy expressions when I have an ADC in front of me tomorrow.

 

So hopefully someone else will weigh in tomorrow with some additional insights.

[Cristina Marletta Livi]

Hi,

meanwhile, this morning, I added 2 appfw policies

. ip reputation

. check access to admin path:

(HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/dentroilpalazzo") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-admin")) && CLIENT.IP.SRC.EQ(ip1).NOT && CLIENT.IP.SRC.EQ(ip2).NOT && client.IP.SRC.EQ(ip3).NOT

 

Yesterday  the hacker tried to log in with the usual mode and was not blocked.

 

No INV_RFC no-compliance messages! Only an XSS check message,

as has already happened.

 

Regards,

Cristina

[Morten Kallesoslashe]

Did you get this resolved? I have a CS vServer where the responder does not work if i come from internal address, but it works from external.