Is there a definitive guide to configuring the Netscaler Global Deny List? I believe that is the "cve mitigation/virtual patch" solution citrix is touting. I've gone through the tech zone article but of course, the commands don't return matching info. I think I'm going down a rabbit hole of the WAF auto signature udpates on the netscalers themselves rather than the netscaler console. I'm not seeing any signatures getting updated from the netscaler console despite having the console cloud connect configured, all my netscalers in inventory, etc.

Let me know if you found any useful information about configuring virtual patching. I'm also a bit clueless about the configuration. As far as I understand, enabling "virtual patching" in netscaler console is all you need to do (??). When a CVE hits and you are not patched yet, the netscaler downloads a signature and adds it to a global deny list policy in netscaler.

From what I understand - you need to check "asset delivery" in the console, and have the netscalers in inventory. However, after doing that, the encrypted version of the *Default Signatures on my netscalers never increases past 0. The tech zone article also says to run a 'stat denylist global AAA_REQUEST' which my devices return nothing for. I went down a rabbit hole of trying to configure automatic signature updates on the netscalers themselves, which require access to an S3 bucket. Even that doesn't work correctly - I have 2 pairs of netscalers, where only one of the 2 has updated to version 184, from 175, but even then the encrypted signatures is reporting 0. I have a case open with Citrix and they haven't come back with anything of value (surprise!) despite having a trace file and support bundles for them. Once I get this situated, I'll definitely do a write up for what I am missing

The main issue here is - when you're on a "fixed build" with no CVE's to it - there is no GDL signature update. I got that from a PM months ago where I was questioning myself the same on "how can I test, if the connection is successful and a GDL rule is applied" "However, if you upgrade to the fixed builds GDL won't be applicable because the vulnerability would have been addressed by means of a code fix already."

Hmm - I'm currently on 73.41, not 73.46 and I still have no encrypted signature version number which I would expect since it's not the latest code. Hard to put a lot of faith in something you cant validate without running code that has bad CVEs...

Similar to the WAF for gateway that has a ruleset that we can't see, in my opinion. Feels a little.. "trust me, it works". Well, does it?

You can view the logs to see if the WAF is getting hits. Additionally, the NetScaler Console and Console Service both will show WAF and threat attempts if configured to do so. This will show you that it is or is not working. I have not really tried out the In Service Software Upgrade (ISSU) capability yet with NetScaler. I may try and do a lab test out of it. This would enable the upgrade of your NetScaler firmware and failover without interruption. There are very stringent requirements (like NIC speeds matching for prod and management, no Azure or AWS support, etc.) but it could be interesting. You could code something that polls the Citrix downloads site, when new firmware appears, do a RestAPI call to create an upgrade job, and upgrade your firmware automatically but if you are not using ISSU, this would cause unacceptable interruptions I would think.

I got confirmation from Citrix that the only way to ensure its 'functioning properly' is if you are on an affected version that has some global deny list signatures. For example, 14.1_73.37 had signatures until .41. Once on .41, you won't show any denylist or get any hits showing as they didn't release any signatures for .41 to protect from the CVE fixed in .46. Definitely a bit frustrating to have to roll back to vulnerable code or wait for a new vulnerability (that also has a mitigation created) to confirm its functioning properly.