Joseph Parks Posted January 2, 2020 Share Posted January 2, 2020 Just a clarifying question....is this basically disabling the Netscaler Gateway or "Portal" as our users call it? If so, how do external users who do not have a dedicated VPN access to our network, get their apps? Reason I ask, our "Portal" url redirects with a VPN as part of the url. Won't that be denied with this policy? And does this need to be applied to all Netscalers or just DMZ netscalers hosting the Gateway? Link to comment Share on other sites More sharing options...
Rhonda Rowland1709152125 Posted January 2, 2020 Share Posted January 2, 2020 The responder policy doesn't block access to the portal page if a legitimate vpn connection is in use (as long as no reference to /../ is made). But it does prevent access to the /vpns/ directory if not an ssl vpn connection and any request to a directory browse up request ".." regardless of whether vpn client or not. The responder policy is NOT expected to block legitimate vpn users OR ICA Proxy connections using the gateway + storefront integration method (the ica proxy method doesn't usually reference the /vpns/ paths during the handoff from the gateway page to the storefront page). It is recommended to apply the fix to avoid potential exploit of the /vpns/ path via management IPs as well. Link to comment Share on other sites More sharing options...
Mark Du Plessis Posted January 8, 2020 Share Posted January 8, 2020 I've discovered on firmware 12.1.54.x (might be on other version as well) that this "fix" breaks some GUI functions. If you only use the Responder policy and do not apply the file skip_systemaccess_policyeval=0 part of the fix the GUI is not affected. If the full fix is applied, try the following: Go to any CAG ( Gateway vServer) that has STAs applied to them and try view the STAs. You should receive an error popup and then no STA servers shown. Link to comment Share on other sites More sharing options...
Joseph Parks Posted January 8, 2020 Author Share Posted January 8, 2020 I am currently on 12.1 49.x but can anyone else verify they are experiencing this issue and especially if they are on same version as myself. I was going to run this tonight. mplessi38, do you see any functional issues or just the error when trying to view STA's? Link to comment Share on other sites More sharing options...
Mark Du Plessis Posted January 8, 2020 Share Posted January 8, 2020 Only seen the STA GUI error so far, but functionally the CAG is working as expected but still early days in testing. With the full fix in place the STAs are viewable via the CLi Link to comment Share on other sites More sharing options...
Joseph Parks Posted January 8, 2020 Author Share Posted January 8, 2020 Ran the "script" on our DMZ Test Netscalers and did not experience the STA issue you mentioned above. Not sure if it is because we are a slightly older version than you or what. Link to comment Share on other sites More sharing options...
Alan Osborne Posted January 17, 2020 Share Posted January 17, 2020 FYI, testing the mitigations is easy on any up to date Windows 10 installation, just issue this command (change the host-fqdn of course): curl -I --path-as-is https://host-fqdn/vpn/../vpns/cfg/smb.conf A 403 response is what you want to see (mitigations are working), a "200 OK" is bad news Link to comment Share on other sites More sharing options...
Etienne Coppin Posted January 21, 2020 Share Posted January 21, 2020 Patching and mitigation will be probably not enough. You have to re-check and control all your appliances. In our case, we found some compromised appliance, we decide to restore instances (or re-image instances) from 1st week of december before the CVE-2019-19781 publication, implement the mitigation proposed by Citrix, revoke/renew certificates + reset of all passwords involved with NetScaler + reset of all administrative accounts with priviledges.. Recontrol everything after remediation. Read carefully these both articles for the verification steps and other recommandations https://www.poppelgaard.com/cve-2019-19781-what-you-should-know-and-how-to-fix-your-citrix-adc-access-gateway Read also this one, not so funny : https://www.fireeye.com/blog/threat-research/2020/01/vigilante-deploying-mitigation-for-citrix-netscaler-vulnerability-while-maintaining-backdoor.html Link to comment Share on other sites More sharing options...
Roger Tubbs Posted January 22, 2020 Share Posted January 22, 2020 I have question regarding the implementation on an HA pair. I apologize if I am hijacking this topic, but after running the first line of code on the primary the instructions state that the second bit of code is to be run on the secondary. When the primary reboots the secondary becomes the primary, being that it is an HA pairing. So, I the run the first bit on the primary, then I am to run the second bit on the secondary which had been the primary? I realize that I am probably overthinking this, but I had to ask. Thanks all. Link to comment Share on other sites More sharing options...
Roger Tubbs Posted January 22, 2020 Share Posted January 22, 2020 I guess what I am asking in my previous question is, should I be staying the secondary in this process? Thanks, Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now