Jump to content
Welcome to our new Citrix community!
  • 0

WAF Violation Logging

Joseph Tuttle


I am testing AppFW as part of our existing ADC deployment. I am having an issue with the logging of violations. I setup a test site and determined a way to replicate policy violation for testing. For most responders and such, I am using custom audit messages shipped to an external syslog. 


In the case of AppFW, I build the profile with logging configured on the desired settings. I then create a policy with a TRUE statement. If I add a log action to the policy, all traffic to the VIP is logged properly. However, the actual violations are never logged that I can see. Not even internally in ns.log. One of the violations I am testing is CSRF. I found a way to consistently replicate a policy violation. I bound the policy both WITH and WITHOUT log action on the policy, and with logging enabled on the profile objects. I run a tail - f /var/log/ns.log | grep APPFW and create a violation. Nothing is logged. I tried  tail - f /var/log/ns.log | grep CSRF. Nothing. I view the CSRF logs in in GUI. No violation recorded, but the violation action (redirect) DID happen. 


It's like AppFW policy violations are not being logged at all.


What am I missing??? Help!

Link to comment

6 answers to this question

Recommended Posts

  • 1

General AppFw Logging info (I know you're aware of some of this, just covering the bases):

With AppFw, the audit action will log every policy hit.  The purpose of the appfw policy is to compare the traffic against the configured security settings aka the signatures and profile.

Usually, logging every policy hit is too much, unless you are trying to confirm policy hits are occurring.  Or using appfw for a quick action like appfw_block, _reset, _drop for a trigger like ip blacklisting.


What determines if the VIOLATIONS are logged is the configuration of the security check/signatures themselves.  For each security check (Start Url, Deny Url, etc), you have a series of actions:  BLOCK, LOG, STAT and then occassionally LEARN or alternate actions like X-out or remove.

Each of these actions occur only "ON VIOLATION" of the specified check.  On violation, block (take prevention action); on violation LOG to syslog, on violation, track STATS in nslog etc...


So, if you are testing your CSRF violation the LOG should determine the logging behavior (or the START URL Logging action would determine logging if using Referer header violation instead).    If you are seeting block behavior, but not the expected result.  1) You might have a different security check being hit first and ensure it is also set to LOG OR 2) your local syslog settings ARE not capturing the appfw violations due to logging levels or other details.


Troubleshoot SYSLOG Settings:

Assuming you have LOG enabled on all the potential security checks. Focus on logging.


Are you relying on the local syslog settings (global audit parameters) or an external logging policy?

1) - For local logging, double check the syslog global audit parameters. For external logging, double check the appropriate syslog audit policy and action.  And confirm the ip destination of the logging policy. For example local logging in the syslog parameters should go to the localhost address. If a remote IP than all your logging is external. If you have the local logging parameters AND a log policy, then you should get logs in both places.

2) - Make sure the correct LOGGING levels are included. AppFw events may require INFO and higher to be logged, until you can confirm which level is being reported. (I had a student whose local logging only captured EMERGENCY and higher) and so no appfw events were caught.  Adjust in either the syslog audit parameter or appropriate syslog policy action.

3)- If someone else configured your ADC, it is also possible that AppFw logs could have been split out from syslog and now appear in their own log and therefore you might be looking at the wrong place.  Try this article for reference:  https://support.citrix.com/article/CTX138973  and check to see if the appfw.log has been set to a separate log facility in the /etc/syslog.conf file... article has the rest of the details.


Additional thoughts:

If still no luck, CSRF is a bit tricky sense it overlaps with how Start URLs are configured and whether you are doing Referer Header validation or CSRF form tagging.

What I would do is go back to earlier security checks like start/deny urls and buffer overflow and see if you can confirm these violations are logging or not.  Make sure start urls are properly configured, and then resume to CSRF testing.  I would also confirm that you have logging enabled for all potential security checks that you are actively processing to see if they are in fact hitting before CSRF as a starting point.







Edited by Rhonda Rowland
Added notes.
  • Like 1
Link to comment
  • 1

A couple of thoughts.

1) If that is your global syslog parameter (System > Auditing, then right pane for syslog parameters), then it is not logging locally and you would have to look at the external option here or in any other audit policy.  I don't recall if appfw violations log at info or higher, so you might include informational in the list just in case.


2) On the profile, You have Start and CSRF set up for block on violation and logging.  So it might just be the log level causing the problem.  Once you get any Appfw violations showing up in log, you should then be able to figure out if a different security check is blocking before others.

I might personally turn stats on too; but if you are getting violations from any check, it should be logged. (Unless exclude informational is the problem here.)


If none of this helps, hopefully support will.


  • Like 1
Link to comment
  • 0

Thanks Rhonda. That gave me a few other things to check with no success. I checked logging levels all the way down to debug and can get no APPFW logs at all. Even if StartURL was causing an issue, it should still be logged.  I looked and did not see a potential dedicated log and checked that the logging server is bound globally. I'm kinda at a loss. I opened a ticket with support. We will see. I will post back here when I have resolution. Your feedback is always super helpful!

Link to comment

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...