Jump to content
Welcome to our new Citrix community!

Capture source IPs on VIP for any connections which are using weak ciphers

Recommended Posts

IF its web content; you can use client ip header insertion either by adding it to the service properties of the affected vms or better option assign an http profile to the lb vserver(s) with the weak ciphers to do client ip header insertion. You can then log this on backend.


IF you want this logged in syslog (note almost wrote "webbed in syslog"...so that was fun) on the ADC, then you could assign a responder policy to the lb vserver, with a NOOP responder action AND an audit syslog action that could log details like client.ip.src and client.ip.vip and/or vserver name as part of the logging action.

Enable "user custom log messages" in your local syslog parameters and any external audit policy you have to display this info.




Link to comment
Share on other sites

OK, so basic demo, though you can adjust based on URL, logging messages, and the exact cipher suite you are looking for. (Don't forget, you can also change the preferred order of ciphers in the cipher list and clients that support a new vs old cipher will choose the NEW one first if it is first in the list over the older one; if the older one is first it will choose the older one.)  So you may be able to reduce clients using old ciphers by changing the cipher order in the group and even removing less desired ciphers.  But at least by changing the order, you will find only the clients that use the "older" ciphers only when they can't use a newer on.


This example does the following: 

  • enables custom log messages in the local syslog of the ADC.
  • creates a responder policy whose action is NOOP (no actual responder action) whose purpose is to look for criteria using the unwanted ciphers (adjust example based on exact cipher name on ADC that you are looking for if not the one I demo with).  Upon policy hit (based on cipher match), it will then use the audit message log action.  Log action is set to "warning" for this example and a simple message for policy name, client ip, vip, and cipher in use.  All can be customized.
  • Default responder binding (goto is set to end) stops processing after highest priority policy hit occurs.  If you want other responder policies to process after the NOOP bind this one to the SSL vserver with a high priority and choose the goto expression as NEXT to see if other policies (drop/reset/redirect apply) after the NOOP is performed.

CLI example follows: replace lb_vsrv_demo_ssl with your actual lb vserver of type ssl.



# 1) enable inclusion of custom log message in global (local) syslog audit policy; for external logging update parameter in remote policy action too

#     GUI:  System > Auditing.  (Right pane) Change Auditing Syslog Settings (aka global audit parameters governing local logging)

set audit syslogParams -userDefinedAuditlog YES

# 2) create the audit message to include with the responder log action.  Gui:  System > Audting > Message Actions

add audit messageaction audit_act_customlog_sourceips WARNING "\"rs_pol_noop_logonly:  \" + \"client ip: \" + client.IP.SRC + \" connected to vserver: \" + client.IP.DST + \" with cipher: \" + client.SSL.CIPHER_NAME"

# 3) create the responder policy with the NOOP (no operation/do nothing) action and a LOG ACTION. Will fire log event when policy criteria is met.

#    adjust cipher list based on actual cipher names on ADC (Traffic Management > SSL > Cipher)

#    GUI:  AppExpert > Responder > Policies

add responder policy rs_pol_noop_customlog_sslcipher "client.SSL.CIPHER_NAME.SET_TEXT_MODE(ignorecase).CONTAINS(\"TLS1-AES-256-CBC-SHA\") || client.SSL.CIPHER_NAME.SET_TEXT_MODE(ignorecase).CONTAINS(\"TLS1-AES-128-CBC-SHA\")" NOOP -logAction audit_act_customlog_sourceips

# 4) bind policy to the necessary lb/cs vserver of type SSL

#  policy needs to be highest priority (aka first in list).  If you need to process other policies after the NOOP/logging policy; then change the goto expression from END to NEXT (in BLUE)

#  alternate example shown below...

#  I used priority 10 to make it process first...

bind lb vserver lb_vsrv_demo_ssl -policyName rs_pol_noop_customlog_sslcipher -priority 10 -gotoPriorityExpression END -type REQUEST
## bind lb vserver lb_vsrv_demo_ssl -policyName rs_pol_noop_customlog_sslcipher -priority 10 -gotoPriorityExpression NEXT-type REQUEST

  • Like 1
Link to comment
Share on other sites

1) Local syslog file limits rollover of file to every 100 KB and every 1 or 2 hours (depending on version). Local copies are limited to the last 25. And there is a file that can be used to change local log retention and rollover.  https://support.citrix.com/article/CTX121898


2) External logging for long term retention is configured through syslog audit policies.  Bound to system global they capture all system-wide syslog events and forward to external location.

If bound to a lb vserver or vpn vserver, then they log just events related to those vservers.  If multiple syslog policies bound, then logging will go to multiple policy locations.

Typically, System > Auditing:: (right pane) will give you the syslog parameters which governs local logging. Keep the parameters logging locally, but you can tune logging details. This is separate from the log rollover above.  Then create additional syslog audit actions and audit policies under System > Auditing > Syslog. And bind those policies to system global as policies.

You'll then get syslog to external destinations by the policy(ies) and continue local logging via the syslog parameters.   Policies are in the Admin guide under the system section (for auditing)





Link to comment
Share on other sites

Hi Rhonda, 


Thanks for your suggestion ..


I have configured Vserver with this responder policy. 


When we did test by doing the scan from Qualys  https://www.ssllabs.com/ site, we were able see source IP capture on sys logs.


But when we did scan from some source server using openssl feature by specifying CBC weak ciphers, we were able to see connections on nsconnections table but we did not see the same connection captured source IP on syslog and also I observed that hit count on this response policy did not increase its value.


We took wireshark capture on client machine for the same.  Please refer as below  




My question is why this connection did not get tracked in syslog capture ? Was it because of TSL version which 1.2? and Are we capturing only TSL version 1 , not a 1.2?  

Link to comment
Share on other sites

You can log everything if you want; but you asked for how to filter when certain ciphers were in use and that is what the filters are doing.

If the cipher in use is not in the expression for the policy specified it will not be logged.


If you want to temporarily log all traffic regardless of cipher as you figure out which list you need, change the responder policy to "true". To capture all traffic.

Or add to the cipher list you want to log for.



Link to comment
Share on other sites

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