Jump to content
Welcome to our new Citrix community!

WAF profile to monitor specific URL


Sohel Shaikh

Recommended Posts

If you mean "observe"/non block mode vs block mode but where you can still learn on it...  (f you meant something else by observe, please clarify.)

You would need to profiles and two policies.

 

policy 1 would need the expression for the URL of concern and hits on that URL (and its dependent objects) would be handled by the settings in profile 1.

policy 2 would then catch everything else (on that vserver) and go to your regular profile in block mode.

 

It might be easier to do separate this traffic via content switching and then bind the policy/profiles at the separate lb tier; might allow you to more broadly define the "hits" to make sure nothing is missed.

 

If there is something you are trying to do such as audit or something other than to continue learning this subset of the application, there might be other ways to accomplish what you want with more context.

 

 

Link to comment
Share on other sites

Thanks for your reply you get it correctly I want to keep 1 URL to be in observe/non block and all other URL in block mode.

Just a question rather than creating content switching towards a separate LB IP can we not map 2 WAF policy in a single LB VIP with different priority? Does it will call both polices are only highest priority policy will be in effect?

Link to comment
Share on other sites

You can use two policies/profiles on one vserver with no overlapping expressions or use content switching.

If you have overlapping expressions things may result in unexpected behaviors...as you would still block the traffic you just observed.

 

Example 1 (overlapping policies)

If you have policy1 and policy2 that both apply, with expression true: highest priority policy will be processed first. If you have the goto expression set to next (if possible, in appfw), then if first policy is processed and NO VIOLATIOn occurs with a block action, then in theory the next policy will be processed as well.  (If your policy bindings are set to end; then it will only process first expression match.)

If the first policy encounters a block, then no further processing occurs.  (Though this would need testing because appfw processing is a little different than other features.)

 

But to run the traffic through appfw evaluation twice is rather resource intensive.

 

Example 2: make so the expressions don't overlap.

Have policy 1 (high priority) only affect the traffic you are observing/not blocking on.

Then policy 2 affects everything else.

more efficient, but you have to think of what if anything you are not protecting the same way.

 

If your goal is to log hits to a specific URL and still process appfw anyway on the same url, then there are other ways to log hits outside of appfw while still protecting it.

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...