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

[Rhonda Rowland1709152125]

If you look at the policy processing flow diagram:  https://docs.citrix.com/en-us/citrix-adc/12-1/getting-started-with-citrix-adc.html

AppFw IS processed first before Responder policies.

If you need to do ip blacklisting or other filtering prior to doing a deep inspection with appfw, use additional appfw policies to do the filtering with a quick action like appfw_drop, appfw_reset, or appfw_block, prior to running the deep scan inspection/signatures profile-based policy(ies).  Use responder as the "first entry point" for any vservers where AppFw is not in use.

 

Example:

bind lb vserver <vserver> -policyName appfw_pol_iprep -priority 100

bind lb vserver <vserver> -policyName appfw_pol_blockadminpaths -priority 110

bind lb vserver <vserver> -policyName appfw_pol_appAprofile -priority 200 # This one contains the actual appfw profile and will only be processed, if no prior violations are found

 

Or bind to global override if you prefer for the iprep and blockadmin paths policies...

Edited June 1, 2019 by Rhonda Rowland
fixed typo

[Cristina Marletta Livi]

Hi Rhonda,

thank you for your response.

Considers that the appfw policy has all the security checks in the log state.

Then, I expect the appfw policy to examine the request, identify the vulnerabilities and trace them in the log and then the responder policy blocks the request.

I also note that the appfw policy has GOTO Expression = END.

 

Regards

Cristina

[Rhonda Rowland1709152125]

AppFw as a feature runs before responder policies.  So, you will have to adjust your policies to get the behavior you want.

 

AppFw security checks are a high-cost security evaluation where as an ip blacklist or URL filter is a low cost evaluation.  If you are not using AppFw, then letting responder block or drop on this ipreputation or url blacklist is fine.

However, if you want to weed out overtly bad traffic before you do a high-cost appfw security check inspection, you will have to move your ipreputation and url filter criteria to an AppFw policy pointing to a default action and make sure this policies RUN BEFORE the appfw policy pointing to the high-cost/security check inspection.  All the triggers that responder can use to filter bad ips due to ipreputation violations or unwanted to requests to admin pages, you can use those expressions in appfw as well.

 

NOTE: about policy execution:

The GOTO expression END, means that if this policy hit occurs, don't look for more policies. If the policy doesn't match, its going to evaluate the next one in the list anyway. 

For a feature like responder, only one policy hit ever needs to be found as any responder action stops the current transaction: drop, reset, redirect, or other custom response.

For a feature like rewrite, the goto expression can be changed to NEXT so multiple matching rewrite policies can be found and therefore multiple actions apply. But most features on NS, don't do this.

For appfw, its a little different. Any appfw pointing to a quick action (meaning no profile/security checks included) like appfw_drop, appfw_reset, appfw_block works just like drop/reset/redirect in responder. The action applies immediately upon policy hit. And only one action can apply. So these would be done BEFORE any deep inspections.

Any Appfw policy that points to an actual appfw profile which consists of signatures and/or security checks is now doing more work. The policy hit, basically means "go do appfw inspection", and then if a violation occurs each signature or security check specifies what action to take on violation: block or transform depending on config.  If the traffic is in violation and a block is encountered, then that transaction is usually stopped by redirect (request-time) or actually dropped response time.  No further policies need to be evaluated regardless of the goto statement as that transaction is terminated.

 

When multiple policies for a given feature are bound, policies are evaluated in priority order per bind point until a matching policy is found (regardless of goto statement).  If no policies match, then no actions apply and the next feature is processed. If a policy match occurs, then the highest priority policy on that bind point (advanced engine), is applied. The GoTo statement determines whether more policies should be evaluated or whether we are first match and then done.  Features like responder/appfw are first match and then don. Rewrite the goto statement can be changed to find more policies.

 

 

So using the policy example I gave you above in the previous post:

If you want to achieve security through both blacklisting and url filters: 1) move these filters to the APPFW feature using the quick actions and 2) bind them at a higher priority than your appfw profile with the secuirty checks.   Keep the GoTo statement to END in this case.

 

If the ipreputation or url filter policies are hit first, traffic is dropped or redirected based on a low-cost evaluation and there is no need to a deep inspection for sql inejection/xss or other attacks as you've already dropped the traffic. If it passes the ipreputation and url filters, then you will do your appfw inspection and protect against attacks as your next level of defense.

 

 

 

 

 

 

 

 

 

[Cristina Marletta Livi]

Ok Rhonda,

thank you so much,

but I have a doubt more.

I've tried this URL:

https://www.XXX.it/wp-admin/admin-post.php?page=%3Bselect

 

The request is dropped and I can see 2 messages in the log: one from responder (blocked) and one (SQL Injection) from appfw policy (not blocked).

 

Why? This did not happen to the hacker.

 

Another question on policy priority.

The priority order for responder policies is: 100, 150, 200, 300.

The priority order for appfw policy is: 100.

Could this cause the lack of effectiveness of the responder policy in some cases?

I don't think so, the priority order applies only to the appfw and then to the responder policies separately. It's correct?

 

Thanks for your answer.

 

Cristina

[Rhonda Rowland1709152125]

In your AppFw profile for each security check you have to set which action(s) to take on violation: 

Default actions (per security check) are: BLOCK, LOG, STATS.  Then some security checks support LEARN and sometimes a TRANSFORM action like rewrite or x-out or remove.

 

If you have a security check in a profile, set so that BLOCK:OFF, but LOG:ON, STATS:ON

What you are telling the profile:  ON violation of sql injection, don't block (allow request), but LOG to syslog and track stats in nslog.

Often times the profile is set to "block:Off" mode so you can observe traffic for a while.  Tweak your settings so you aren't blocking too much and then turn on full protection: BLOCK:ON.

So the log event showing you a sql injection attack, but NOT BLOCKED, indicates LOG:ON but BLOCK:OFF.

 

To stop an attack, BLOCK:ON needs to be enabled.

Actions are set per security check.  For most request time checks: Block:ON means stop transaction be redirecting to the Profiles redirect url (profile settings). For cookie consistency check, a BLOCK action means strip cookies from request. For response time checks, a BLOCK action means terminate the response (can't redirect response-time).

 

Share a screenshot of your profiles security check summary page for additional details.

 

I'll answer the priority question next (so you don't have to wait; it will take a few minutes to explain).

 

[Cristina Marletta Livi]

Here the screeshots:

the responder policies (all drop and END)

and the security checks.

 

As I said, in my test the policies hits both.

Low performance, it's true but the request is blocked.

I don't understand why the hacker didn't have the same behavior.

 

Best regards,

Cristina

[Rhonda Rowland1709152125]

6 minutes ago, Cristina Marletta Livi said:

Another question on policy priority.

The priority order for responder policies is: 100, 150, 200, 300.

The priority order for appfw policy is: 100.

Could this cause the lack of effectiveness of the responder policy in some cases?

I don't think so, the priority order applies only to the appfw and then to the responder policies separately. It's correct?

 

Let's say you have a vserver, with the following policies bound:

lb_vsrv_demo_http

    rs_pol_sendtossl  #redirects to https://....

 

lb_vsrv_demo_ssl

    appfw_pol1_dropbyiprep                 appfw_drop                    priority 100

    appfw_pol2_dropbybadurls             appfw_drop                    priority 200

    appfw_pol3_appsec                          appfw_prof_appsec      priority 300

    

    rs_pol1_dropbyiprep                         DROP                                priority 100

 

 

In the above scenario, remember APPFW policies are evaluated BEFORE responder policies.

Advanced policy engine policy processing and bindings

1) Features are processed in a given order.  Meaning APPFW policies are evaluated (across all bind points), then RESPONDER, then Caching, and so on. Some features can preempt traffic, meaning if their policy hits occur and they take an action, the current transaction stops and no further policy evaluation occurs.

2) Advanced policies bind to the GLOBAL OVERRIDE, vServer-specific, and GLOBAL DEFAULT bind points.  The GLOBAL OVERRIDE is evaluated before vserver. vServer is evaluated before Global Default.  However, again, for features like appfw/responder and a few others, once a policy hit occurs then the highest priority action applies and there may be no further need to look for other policies, as their actions are less priority than the one you've already found.  Once, we decide to drop or reset a connection, there is no need to see if we need to drop or rest this transaction more as we can only do it once.

3) Priorities work within that bind point (per feature).  Also priority 1 overrides 10; 10 overrides 100; etc....

 

As a result, in the above scenario, if traffic hits lb_vsrv_demo_ssl, APPFW pol1, pol2, and pol3 are evaluated in priority order BEFORE we ever look at the RESPONDER policies. If the AppFw finds a violation and is configured to BLOCK the transaction, then the transaction is immediately redirected on the FIRST policy violation we find and no further appfw policies are evaluated AND there is no need to even look at the responder policy.

 

So, if you are coming from a bad IP and attempting a SQL injection attack, then appfw_pol1_dropbyiprep (priority 100) is evaluated before appfw_pol2.  So appfw_pol1 dropped your traffic and we don't attempt to look at any other appfw policies (or any other feature) as this transaction is terminated. If you weren't from the bad Ip or bad urls so neither appfw_pol1 or appfw_pol2 applied, then your request will be inspected by the appfw_pol3_appsec with the security checks and depending on its configuration the SQL Injection attack should be found (violation) and BLOCKED at this point, stopping the transaction.  Unless you transform the request, the transaction stops and we don't even look at later features like responder.

 

If no violations in appfw are encountered, then and only then will the  responder policy be evaluated in the above example.

 

----

If you are not getting the results you expect, you will need to share the policy bindings you are using AND maybe a summary of the appfw security checks, the redirect url you are using the profile (the whole profile would be hard to share), but you may have some conflicting settings that you aren't aware of.

 

 

 

 

 

 

[Rhonda Rowland1709152125]

4 minutes ago, Cristina Marletta Livi said:

Here the screeshots:

the responder policies (all drop and END)

and the security checks

 

So, the reason why AppFw is *not* stopping the violation, you have it inspecting for some attacks and logging them, but none of them are set to BLOCK:ON so it is not stopping the attack (which is what block means). To block on violation, block must be ON for the appropriate checks.  And profiles usually need to be configured to allow good traffic through while blocking bad.

Edited June 1, 2019 by Rhonda Rowland
added a missing "Not" to clarify the statement

[Cristina Marletta Livi]

But  I don't want to block the violation on security checks (non yet the security check must be relaxed) I want block on responder for IP and path violation.

In my test,  this happens why in the case of the hacker no?

[Cristina Marletta Livi]

The real scenario is:

lb_vsrv_demo_http

    rs_pol_sendtossl  #redirects to https://....

 

lb_vsrv_demo_ssl

    rs_pol1_dropbyiprep                 DROP   END                    priority 100

    rs_pol2_dropbybadurls             DROP_END                    priority 200

  ......                                                     DROP_END                    priority 300

 

 

 

    appfw_pol3_appsec                  appfw_prof_appsec      priority 100

    

 

[Rhonda Rowland1709152125]

Show the policy summary with their expressions and the profiles they point to. And confirm that these are all bound to the HTTPS vserver and not just the HTTP one.

 

Is the attacker's request coming from something that matches the IPREP ip list or the URL in the bad url list? You can have an attacker who is not on the known malicious IP list maintained by webroot's bright cloud service and just an individual hitting your site; in which case you would need a custom blacklist filter that you maintain manually or via http callout in addition to the bright cloud service.

 

If no, then the only violation is the SQL Injection attack.

 

[Rhonda Rowland1709152125]

I re-read your policies from the beginning.

 

One other thing you can do, is to add a log action to the responder policies. So you will see their hits get logged to syslog as well. So you can see when the appfw policy hit occurs and the responder policy hit occurs. 

 

When your attacker hits, appfw is processed first and logs the sql injection or xss violation but takes the NOT BLOCKED behavior, so additional request processing occurs.

The responder policy doesn't log its action by default, so you may not see a record in syslog unless youconfigure the log action on the responder policies.

Once appfw is done and allows the request, responder should be hit. With the log action, you should now be able to confirm that when the evaluation occurs.  Responder won't stop the traffic until AFTER appfw says, "i saw a violation, but you told me not to stop it."

 

Otherwise, there is an issue in your policy expression. What I THINK you want the policy to filter urls to do is to block any access to the specified paths, if NOT coming from one of the allowed IP addresses. If that is not the logic you intend, clarify and we may have to tweak that policy.

 

Your original expression you stated above:

 

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

 

A couple quick notes:

your .eq() comparisons are case-sensitive, so it may be getting by this evaluation due to case. And I would tweak the parentheses to guarantee order of operations as the original posting may have been missing some required ones.  Corrections below:

 

((HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).EQ("www.XXX.it") || HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).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))

 

If you are not using the proper hostname && url paths, it should drop requests.  AND if it is NOT from one of the allowed IP addresses: ip1, ip2, ip3. (The parentheses may have been right originally, I just need to see it to reconfirm.)

[Cristina Marletta Livi]

All the policies are bound to the HTTPS server.

The only policy bound to HTTP server is the responder thhp_to_https.

 

The URLtried from hacker is:

https://www.XXX.it/wp-admin/admin-post.php?page=yuzo-related-post

(with POST method).

I can see the URL in security check violation.

 

In my above scenario:

the PI expression of rs_pol2_dropbybadurls   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

 

his IP is not in the list of 3 IPs.

The PI expression of appfw_pol3_appsec is 'true'.

 

 

 

 

[Rhonda Rowland1709152125]

Just to confirm there isn't a logic problem here, do you want to block any request to this site that is not from the allowed IPs OR only block requests to these hostname/path combinations IF from a not allowed IP?  Because traffic going to the wrong path and NOT these ips will be allowed and not prevented in current expression.

 

If you need to block all traffic NOT from these IPs regardless of path/hostname, we need different logic.

If you only want to block access to these paths/hostnames from these IPs, then your on the right path, though you could skip the hostname comparison (as you are already on this vserver) and just do the path and IP comparison.

 

 

One other policy change you could try:

Change this:

((HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).EQ("www.XXX.it") || HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).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))

 

To this:

((HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).EQ("www.XXX.it") || HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).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) || CLIENT.IP.SRC.EQ(ip2) || client.IP.SRC.EQ(ip3)))

 

This should be equivalent, but might show if the .not operator is the problem.  The other thing, simplify the policy during testing and make sure the three main phrases work individually.

DROP for hostname

DROP for path

DROP for not allowed IP

 

Then you can work on the logic combining them. It looks right to me, but I could be rushing through the evaluation.

 

[Cristina Marletta Livi]

All the responder policies have a log action.

No message corresponding to responder for the hacker.

 

In my expression:

www.xxx.it is lowercase

yy.zzz.dd.hh is an address

 

((HTTP.REQ.HOSTNAME.EQ("www.xxx.it") || HTTP.REQ.HOSTNAME(ignorecase).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))

 

 

The URLtried from hacker is:

https://www.xxx.it/wp-admin/admin-post.php?page=yuzo-related-post

(with POST method).

I can see the URL in security check violation log.

[Cristina Marletta Livi]

Hi,

but...

((HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).EQ("www.XXX.it") || HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).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))

 

((HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).EQ("www.XXX.it") || HTTP.REQ.HOSTNAME.set_text_mode(ignorecase).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) || CLIENT.IP.SRC.EQ(ip2) || client.IP.SRC.EQ(ip3)))

 

have the same logic: because:

NOT (A OR B) =  (NOT A) AND (NOT B)

 

This is confirmed by my test.

If I try:

https://www.xxx.it/wp-admin/admin-post.php?page=%3Bselect

from not admitted IP, the request is blocked and I can see 2 messages in ns.log: one from responder

and one from appfw policy.

 

I don't understand how the hacker could have skipped the PI expression of the responder policy.

[Rhonda Rowland1709152125]

They are supposed to be equivalent; I was just testing there wasn't an issue with the .not operator in this case.

Keep in mind that if they connect by IP instead of hostname, this policy won't trip. If they  connect UPPERCASE in hostname, your policy as written won't hit. 

Which is why I wanted to confirm if you want to drop any request from disallowed IPS or only requests to specific fqdns/paths from specific ips. This will possibly require a change to the logic to make it harder to bypass.

Other things:  Is the responder feature enabled?  And make sure responder policy is pointing to drop and not NOOP.  

 

This is why it might be worth simplifying the logic in pieces.

 

I'm thinking on this and will let you know if I think of anything else.

 

The appfw violation will always be logged, whether responder applies or not (becuase appfw evaluates and applies first). So then we just need to make sure responder is going into affect (and just not being logged) or if its missing evaluation for some reason.

 

[Cristina Marletta Livi]

Why if they connect by ip the policy doesn't work?

[Rhonda Rowland1709152125]

Your policy is essentially:  (A && B) && !C

where A is your HOST header

where B is your PATHs

where C is your allowed IPs. (Not on list is blocked, but only if A&B is true)

 

If the user connects https://vip1/wp-admin/<stuff>

If an attacker connects via IP instead of name, then the host header <VIP1> is not one of the values you are looking for. So the responder policy to block traffic will never evaluate to TRUE (hit) in this case, even if they come from a bad IP. The attacker would "bypass" your policy because its a condition you aren't blocking on.  We're only blocking requests from bad IPS to the specific hostname/path combinations. If your outside that hostname/path combination, then the source ip doesn't matter.

 

That's also why being case-sensitive in your original policy is bad. If you only look for www.xxx.it and attacker comes in as WWW.XXX.IT, then your policy as written won't trip regardless of the source ip either.

 

If you want to block all access from unapproved IPs, then the expression needs to be different.

If you only want to block requests to specific paths from unallowed ips, then we just need to make sure your current policy isn't too narrow.

 

Like I said, if your load balancing (as opposed to content switching), you can ditch the host header check and only look at the paths and IP combinations.

 

 

 

 

 

[Cristina Marletta Livi]

Hi Rhonda:

. The url used by the hacker (found in ns.log) is lowercase and use hostname:

https://www.xxx.it/wp-admin/admin-post.php?page=yuzo-related-post

. The same url tried by me from a unauthorized ip is blocked.

 

If you check my condition, in expression you can find zz.yyy.dd.hh.

This is public vip not an hostname.

 

I don't understand....

.

[Cristina Marletta Livi]

Please, check if there is an issue with not operator...

 

[Rhonda Rowland1709152125]

56 minutes ago, Cristina Marletta Livi said:

Hi Rhonda:

. The url used by the hacker (found in ns.log) is lowercase and use hostname:

https://www.xxx.it/wp-admin/admin-post.php?page=yuzo-related-post

. The same url tried by me from a unauthorized ip is blocked.

 

If you check my condition, in expression you can find zz.yyy.dd.hh.

This is public vip not an hostname.

 

I don't understand....

.

 

I forgot that your reference to zz.yy.dd.hh was the VIP and not an alternate FQDN; I thought your policy wasn't handling this scenario.

 

 

[Cristina Marletta Livi]

Any other ideas?

I can modify the expression policy but if I don't know how the hacker passed the check, I don't know how to fix it.

 

[Rhonda Rowland1709152125]

I won't have access to a NS until tomorrow, so if anyone else has ideas before then hopefully they will post. Double check the notes on log actions I included in case the policy is being hit and not logging (just in case, its an easy fix.)

 

1) What version of NS firmware are you running, in case there is a version specific issue?

2) You gave a summary of the 4 policies in use, can you share all 4 policy configs and specify their bind point and priorities. Are  you just doing load balancing or is a cs vserver involved? Anything else that might affect the processing flow. And for the the policies in that summary do ALL of them have a log action specified?  Are any of this log actions being observed?

 

If you're concerned about sharing the policy expressions in the forum, you could obscure them OR private message. I'm mainly just trying to see if a different policy is being hit first (and not logged) so the one you're expecting is not going into effect.

 

Keep in mind that if appfw logs the violation, but the responder policy is hit, then the request was still blocked by responder (appfw just ran first). Without a logaction, responder policy actions are not logged to syslog.  A few extra things to note about log actions in case its a factor of just not being logged:

• Features like rewrite/responder support log actions; otherwise they don't log to syslog.
• Verify the log level is something you are reporting in syslog; for example if you have it set to DEBUG but you are excluding capture of DEBUG it won't show up. I would recommend INFO or higher depending on your use case.
• By default log actions log to syslog (/var/log/ns.log). If you choose in the log action to log to newnslog, then the event shows up in nslog (/var/nslog/newnslog) which may not be what you are expecting. I would recommend keeping this setting off and continuing to log to syslog.
• ALSO: Remember, even if a log action is specified, it STILL won't show up in syslog UNLESS you enable the "Show custom log messages" in the syslog local parameters or external audit policy.  If you are looking at the local syslog, verify the global audit parameters for syslog. If looking at an external syslog, then double check the syslog audit policy in effect.

 

If you aren't seeing the responder policies hit at all, then something else is going on. Are there any other global policies that might be in effect or any other responder policy that have a NOOP action (as that would prevent later responder policies from being evaluated.)

 

If you are using content switching in addition to load balancing, are there any additional policies on the CS vserver that may hit first before the lb vserver are evaluated; again especially if log actions aren't specified as responder policy actions won't show up in syslog by default without it.

[Cristina Marletta Livi]

Hi,

here the answers:

1. CitrixADC VPX Release 12.1 49.23 nc

2. There is 2 vserver, lb_vsrv_demo_http and lb_vsrv_demo_ssl:
   
virtual server: lb_vsrv_demo_http

 rs_pol_sendtossl  #redirects to https://....

virtual server: lb_vsrv_demo_ssl

    rs_pol1_dropbyiprep                 DROP  END                  priority 100

    rs_pol2_dropbybadIPadmin     DROP  END                  priority 140

    rs_pol3_dropbadIPservice         DROP  END              priority 200
    
    rs_pol3_dropbadIPcontent       DROP  END              priority 300

    appfw_pol3_appsec                  appfw_prof_appsec           priority 100          
 

rs_... are responder policies                                        
appfw_pol3_appsec is an APPFW policy

 

No content switching, no override global.

All active security checks in appfw_prof_appsec are in Log and Stats status.

Each responder policy has a specific log action.

Responder Expressions:

rs_pol1_dropbyiprep: CLIENT.IP.SRC.IPREP_IS_MALICIOUS

 

rs_pol2_dropbybadIPadmin: (HTTP.REQ.HOSTNAME.EQ("www.demo.it")|| HTTP.REQ.HOSTNAME.EQ("public VIP")) && (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

 

rs_pol3_dropbadIPservice: (HTTP.REQ.HOSTNAME.EQ("www.demo.it") || HTTP.REQ.HOSTNAME.EQ("public VIP")) && client.IP.SRC.EQ(ip4).NOT && client.IP.SRC.EQ(ip5).NOT && client.IP.SRC.EQ(ip6).NOT && HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-json/wp/v2")

 

rs_pol3_dropbadIPcontent: (HTTP.REQ.HOSTNAME.EQ("www.demo.it")|| HTTP.REQ.HOSTNAME.EQ("public VIP")) && CSP_path_wpcontent && CLIENT.IP.SRC.EQ(ip1).NOT && CLIENT.IP.SRC.EQ(ip2).NOT && client.IP.SRC.EQ(ip3).NOT && CLIENT.IP.SRC.IN_SUBNET(10.0.0.0/8).NOT

 

CSP_path_wpcontent is an expression:
(HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-content/languages") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-content/logs") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-content/plugins") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-content/themes") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-content/upgrade") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-content/uploads") || HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/wp-includes")) && (HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("select") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("where") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("union") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("like") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("and") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("insert") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("delete") || HTTP.REQ.URL.QUERY.TO_LOWER.CONTAINS("update"))

 

I'm sure the hacker's request came to the web server since, in the web server access log I can see a corresponding POST message (same time, same IP, same URL).

His request URL is:
https://www.demo.it/wp-admin/admin-post.php?page=yuzo-related-post

A corresponding message is present in our Netscaler external syslog server. It is an XSS message written by the appfw policy.
No messages from responder policies.

 

Then, I'm sure no responder policy hits.

Should have hit the rs_pol2_dropbybadIPadmin policy.

Why?

Regards,

Cristina