Hi Piviul, 1) NLA shall be used.
RDP does not have the best reputation due to the complexity of the protocol. And initially there was no authentication except the login of the remote session, i.e. whatever issues are in the implementation are exposed to an anonymous hacker. This changed with NLA which introduced mandatory authentication prior to protocol data exchange (except for the preconnection info used by Hyper-V). https://calcomsoftware.com/the-policy-expert-rds-require-user-authentication-for-remote-connections-by-using-network-level-authentication-nla/ "When using RDP with NLA disabled or not configured, remote users can access the RDP tunnel without any authentication required. This dramatically increases the chance for attackers to perform RDP based attacks, such as the wormable BlueKeep among others. Enabling NLA will block attackers lacking authentication credentials, and it is recommended specifically for BlueKeep prevention, regardless of patching actions." Obviously for some vulnerabilities patches are available in the meantime, but without NLA you are still allowing an anonymous user to consume lots of resources on your system. (https://en.wikipedia.org/wiki/Network_Level_Authentication) Takeaway: in order to protect your servers, enforce NLA (for windows easy via group policy). 2) Certificates shall be used When a TLS connection is established, two important things are done: 2.1) the identity of the server (and optionally, almost never the client) is validated/authenticated, using the servers certificate and certificates along a chain up to root certificates of trustworthy certification authorities, which are known and trusted by the client prior to connection establishment. 2.2.) encryption algorithm and key are negotiated. If you don’t support 2.1 with trusted certificates, you may end up with communicating encrypted to someone you do not know, and probably disclose your crown jewels (including credentials) to an enemy. Self-signed certificates or - depending on scenario - certificates signed by private certification authorities make 2.1 more difficult to impossible, and the last resort of any client software is to present a security warning/alert. However, one should never delegate the decision to end users. You have to train them, and the only easy rule is to cancel any security alerts. If you are an all windows organization, you can deploy certs via GPO, but which organization is windows only? Not BYOD? Takeaway: certificates protect your clients or end users. 3) 1+2 as one mechanism protects the server and the other your users, you just have to do both. Best Regards, Joachim > -----Ursprüngliche Nachricht----- > Von: Piviul <[email protected]> > Gesendet: Mittwoch, 15. April 2020 08:40 > An: [email protected] > Betreff: Re: AW: RDP to Windows Server 2019 > > Il 14/04/20 08:03, Joachim Lindenberg ha scritto: > > Hello Piviul, > > disabling NLA and ignoring certificates is definitely a bad advice from a > security point of view. If certs are wrong, it can usually be seen in guacd > logs. > ...yes Joachim you are are right, it's never a good advise to weak > security ...but if we would like to evaluate the weight of the weakeness > introduced, we are talking about ignoring that certificates sent from a > client in a LAN can't be validated from a Certification Authority > because autosigned, isn't it? In other word ignore certificate doesn't > mean don't use them to secure the connection but weak the certificate > check... or there are other weakeness I don't see in ignoring certificates? > And if we would like evaluate the weakness introduced about don't using > NLA means that credentials are validated from the client after the > connection instead of authenticate before the connection... but > credentials and all network traffic are encrypted in both cases I hope... > > There is no controversy in my question I would like only check if there > are aspects that I have no considered. > > Piviul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
