Jump to content
Welcome to our new Citrix community!

App Firewall Auditing

Joseph Tuttle

Recommended Posts

Good afternoon all,


We are currently using Auditing Message Actions for formatting of responder policy logs. We are beginning to test AppFW and I am looking into how best to collect logs from that function. There is a way to assign a Auditing Message Action to the AppFW profile, and I have tested this with mixed results. I would like to ask the following for those that may have more experience than myself with AppFW. I find the AppFW logging a bit confusing. We are offloading to Graylog.


Example Audit Msg. Action format (this one is bound to a Responder that looks for old browsers and then formats the log as below): "Policy Violation: Drop Old Browsers |" + " XFF IP: " + HTTP.REQ.HEADER("X-Forwarded-For") + " | HOST: " + HTTP.REQ.HEADER("Host") + " | URL: " + HTTP.REQ.URL + " | USER AGENT: " + HTTP.REQ.HEADER("user-agent") + " | NSAction: Send To Map Screen"


 - It appears that when the AppFW policy is bound to a VIP with a "true", all traffic to said VIP triggers the log regardless of Policy Violation. Should this be the case, or should only policy violations trigger this? If I remove the Audit binding and violate policy, I get nothing in the logs regardless of AppFW logging configuration.


 - In the event of logged traffic as above, I get a AppFW event and most headers are accessible for logging, but AppFW specific data is not. Is there a way using the Audit Message Actions to include the policy violation information as well as regular header info? I do not see a method to recall this data.


Thanks in advance for any guidance you may be able to provide.


Link to comment
Share on other sites

I wouldn't use the audit message for this, unless your policy trigger/action is adjusted.


What your seeing is standard behavior for the advanced features, upon policy hit the log action is taken and the policy action/profile is evaluated.  For AppFw, this isn't what you really wanted.


The APPFW feature audits all violations it takes automatically. So without the audit log message, the policy "true" results in the traffic being compared against the signatures and/or profile, if a signature violation or profile security check violation occur, then the action (block/log/stats) is logged to syslog per the LOG enabled action for that signature rule or that specific security check.  As a result, you will get logs on violation and not for every policy evaluation/invocation.


If you use the audit message, then every policy hit is logged which as you noted occurs when the policy expression is TRUE which means, when true go compare against profile/signatures.  So now you got a policy log message on every policy hit and not just on the security violations.


For best results, only use log actions on appfw policies that use one of the quick actions:  appfw_block, _reset, _bypass, _drop.  And for which the policy expression alone is the trigger to stop traffic such as with IP reputation or callout blacklisting, so you can record why this policy was triggered and teh action taken.


For appfw policies with full profiles, use the expected "log on violation" behavior to note when a specific signature or security check blocks or mitigates an attack and not just every time the policy says go compare against profile.


If you have a policy that you want to drop old browsers, and it doesn't hit an actual profile, then use the custom log action when the policy triggers. If you are using the policy to say if old browsers go compare against this specific signature list, you would have better luck without the log action.


  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

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