remote desktop no vpn

[pcpete]

I noticed my tech yesterday forwarded ports and was connecting to a new 2016 server we installed without a VPN. This was done to trouble shoot something. Is this really risky if just done for a few days, assuming it does not get forgotten :-(

 

[Sky-Knight]

Few days? Try a few seconds...

RDP brute force attempts happen within SECONDS. Exposing RDP to the world without 2FA enabled is like watching the old blaster worm tear through an unpatched LAN. Machines are breached in SECONDS, not days. All it takes is one weak password on any account that has access, or a machine that isn't patched to current and SPLAT.

 

[pcpete]

Thanks. it is off now. it has been like that since last night. we changed the password, hopefully no damage was done. At this point, what things would you check?

 

[oldtech]

No offense intended but if your tech is so clueless about security issues as to open up RDP on a client AT ALL without VPN he needs to find another line of work. That server is almost guaranteed to be hosed, pwned, whatever adjective you desire from a security standpoint. If it were my client I'd nuke and pave it (drastic to be sure) and at bare minimum reset ALL passwords, Delete/disable the admin account (after setting up an alternate of course). I would do all that locally to the server with the server offnet. Then when back online start monitoring outbound connections for unknown or unverified addresses. I would also reach out to my insurance provider and make sure my liability coverage is up to snuff.

 

[Markverhyden]

Obviously that's about as stupid as stupid can get. But in reality the risk may not be that bad. If they are not serving up content out of that IP then the server won't be on places like shodan.io.

That being said if it was up for a few hours you can guarantee that the IP was port scanned even with no content being served out. But the bigger question is why? Every situation is different but that's a pretty desperate measure to take. Especially leaving it up for even a few hours.

 

[pcpete]

@Markverhyden We are obviously do not do servers often and are not fully competent in this area. He did not have any idea a server would get hacked that quickly if it was password protected. To make things worse, it was not a very complex password. We have come from a residential breakfix background. All we can do now is learn and move forward.

 

[pcpete]

Just curious, how do they brute force a password? Doesn't windows not allow constant retries without a pause to slow things down?

 

[Sky-Knight]

Just curious, how do they brute force a password? Doesn't windows not allow constant retries without a pause to slow things down?

The built in administrator accounts are immune to account lockout policies. They aren't set by default either.

As for the scanning and brute forcing itself, that's all done automatically. Bots find the open port, other bots start trying to login with common username / password pairs.

At very least, you have to use a product called RDPGuard, that will slow down brute force attempts. However, beware... this isn't 2FA... and I've had an RDP server that was exposed with RDPGuard protecting it get nailed, and crypto'd... it just took about 2 years to do it. So Now I RDPGuard, and Duo any RDP service that needs to be exposed. If the client can't handle that... VPN.

P.S. all of the above applies to SSH too. Anything you can use to remote admin a server MUST BE MFA protected. I don't care if it's your RMM, 2FA that crap! Or wind up in the news as another cautionary tale, and go out of business like an idiot should. I don't mean to be harsh here, but there have been MANY high profile MSPs nailed in the last 12 months alone. Not knowing this isn't just a case of live and learn, it's a case of never bothering to look.

 

[pcpete]

Let's say it was exposed for 17 hours with a non complex password for admin, it seems as if it is guaranteed to be compromised. Does that statement seem accurate?

 

[Sky-Knight]

Let's say it was exposed for 17 hours with a non complex password for admin, it seems as if it is guaranteed to be compromised. Does that statement seem accurate?

It's not guaranteed, but it is highly likely. You'd have to audit the security log, and see if there are any unaccounted for successful logins, or see if the security log was cleared. The latter is a dead giveaway something is up.

 

[YeOldeStonecat]

There are so many possible things that can happen....I'd even consider "If there's a small chance something could have busted in...well...now we have to take some form of action". Bottom line is "You don't know for sure"..so it's safest to assume yes.

Older and/or unpatched versions of Windows....it's not an account guessing game to keep trying usernames/passwords to get it, they simply use an exploit tool to easily bust into the OS like a hot knife through butter. Don't even have to waste time trying to log in, the tool gets run, it exploits the older/unpatched Windows..and in mere milliseconds...BOOM they're in! It used to be Server 08 non-R2 and older...to be honest, I'm not sure if 08R2 and 2012 have joined that list....I stopped paying attention because a while ago I stopped having standard terminal server and use only TSGateway.

Newer OS's....to the best of my knowledge it is a username/password attack. Can be either via standard "grinding tools"...that keep guessing standard stuff like the Administrator accounts and other standard default user accounts that many domain have....or they study the business...and get names of users...and go on from there. Once you get the name of users...can run a grinding attack based on that, or...(as is more often the case now)...compare those names against any of the tons and tons of tons of lists of breached accounts floating around out there on the underground market. Tools at their disposal make this pretty easy to do! And pretty successful since many people use the same passwords all over the place. And/or they can specifically target the end user with a phishing campaign to get their password.

Trying to get fancy and changing ports from the standard 3389 to other ports like 3391 or 4020 or whatever...pretty useless. The tools they run now to scan IPs..many will scan all the ports, it will be found, and via a fingerprinting ability of these scanning tools, know it's a RDP host and move forward with RDP attacks.

Safest thing...if you need to have a terminal server....don't expose it to the outside world. Keep it wrapped safely behind the firewall, and have end users VPN in first. OR....use TSGateway. TSGateway is a role you add to a server on the network...to proxy in RDP traffic through HTTPS/SSL (port 443 ONLY). An SSL certificate is used. It is still considered secure, I'm not aware of any exploits that existing against it. The only weak point here is....users..using passwords that are stolen and on a list of breached accounts, or having them fall to phishing.

Which is why it's more and more important to use MFA/2FA. Like Duo on it.
And..educate users...educate..educate...educate!

The only exception I have to the above, is at one client, I have not a terminal server but their main app server..port 3389 is open/forwarded on the firewall to it. BUT....BUT....the firewall has an ACL on it, limiting incoming traffic on to ONLY come from the IP of the office of the company that manages that EMR software.

 

[oldtech]

Let's say it was exposed for 17 hours with a non complex password for admin, it seems as if it is guaranteed to be compromised. Does that statement seem accurate?

Very accurate

 

[pcpete]

looking for external logins in the security log, ours from our shop was the only one. We saw only about 5 failed logins with odd user names. Weighing the pros and cons with shutting down the two vet clinics and the hard talk with the owner, do you feel we may have not been compromised? If we we found evidence of logins we would do the right thing and tell the owner and nuke and pave. I am guessing it is hard to doctor these logs, so if we are not seeing many attempts or actual logins, is it safe to assume we got lucky?

 

[pcpete]

I will say out loud, our security measures are often an after thought. We have had the home user break fix mentality for some many years where it did not harm us or our clients. Embarrassed, but it is the truth. This job started out as a small clinic who needed a little breakfix help, then over the years progressed into two clinics running off of one server (the two clinics are connected via VPN form the fiber isp). Hopefully this is an eyeopener about our sloppy practices and a chance to do things right in all cases

 

[Sky-Knight]

The problem boils down to, you don't know...

If you keep the server, you're rolling the dice. You might come up lucky, who knows. You won't know for potentially six months either, because the most common thing that happens to RDP breaches is a crypto. And they're patient enough these days to let them sit for a good long while, so your backups will be infested as well.

So, if you're ready to roll the dice, then at least get a backup going, make sure it works, and make a plan to restore the server from scratch if something happens. The old backups will be infected, so you cannot use any executable files from it, only data files.

Or... you blow the server away, start over, and know it's clean. The question is, how much is that knowledge worth to you?

 

[Markverhyden]

We saw only about 5 failed logins with odd user names.

That is what happens with attempted hacks. Example below from my email server.

2019-12-16 16:08:58 -0500 02 mail SMTP-IN:00001DAD: Authentication error for user 'cholecystitis@verhyden.org': Account not found locally

I can get hundreds every day just on my email server. If I look at my USG I get many times that. But that's the nature of the game when you provide services.

You said the password was not very complex. Brute force is a matter of pure statistics. As @Sky-Knight mentioned this stuff is all automated, with a database behind it. The black hats find an IP, launch a demon pointing to it and wait for a success notice. Part of what they do is start with the common password variants. Like password%%%%%, welcome%%%%, letmein%%%%%, techsupport%%%%, etc. And they probably start their iterations at 6 characters or so in the password brute force. Saves them a little time.

Were they all from the same IP address? Given you only had 5 in 17 hours, assuming you filtered the log file properly, then it's doubtful anyone got in. But this is risk management so it's really up to each person to determine what they are and are not comfortable with. Did you look at the users list to see if a user has been added? Run the best practices on the server to see if something shows up? The list goes on forever.

The problem is a networking issue not a server issue per se. Your edge device, router, is the gateway, literally. By default NAT acts as a firewall. Internet design does not allow traffic to pass from a public IP to a private IP range unless it's allowed at the interface. In the design there are two scenarios to allow traffic. Traffic that is initiated from the inside, say going to google.com, always allows return traffic unless there are restrictions implemented. What we are talking about, in your case @pcpete is "unsolicited traffic". Someone randomly knocking at the door. By default all devices block that unless it's specifically allowed. As in port forwarding, DMZ, etc.

In simple terms never, ever do any kind of port forwarding, DMZ, etc, etc unless you completely understand the consequences. That the ISP provides the VPN I'd talk to them about whitelisting MAC addresses if you can't do that directly on the edge device. This is a way to block black hats. If they are not providing any services to the public, like a website, it should be simple. Not perfect of course. Remember that the vast majority of breaches involve PEBKAC failures which start on the inside with unlimited outside access unless otherwise blocked.

 

[Sky-Knight]

MAC addresses don't exist past the first router... I find using them for any sort of ACL to be annoying, and extremely limited.

 

[computertechguy]

Thanks. it is off now. it has been like that since last night. we changed the password, hopefully no damage was done. At this point, what things would you check?

look for unknown users..