|
|
|
|
|
by pbhjpbhj
840 days ago
|
|
A few naive questions: I see a few comments indicating that connecting Microsoft (? not mentioned anywhere in the report??) t Terminal Services to the internet was a wholly bad idea. Aside: is the report using "Terminal Services" generically, or do they mean that the server hasn't been updated since before 2009 (? when it seems Terminal Services became Remote Desktop Services (RDS))? Is there something inherently insecure about remote desktops, or is MS software here known to be particularly insecure, or ...? RDP is default enabled on MS Windows installs (I always disable it), is that more of a problem than one might imagine? Do they say anywhere where the access was from (maybe only GCHQ know that). Presumably the firewall would only allow known connections - did they report on analysis of all the remote clients? |
|
Exposing RDP to the Internet directly has been frowned-upon because of the attack surface being presented, there's no two factor "story" out-of-the-box, and you're opened up to brute force attempts on cruddy user passwords.
Older versions of the Microsoft Remote Desktop Protocol had a much larger attack surface than current versions. The current versions with Network Level Authentication (starting in Windows Vista/Server 2008) present a smaller attacks surface. Older versions used "homegrown" Microsoft crypto, whereas current versions use TLS.
Disclosure: I made a FLOSS fail2ban-like tool for RDP many years ago[0]. I had a situation where I was forced to expose RDP to the Internet and I didn't like having it open w/o some protection against brute force attacks. This tool happens to still work in Server 2022 and will slow the velocity of brute force attacks. I still highly recommend not exposing RDP directly to the Internet anyway.
(The ts_block tool is missing some fairly essential functionality that I never got around to implementing. It works fine and is really easy to install but some things are sub-optimal.)
[0] https://github.com/EvanAnderson/ts_block