Jump to content
Welcome to our new Citrix community!

Responder policy to drop requests containing JNDI strings

David Chivers

Recommended Posts

Thank you for sharing your solution, David.  To the best of my (limited) abilities, I'm comparing it to the guidance Citrix has provided at:




Do you see any advantage to either your or Citrix's approach?  We've implemented Citrix's solution below for three vServers and are looking to see if any problems pop up.


add policy patset patset_cve_2021_44228
bind policy patset patset_cve_2021_44228 ldap
bind policy patset patset_cve_2021_44228 http
bind policy patset patset_cve_2021_44228 https
bind policy patset patset_cve_2021_44228 ldaps
bind policy patset patset_cve_2021_44228 rmi
bind policy patset patset_cve_2021_44228 dns

  • Like 2
Link to comment
Share on other sites

I would think it should include HTTP.REQ.URL? Though I think/suspect it is as simple as duplicating the two OR clauses and changing the beginning keywords ..


? (untested.. just thinking..) but effectively




And inserting it properly into the policy?


And wonder if they will post guidance for CVE 2021-45046 (just not familiar with all the ins and outs of these patterns yet)

Link to comment
Share on other sites

@Robert thanks for the reply. That policy from Citrix appears to more thoroughly check for obfuscation, and also checks the body of POSTs so use that one instead. I have edited my question to remove my lesser solution to avoid confusion. I did bind some more lookup protocols to the pattern set for our use:

bind policy patset patset_cve_2021_44228 iiop
bind policy patset patset_cve_2021_44228 nis
bind policy patset patset_cve_2021_44228 nds
bind policy patset patset_cve_2021_44228 corba


@Andrew the expression HTTP.REQ.FULL_HEADER includes all headers including the URL header.

The Citrix solution searches the entire request header and the first 8kb of the request body twice to match against different types of obfuscation. The common GET request doesn't even have a body, and responses are not scanned.


We use ADCs for a number of sites and services public and internal. I mentioned to our help desk users with HTML Receiver connections (the "light version") might experience some lag, so they might want to guide users to using the "full version" of Workspace App if they have any problems.

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