Ok, I have a challenge. A customer uses two gatewa...
# citrix-netscaler
r
Ok, I have a challenge. A customer uses two gateway vservers to permit Akamai WAF to be in front of one and the "OGR" one for direct receiver connections once authenticated etc. In December, a threat actor hit the external site for the OGR gateway, which returns a standard login portal and attempted to brute force their way in. The gateway does not have an approved login setup so it always failed, but several million login attempts is a load on the system. At that time, we added a rule that if the CitrixReceiver header was not present, drop the traffic. We can't do a rate limiting rule because there isn't a login. We can't change the login schema because their isn't a login. The header worked, until last Friday a threat actor knowing it was a NetScaler Gateway inserted the Citrix Receiver header, and tried again about ten thousand times to login. This time they spaced it out so there was not more than 3 or 4 failed attempts per minute. Tricky little sucker. Again, there is not a valid method of logging in, so they didn't get anywhere. I had thought we could change theme of the gateway page to have a blank login page or modified in some way that there was not a login username and password field on the page that was returned. I created a new theme from the RfWebUI template, modified the pages and uploaded them, and bound the theme to the gateway. When the customer attempted to view the page spoofing the header, they received the default RfWebUI theme once again. At this time I noted that the earlier attempt had not returned their modified UI, but the default one. As a test, we enabled the GreenBubble and X1 themes, and these themes did display. It appears that the OGR Gateway without a login will not accept a custom UI theme, I suspect because it does not have a login schema attached. Anyone have any ideas how to work around this? Any other ideas how to block login attempts on this page? We can't modify the traffic or send responder or rewrite policies because we cannot affect the valid receiver traffic.
j
I would add an EULA to tick with username input only first, second screen is the pwd that they will never reach. You can bind a dummy auth server that do nothing, so schema works, no?
k
what sort of requests are they hitting to the GW? I think you should be able to see that because you can run a trace
I mean that you mentioned "We can't do a rate limiting rule because there isn't a login. We can't change the login schema because their isn't a login.", but then again "The header worked, until last Friday a threat actor knowing it was a NetScaler Gateway inserted the Citrix Receiver header, and tried again about ten thousand times to login."
r
You can add a plugin to your browser like Modheader and add a header to any browser request. All they are doing is browsing the page with the “CitrixReceiver” header included (or with a hacker tool that automates the behavior). If I bind any form of auth to the page it would break the Optimal Gateway Routing (OGR) function, even a dummy one. The second gateway has no human interaction at all. It can’t because only receiver traffic uses that FQDN. Since it dies not have an authentication bound to it, even if you had valid credentials you would get “Access Denied”.
k
isn't the authentication done using an http post request... if you would block that on verb level? or does that post ever occur, sorry... a tad sllloww
j
Are there particular URLS you can drop for the authentication portion that isn't used by the gateway portion?
r
I honestly wasn’t expecting it to return a page, but for some reason it insisted. There is a “receiver” folder nested down further. It only has folders with files for “default”, “X1”, and “GreenBubble”. I’m going to add one for the new custom theme, and copy the default files over and see if that doesn’t do it.
j
If the OGR doesn't even need access to the pages, I wonder if you can deny any access to those pages. As the receiver technically would only hit the root hostname.
k
But this is definitely something worth improving with OGR. Just some tickbox in GW that would make it just a HDX routing point and disabling (possibly all) web page elements. One other thing with OGR would be support for HTML5 btw
r
We have tested a responder policy that if it contains “index.html” drop traffic. Isn’t interfering with HDX traffic so far, but I’ll let you know.
🙌 1
j
If you need me to test anything in my lab let me know. I may want to add something to my Gateway lockdown standards if this is a thing.
👍 1
r
I am on PTO until Tuesday. I’m scheduling time with the customer to try it in Dev environment when I get back. One of our other Gurus has tried it and says it’s working. Once I get it ironed out, there will probably be a blog post about it. Thanks all!
👍 2