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

Avoiding to log sensitive information


Johannes Norz

Question

With ADC 13.0 onward, we have the possibility to avoid logging sensitive information like passwords (https://docs.citrix.com/en-us/citrix-adc/13/application-firewall/logs.html#mask-sensitive-data-using-regex-pattern). I'm using 13.0 83.29. That's what I wanted to do, however, it didn't work like expected. No matter, if I'm useing CEF logging, or traditional logging:

 

I created an extended logging policy and bound the following action:

 

bind appfw profile loggingtest -comment Password -logExpression no_log_passwd "HTTP.REQ.BODY(10000).REGEX_REPLACE(re!(?i)\\bpasswd1(:|=)\\s*\\w*\\b!, \"passwd1=xxx\", ALL)"

 

 

The result is not exactly, what I expected. Log without logging policy:

Jan  4 10:10:18 <local0.info> 192.168.229.10 CEF:0|Citrix|NetScaler|NS13.0|APPFW|APPFW_FIELDFORMAT|6|src=192.168.229.1 spt=8277 method=POST request=http://192.168.229.222/ msg=Field format check failed for field passwd1\="426" cn1=65511 cn2=65129 cs1=loggingtest cs2=PPE0 cs4=ALERT cs5=2022 act=blocked

 

Log with logging policy:

Jan  4 10:12:45 <local0.info> 192.168.229.10 CEF:0|Citrix|NetScaler|NS13.0|APPFW|APPFW_LOGEXPRESSION|6|src=192.168.229.1 spt=8277 msg=uname\=test&passwd1\=xxx cn1=65510 cn2=65129 cs1=loggingtest cs2=PPE0 cs4=ALERT cs5=2022 cs7=no_log_passwd
Jan  4 10:12:45 <local0.info> 192.168.229.10 CEF:0|Citrix|NetScaler|NS13.0|APPFW|APPFW_FIELDFORMAT|6|src=192.168.229.1 spt=8277 method=POST request=http://192.168.229.222/ msg=Field format check failed for field passwd1\="426" cn1=65511 cn2=65129 cs1=loggingtest cs2=PPE0 cs4=ALERT cs5=2022 act=blocked

 

So the password appears anyway, however, there is a 2nd log with the removed password as well.

 

I thought, I could remove logging for form filed consistency, but that's not a good solution as it will remove both log entries. For all the rest, it will try to log a password, no matter, if there is a password, or not, the only difference is (this is a log for a deny URL):

 

Jan  4 10:23:45 <local0.info> 192.168.229.10 CEF:0|Citrix|NetScaler|NS13.0|APPFW|APPFW_LOGEXPRESSION|6|src=192.168.229.1 spt=43864 msg= cn1=65543 cn2=65156 cs1=loggingtest cs2=PPE0 cs4=ALERT cs5=2022 cs7=no_log_passwd
Jan  4 10:23:45 <local0.info> 192.168.229.10 CEF:0|Citrix|NetScaler|NS13.0|APPFW|APPFW_DENYURL|6|src=192.168.229.1 spt=43864 method=GET request=http://192.168.229.222/denyme msg=Disallow Deny URL for rule pattern\="/denyme". cn1=65544 cn2=65156 cs1=loggingtest cs2=PPE0 cs4=ALERT cs5=2022 act=blocked

Any ideas?

 

Logging.jpg

Link to comment

3 answers to this question

Recommended Posts

  • 0

It worked different to what I thought. The correct method is using "Confidential Fields" https://docs.citrix.com/en-us/citrix-adc/current-release/application-firewall/configuring-global-settings/confidential-fields.html

 

add appfw confidField Passwd1 https://gateway.abc.de/.* -isregex REGEX -state ENABLED

 

just in case, someone crashes into the same problem :)

 

Johannes Norz

https://norz.at

Link to comment
  • 0

The difference *may* be that the custom loggingpolicy/logactions apply when appfw policy HITs occur aka anytime the traffic is compared against the policy to do an appfw comparison.

But a security check LOG action occurs during a security check violation.   

 

My guess is that you are seeing both events and the logging action is only going to mask content during the appfw policy expression is true (then go do appfw profile inspection AND the logging action).  So the regex_replace is only affecting the appfw policy expression hit's logging action. But it has no impact on the security check is in violation, now log based on security check behavior.  The masking of the field contents is then governed by the confidential field as Johannes reported.

 

Its not what I would have expected, yet it doesn't surprise me either. But it just means I don't necessarily see the benefit of the logaction on the appfw policy hit to replace fields, except for when you 1) are logging all policy hits and 2) the content would be vulnerable and the confidential field rules don't apply yet.  (Note: this is just my two cents.)

 

 

 

 

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