RDP Brute Force attacks

[Jmage]

Hi!

I don't know about you guys but this week as been the "RDP Brute Force" week for my clients. Many of them called me about their account being locked. I'm pretty sure it's the nasty Cryptolocker and his friends trying to get access inside my clients network to dump their payload.

So far, no infections. Only locked out accounts. All of them had RDP open on their server and some of them on their work computer too.

I always keep the default 3389 port closed and forward different ports like 3399, 3398 etc... Right now, I have changed the ports for some new ones and the attacks seems to have stoped. I guess only until it find my new port...

What bugs me is that all the servers have the main "administrator" accout disabled and I use another name for the admin account and a "backdoor". The first admin account gets locked but thankfully not my backdoor. How do they find the account name to brute force? I mean, they find the admin account and all my clients usernames. If I unlock a user it would get locked back in less than 1 minute.

Some of them have SBS 2011 with Exchange and OWA. Can it come from there? Should I disable OWA?

Also, what do you guys do to keep your RDP secure and don't get your accounts locked out?

I know about using a VPN but I'm not too much into letting a non-managed computer enter their network...

Thanks in advance for your wisdom.

 

[freedomit]

Funnily enough I was going to post something similar today. I look after an RDS server that has port 3391 open for RDP. We have a strong password policy on the server and make sure it fully patched but it was annoying me getting up to 5,000 login attempts from a single IP every day and our RMM sending an alert. I found some software called RDPGuard so installed a free 30 day trial, it monitors logins and adds a firewall deny rule on the server after x number of failed logins (I set it to 3). This worked great for about 25 days and was actually going to purchase the software until last night I had 4,000 attempts. I looked at RDPGuard and it was full of blocked IP's. So it looks like the hacker changed from using a single IP, getting blocked and moving on to using multiple IP's to login with. As each IP gets blocked after 3 attempts then that's over 1,000 infected computers part of the hackers botnet and attempting logins.

I honestly think the only real solution is to move to VPN & RDP or using a RDP Gateway and connecting via HTTPS.

 

[Jmage]

Thanks for your input.

I'm not really sure I want to setup VPN for RDP. I was looking at RDP Gateway too.

I tried installing EvlWatcher (Same as RDPGuard but free) at one of my clients but then I checked the logs and they doesn't provide the IP of the source of the attack. So I think I'll have to dig deeper and see where it really comes from. Just wanted some advice from fellow tech before put many hours into finding the perfect solution.

 

[freedomit]

Thanks for your input.

I'm not really sure I want to setup VPN for RDP. I was looking at RDP Gateway too.

I tried installing EvlWatcher (Same as RDPGuard but free) at one of my clients but then I checked the logs and they doesn't provide the IP of the source of the attack. So I think I'll have to dig deeper and see where it really comes from. Just wanted some advice from fellow tech before put many hours into finding the perfect solution.

Yep there are free scripts and programs that try and do the same as RDPGuard but as you found they monitor the logs for events and then try and make firewall rules from the IP, the issue is the IP isn't captured anymore with the newer OS's and version of RDP. I'm not sure ow RDPGuard works but it does work, download the 30 days trial and give it a go, it's really lightweight and simple and certain improved the security but doesn't fully solve the problem.

 

[trevm999]

RD Gateway or VPN then firewall to restrict to the RDP port

 

[TurricanII]

Most basic routers allow port knocking (where you hit one port number to open another). You could have a batch file to hit the port then rdp in.

Most vpn solutions on proper firewalls allow you to put traffic rules in so that vpn users can only target necessary ips and tcp 3389. Make sure to have a different username/pass for VPN than for rdp.

I prefer openssh so you can ssh in with a unique 2048bit key file from each machine (disable username and password/keyboard interactive login on openssh) then forward ports in. With ssh you can limit access to specified port numbers and ip addresses. I use putty as a client on Windows and the built in ssh on unx/mac. You can put putty, key file and registry export of putty settings on usb too for quick ssh into work from various locations

 

[Sn@Ke]

There's a great product for Linux servers called "fail2ban" which basically logs all IP attempts for various things such as SSH / FTP / etc etc.
I've recently started doing a lot more work on windows servers and noticed just how often they're brute forced via the security logs, so I went on a mission to find the same software and came up with this:
https://github.com/glasnt/wail2ban

It will monitor the windows security logs and once an IP has failed to login X times, it creates a temp block rule in the windows firewall for that IP much the same as fail2ban in Linux --- It's super easy to install, just download and extract to C:\scripts\wail2ban - then open up windows scheduled tasks and import the XML file, then run the .bat file once - you're done.
Worth reading the git info and giving it a go, I install it on all the windows servers I work on which have outside access to the web.

 

[YeOldeStonecat]

RDP Guard (mentioned above) is the Windows version of Fail2Ban.

We have quite a few clients with terminal servers. Most of them are running via TSGateway (port 443 only), so no port 3389 or whatever created port you want is exposed.

TSGateway is more secure.
However, most of our business clients are also behind UTM appliances. Meaning, a true good firewall, not just a plain NAT router.

This here, grinding/hacking attempts against exposed services, is one of the many reasons you should use a UTM to protect business networks, not just some plain NAT router which in essence is just a dumb 1x way firewall.

Based on whatever UTM product you use, you have things like attack blockers, intrusion detection systems and intrusion prevention systems, tons and tons of traffic analyses and reports, geo-blocking features, reports being sent to an admin. And an IT person that actually reads those reports, takes precautionary measure in the firewall, keeps the firewall updated, etc.

That's....part of the security system (or at least SHOULD be). Strongly...strongly recommending those services should be part of what we do as the IT consultant for the client. Not just allowing them to do moves that put them at risk cuz we're not able to put on the IT consultant hat for the client and do our job.

I've mentioned in the past that port forwarding port 3389 is safe as long as you keep the host updates, account policies complex, lockout rules applied for a set period of time. But we also have most of our clients behind Untangle. And to be honest....I cannot remember the last time I've had an account lockout that I had to undo....in the past year or more. Yes it's happened, but that added measure of security of the lockout policy is good for the once every few years you have to unlock an account. But the amount of times I've had to unlock an account in the past ...quite a few years....I think I can count on one hand.

And I credit that to having a UTM at the edge protecting it and doing its thing!

I don't do port 3389 on a DC. I don't do port 3389 on SBS, never port 80 either. Only....443 for RWW and OWA and prior versions the one for Sharepoint...what was it, 4125 or something. Never port 80, never port 3389 on a DC.

And yes over the past year or more...grinding attacks have really taken off, I can attest to that from logs of the IDS module of Untangle....and especially in the past few months after the geo blocking was added, and I put a widget in the dashboard for the blocked traffic of the firewall from the geo rule.

It's also baffling how so much legit traffic originating from the client needs to go outside our country. Geo blocking needs to be constantly monitored to allow legit stuff. Case in point...a recent deployment of O365...downloading MS Office from the portal, would not work until I allowed the Netherlands (NL). I saw the traffic trying to go there..made me go "WTF...really?" And a few days ago, had to download drivers for some Kyocera..had to briefly allow Singapore to allow that. So Geo blocking requires constant maintenance and occasional door opening, but it can also cut down grinding attacks against the outside by >75%.

 

[Vyper28]

Do people not typically block RDP connections from all but a white-listed IP anymore?

I had RDP access on 3389-3399 for all my servers, but our edge device is always configured to reject RDP connection attempts unless it's from my office IP. (Or one of the other static IP's we assign, like my home IP, or my VPS' IP).

 

[GTP]

Based on whatever UTM product you use, you have things like attack blockers, intrusion detection systems and intrusion prevention systems, tons and tons of traffic analyses and reports, geo-blocking features, reports being sent to an admin. And an IT person that actually reads those reports, takes precautionary measure in the firewall, keeps the firewall updated, etc.

I get daily reports from my UTM.
It astounds me how many "attempts" there are.

 

[YeOldeStonecat]

Do people not typically block RDP connections from all but a white-listed IP anymore?.

For businesses, that can be difficult. Remote/home workers...typically home connections are on dynamic accounts. Or "road warriors"..working from various places on the road, public wifi, hot spots, hotels, whatever.

 

[Vyper28]

For businesses, that can be difficult. Remote/home workers...typically home connections are on dynamic accounts. Or "road warriors"..working from various places on the road, public wifi, hot spots, hotels, whatever.

Is RDP really that common for this? For end-users we typically go the VPN route for remote work.. We have a couple remote gateway setups but I think 95% are VPN only.

 

[trevm999]

Is RDP really that common for this? For end-users we typically go the VPN route for remote work.. We have a couple remote gateway setups but I think 95% are VPN only.

Yes, it typically offers a better user experience, less chance of data corruption, and the applications they need to use are probably on the RD server anyway.

 

[TurricanII]

I don't want to start an argument I would never leave RDP open without limiting access to certain IP addresses.

I've opened it for a period of a couple of days in one particular case, but now I put in SSH, RDP over https or SSL VPN all of which can work over a single TCP port such as 443 for the reasons mentioned above by @YeOldeStonecat (traditional VPN been blocked from various offices and free Wi-Fi locations)

 

[YeOldeStonecat]

Is RDP really that common for this? For end-users we typically go the VPN route for remote work.. We have a couple remote gateway setups but I think 95% are VPN only.

From what we see out there in the real world...yes 3389 and similar is open all over the place. We take on new clients that have had it exposed, or tons of alternate ports lined up like ducks going to different rigs internally. Alternate ports don't matter much the scanning bots sniff a wide range and lock in and start the grind. Hackers ain't dumb..they've known for a long time people do alternate ports and have adjusted accordingly.

If admins aren't going to put complext passwords and lockout policies and proper firewalls and tightened up firewall rules in place, yeah VPN is a good approach, keeps it rather hand free. But it also adds a clunkiness for end users, sometimes it doesn't always work (like when they're traveling, and guesting on some poorly setup double NAT'd network. Or VPN clients break and need uninstall/reinstall. VPN has its overhead of issues too.

 

[trevm999]

I prefer openssh so you can ssh in with a unique 2048bit key file from each machine (disable username and password/keyboard interactive login on openssh) then forward ports in. With ssh you can limit access to specified port numbers and ip addresses. I use putty as a client on Windows and the built in ssh on unx/mac. You can put putty, key file and registry export of putty settings on usb too for quick ssh into work from various locations

This is pretty neat, I never knew you could do RDP over SSH (or any port forwarding).

 

[TurricanII]

This is pretty neat, I never knew you could do RDP over SSH (or any port forwarding).

Yup. Sounds like you know, but for everyone's benefit: Ideally SSH server would be on the DMZ but you can edit the authorized_keys file for each person and disable their ability to access the console on the SSH server plus restrict which IP/TCP ports they can create a tunnel to. You can create a key for each device or USB stick and append a comment to each line of the authorized_keys file on the server, e.g. BobsLaptop so you know which SSH key to disable when Bob leaves or loses his machine. Plus OpenSSH logs successful/failed logins with source IP in Windows Event Log so you can watch them with RMM or other SEIM/event log monitors.

 

[fencepost]

I'm not sure I buy that "most basic routers allow port knocking" because I'm pretty sure they don't unless it's a basic router running something like OpenWRT instead of the stock firmware.

That said, on ones that do turning on port knocking can be a viable option - we've done that and it basically eliminated the grinding that we were seeing. Prior to that we'd been blocking IPs after several repeated failed attempts, but the attackers just bumped up the delay between connection attempts which pretty much makes it useless. There are so many bot machines out there these days that counting on attacks coming from a single location is pointless.

 

[Vyper28]

I'm not sure I buy that "most basic routers allow port knocking" because I'm pretty sure they don't unless it's a basic router running something like OpenWRT instead of the stock firmware.

That said, on ones that do turning on port knocking can be a viable option - we've done that and it basically eliminated the grinding that we were seeing. Prior to that we'd been blocking IPs after several repeated failed attempts, but the attackers just bumped up the delay between connection attempts which pretty much makes it useless. There are so many bot machines out there these days that counting on attacks coming from a single location is pointless.

I think he's getting at basic business grade equipment, we ARE talking about clients with server's here. If they have a server behind an OpenWRT box, I think a sysadmin somewhere along the lines didn't do their job.

From what we see out there in the real world...yes 3389 and similar is open all over the place. We take on new clients that have had it exposed, or tons of alternate ports lined up like ducks going to different rigs internally. Alternate ports don't matter much the scanning bots sniff a wide range and lock in and start the grind. Hackers ain't dumb..they've known for a long time people do alternate ports and have adjusted accordingly.

If admins aren't going to put complext passwords and lockout policies and proper firewalls and tightened up firewall rules in place, yeah VPN is a good approach, keeps it rather hand free. But it also adds a clunkiness for end users, sometimes it doesn't always work (like when they're traveling, and guesting on some poorly setup double NAT'd network. Or VPN clients break and need uninstall/reinstall. VPN has its overhead of issues too.

I agree that port numbers don't really matter, but I still think leaving 3389 exposed just seems too risky these days. RDGateway would mitigate much of the risk, but it's not without faults of its own. At the very least, without internal DNS names, the attacker couldn't do anything to your network even if they did brute force through.

What about RDP over VPN? I haven't had many issues with VPN's since I started rolling out Sophos UTM's, but our sonicwall clients used to have interruptions frequently enough.

 

[fencepost]

I think he's getting at basic business grade equipment, we ARE talking about clients with server's here. If they have a server behind an OpenWRT box, I think a sysadmin somewhere along the lines didn't do their job.

Maybe I just didn't know where to look, but I don't recall ever seeing anything obviously in that category on Sonicwall routers I've looked at (and a couple quick searches didn't turn up anything on it either). I haven't looked at any of the Cisco small business stuff recently, but if it's still based on the same core that they got from Linksys with the RVxxx routers then I'd be surprised if it was in there either and I'd classify both of those as "basic business grade."

I'd expect better from UTM, but that steps beyond "basic."