Thanks, EdelweissPirate. A bit harsh, but solid advice. Gonna buy a simple little router right now.
Sorry for the harshness. The main point was to be direct and abundantly clear; harshness was an unfortunate side effect.
I don’t mean to say that you can’t learn this stuff in detail—you just haven’t yet.
You’ve obviously dug into the subject in a nontrivial way, and you seem to know some important things about network security. I’m sure you could build a robust understanding of the subject pretty quickly. Please don’t be discouraged by my post!
I am not specifically a security expert, but I do work in IT, and use RDP daily along with other remote access and control methods.
I would say the key risk with RDP is: There is only one layer of challenge, which is the user authentication (local or AD) - if the attacker has valid credentials for the machine or domain, or has an exploit that can somehow circumvent that authentication, they are straight in.
With other remote access/control solutions, there is usually a necessity for the local user to grant permission for the remote user to take control. I imagine those things aren’t immune to exploit either, but they are another layer of challenge.
On a non-server OS, however, RDP access will log out the local user in order to create the session for the remote user - so if you were logged in and using the computer, it’s a reasonably sure indication that nobody was remotely logged in.
Yeah that’s exactly it.
I think CVE-2019-0708 has the effect of the latter. If that had been known a year earlier AND Windows 10 would have been affected then I could have been hacked that way.
As for the former, I actually found out later that Windows had logged an Audit Failure in the Event Log for every incoming hack connection. That is, I had almost 10,000 Audit Failures in the Event Log within a short time. The event showed the account name that failed. There were thousands of common Windows account names tried - “Administrator” in many languages, “Media”, “Accounting”, etc. and every person first name you could imagine (“Tom”, “Dick”, “Harry”, etc.etc.etc.) with every account name occurring a few times (perhaps trying a handful passwords for each).
I was somewhat relieved to note that they would have never guessed EITHER my account name OR my password (not long enough for sure, but not guessable in just a few tries) this way. It wasn’t close.
So I was lucky there. I know very well the principles of defense in depth and minimal attack surface etc. so I realize it was a major crisis that it came anywhere near this close. I look forward to completely eliminating this risk with the new separate router/firewall. (Just ordered a Ubiquiti EdgeRouter X.)
That’s all valid. But any attacker already has an exploit to circumvent RDP auth: brute force. An attacker can just hammer away with random username/password pairs until they get in. And, given enough time, they’ll succeed.
Of course, that’s true for any service that relies on usernames and passwords for access control. Unix tools like fail2ban address this by blocking IP addresses from which too many failed attempts are made.
ETA: partly ninja’d by the OP!
Here’s Steve Gibson on Security Now discussing Bluekeep (Starting at 1:34:45). He’s pretty much in agreement with all the advice given so far.
Slashdot in the past day posted a blurb with the headline “Exposed RDP Servers See 150K Brute-Force Attempts Per Week”. With some links to click on for more info.
If RDP were “safe”, there wouldn’t be so much focus on trying to crack into systems using it.
Ah, of course - the other factor is that RDP does not even throttle after failed attempts - other kinds of web-facing login services often implement an incrementing timeout after each failed attempt - effectively limiting brute force attacks.
As one of the participants in this thread who you apparently didn’t listen to the first time around, I just wanna say you’re only lucky that this new exploit didn’t hit you. Often, it’s the NEWER versions of windows (your win10 vs win7) where these exploits are found whereas the slightly older ones (say one gen back like win7) have had more exposure and more time to mature and have had patches created.
Think about it, you were not too far from losing everything. Like, everything. Here you are trying to cover all bases like a madman to somehow shield your frankly fragile windows machine (“unplug all outside networks during feature updates”? :dubious:) when everyone was giving you simple advice to use a router.
I don’t even remember what your reason was for not wanting to use a router in the first place but it can’t be a good enough reason IMO.
Thanks for the link, ftg that’s exactly the stuff I wanted to hear when I asked the OP.
In case it’s not clear, I know very well, and always knew that RDP should not be exposed on the public internet. I never knowingly exposed RDP to the internet. In fact I was always careful to specifically block RDP from the internet. (Though not in the best way.) Except just that one time last year, for a few hours, by accident. So yes, I now know from direct experience about those"Exposed RDP Servers See 150K Brute-Force Attempts Per Week", that’s all true.
arseNal I disagree with nothing in your post (well I remember the reason but other than that).
Most RDP setups are to Windows servers, usually implementing domain policies. one default policy is that an account is locked after X bad tries - usually 5 bad tries, 10 minutes locked. (Hence attempts that try maybe a few passwords then move on to a different ID). Again, the actual administrator account is immune to locking, and it’s AFAIK impossible to make it only allowed to login on the console, not remote. As others mention, standard practice (and what you find on new non-server Windows) is that the Administrator is by default disabled, like Guest.
A box router is better than using Linux or Windows as the internet-facing interface, because a full version of Windows has far too many attack points, some of which we may not know. It’s a huge and complex pile of steaming software. A router box has one job, much simpler programming, and a much smaller possibility of holes in the system. (However, do check for firmware updates from time to time…)
My problem with Windows Firewall is the opposite. Updates occasionally turn it back on, whereas managing a decent sized network you want to be able to control and manage PC’s remotely - and this will fail for some applications when the firewall goes back on. I forget how many times I’ve had “why can’t I connect to that workstation???” only to find the firewall has turned back on. Within a well-protected domain network, local firewalls are usually off by policy.
Good higher-end firewalls like WatchGuard or Sonicwall have the feature to enable authentication logins. You cannot use, say, RDP unless you login to the firewall’s web page and authenticate. you can even set this up to be a different user/password than the RDP connection, so a hacker has to find 2 sets of ID’s.
If RDP were so easy to crack, you’d see less attempts too. It’s a tribute to the fact that it is immune to (almost) everything but brute force.
Hackers try because the rewards are so high. If you can get logged onto a server in an enterprise, you would have access to a huge amount of data to move to the next step of any attack.
(getting into a system can give you amazing opportunities - download the SAM for dictionary attack on all users/passwords; enumerate all other machines on the network, any shares, can you plant malicious software in assorted other systems; enumerate all users in the domain if anonymous SID enumeration is not off; read email perhaps; etc. etc. etc. And this does not even include being able to figure out the business organization for those famous emails “Hi it’s the boss; Urgent - can you wire $200K to one of our customers?”)