Thanks for your most helpful article “How to setup RDS Gateway as a replacement for ‘Access Anywhere’ or 'Remote Web Workplace'”.
That is done and operational on our Windows Server Essentials 2016.
What is the best way of hiding the website that appears at https://domain/remote so that only our saved RDP files can be used to connect?
Also, as our remote access is usually from known and static IPs, I setup a rule in our Opnsense firewall that port forwards to our WSE2016 server and only allows WAN connections to 443 from known IPs. As I occasionally need remote access from an unknown IP e.g. via my Android phone and 4G, I setup another rule that forwards all IPs, but from a little used port, say 23454, to our server’s 443. I have a second RDP file on my desktop for use only when on an unknown IP, whose Advanced tab, RD Gateway Server, is set to domain:23454. Using this RDP file, I get the usual login prompt fine but a Remote Desktop Connection message “ This computer can’t verify the identity of the RD Gateway “domain:23454”. It’s not safe to connect…”
When I “View certificate” offered by that message, it does not match the domain and is not the same as the certificate used by my RD Gateway. If I use the original RDP file, whose only difference is it does not contain the port number, I connect fine from a known IP. What gives with the second RDP file using an invalid certificate and is there a work around or better way to do this?
Thank you .
This is a solution I have been looking for. Does the CVE-2020-0609 patch resolve the security issue?
Do you know if this will work with an MFA agent such as DUO?
I do not really have an answer to your question as you are trying to do something that is out of the 'normal' scope of things. I would not be that worried about Access Anywhere, RDS Gateway and security. As far as I know this is the most secure configuration for remote access.
Changing some port is security by obscurity, it does not add anything because a port scan will show what you are doing.
Spoke to early about RDP Gateway and security, see CVE-2020-0609 | Windows Remote Desktop Gateway (RD Gateway) Remote Code Execution Vulnerability
Thanks Mariëtte
Certainly a horrifying disclosure that an “unauthenticated attacker” could remotely connect and “then install programs; view, change, or delete data; or create new accounts with full user rights”. Whilst last week’s MS update may fix “how RD Gateway handles connection requests”, I doubt it addresses the more fundamental issue i.e. that the authentication we so depend upon, can be circumvented.
We all need to review our security regularly and my question is about the best ways of reducing our "sitting duck" status.
Having a quality firewall between WSE / SBS and the internet has been essential to me from day one, and I know my existing setup would have stopped the unauthenticated attacker, as they would not have been on an IP known to our firewall.
Whilst moving ports may seem a weak defence, my understanding is the attacker has to do a port scan which firewalls easily detect and block, leaving the attacker none the wiser as to what ports are open if they are outside the commonly used range. Am I wrong or is there a better way?
My testing with Nmap, since my last comment, shows that as you said, moving ports provides little defence. There must surely be more that we can do?
Brad,
You can turn off the server? Just kidding. You could have a Firewall in front of the server that does state-full inspection and can block countries or ASN but that is still no guarantee. There is no such thing as 100% secure
Reading “The Six Dumbest Ideas in Computer Security”
https://ranum.com/security/computer_security/editorials/dumb/index.html
suggests that we should be both worried and do what we can.