Solved

What is the best way to prevent RDP brute force DOS attacks?

Posted on 2014-03-10
16
6,493 Views
Last Modified: 2014-04-02
We have a hosted server running Windows Server 2008 R2 that approximately 60 users access via RDP from approximately 8 locations. We were recently the target of a RDP brute force attack on that server, which caused major instability for our users and in most cases disconnected/blocked access to it.

After identifying the issue, we blocked the offending IP via Windows Firewall, but were attacked later that day from a different IP, which we also blocked, and have since received no further attempts.

I was, up to that point, not familiar with this sort of exploit, and have since done some homework on how to prevent such attacks, but haven't found a perfect solution for our configuration. I would like to note that the attacks were originating from any number of very high ports, and obviously being directed at 3389, which is currently not configured to block other ports from accessing it.

Would setting a rule to only allow access TO local port 3389 FROM remote port 3389 be the best solution, or would that cause some sort of malfunction I'm not taking into consideration?

Thanks!
0
Comment
Question by:botsadmins
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 3
  • 2
  • +4
16 Comments
 
LVL 15

Expert Comment

by:Giovanni Heward
ID: 39917916
Q: Would setting a rule to only allow access TO local port 3389 FROM remote port 3389 be the best solution, or would that cause some sort of malfunction I'm not taking into consideration?

A: No, the TCP/IP stack of the client will automatically select a User/Ephemeral or Dynamic/Private source port.

Microsoft Windows operating systems through XP use the range 1025 to 5000 as ephemeral ports by default.  Windows Vista, Windows 7, and Server 2008 use the IANA range by default.
Ref: http://en.wikipedia.org/wiki/Ephemeral_port

Port numbers are assigned in various ways, based on three ranges: System
Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
Ports (49152-65535); the difference uses of these ranges is described in
[RFC6335]. System Ports are assigned by IETF
process for standards-track protocols, as per [RFC6335].  User Ports
are assigned by IANA using the "IETF Review" process, the "IESG
Approval" process, or the "Expert Review" process, as per
[RFC6335].  Dynamic Ports are not assigned.
Ref: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

My suggestion would be to adopt a whitelist approach.  This involves denying all inbound IPs to 3389/TCP, with the exception of your white list (e.g. authorized source IPs and/or NetRanges).  Combined this with best security practices for RDP and you have a much strong defense.  In addition to this, I would also create a script which detects x number of invalid attempts and then updates the firewall rules to shun the IP address for a given period of time.

Consider placing all remote access services behind a VPN, in addition to the recommendations above.
0
 
LVL 76

Accepted Solution

by:
Alan Hardisty earned 500 total points
ID: 39917975
Changing the default port from 3389 on your RDS server, or a redirect on your firewall from say port 4567 to port 3389 internally would help.

Because you have the default port, hackers scan for this specifically and then attack away, but with a different port, they don't know which port you will use and thus they don't know they can attack it as easily.
0
 

Author Comment

by:botsadmins
ID: 39917988
The problem with the whitelist approach, which is what was initially thought of as prevention, is we have a number of remote users working from home whose IPs we have no control over, and that could change at any time without us knowing. Example, we have 4 home users accessing from outside the U.S., and 2 within the U.S., as well as our system admins and executives that may have need to access at any time, along with an auditing company whose IP's we do not have access to.

I would like to note the remote ports the attacks originated from were in the dynamic/private range (all above 49151), and not the typical user port range, most commonly coming from port 61297.

The scripting idea is one we have looked at, but wanted to get more outside advice on the matter.

Thanks!
0
Optimize your web performance

What's in the eBook?
- Full list of reasons for poor performance
- Ultimate measures to speed things up
- Primary web monitoring types
- KPIs you should be monitoring in order to increase your ROI

 
LVL 15

Expert Comment

by:Giovanni Heward
ID: 39917989
Changing the default port from 3389 on your RDS server, or a redirect on your firewall from say port 4567 to port 3389 internally would help.

Because you have the default port, hackers scan for this specifically and then attack away, but with a different port, they don't know which port you will use and thus they don't know they can attack it as easily.

In and of itself, this is known as security through obscurity and is not recommended.  An attacker need only scan your IP address/range for all open TCP/UDP ports: 1-65535, to ascertain which non-standard port RDP is running on.  This is accomplished by fingerprinting the responses (RDP will respond the same, regardless of the port.)

To achieve obscurity with security, you'd need to incorporate the sound suggestions above (ID: 39917916).
0
 
LVL 15

Expert Comment

by:Giovanni Heward
ID: 39917996
@botsadmins

All the more reason to move your remote access services behind a VPN.  :)

This would enforce identification, authentication, authorization, and accountability before access to remote services were permitted.

See http://www.juniper.net/us/en/products-services/security/sa-series/sa2500/
0
 

Author Comment

by:botsadmins
ID: 39918007
As it is a hosted server, we don't have a physical firewall to redirect from, which is what we do on our locally hosted servers.

And yes, changing the default port on the server itself was an option we considered, but the task of then adjusting the RDP setting for those 60+ users (who access via RDP App, which is a preconfigured icon on their individual desktops) is one we were hoping to avoid undertaking.
0
 

Author Comment

by:botsadmins
ID: 39918030
@heward

Once again, it being a hosted server, we don't have access to install a hard VPN appliance, and the POS software our users are accessing through the RDP app doesn't play well with VPN's either, according to the company that designed & installed it.
0
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 39918045
I've never had a brute force attack since changing the default RDP port, nor have any of the servers we manage and we manage plenty.
0
 
LVL 15

Expert Comment

by:Giovanni Heward
ID: 39918062
The primary issue with such approaches is the fundamental lack of sound information security principles-- namely defense in depth and least privilege.

This conversations highlights the difference between network and systems administration mindset (focused on availability) as opposed to an InfoSec professional mindset (focused on availability, integrity, confidentiality and the assurance thereof.)

At the end of the day it comes down to the priorities of the organization and managerial acceptance of risk.

Good luck to you both.
0
 
LVL 10

Expert Comment

by:tmoore1962
ID: 39918190
suggest vpn connection to your firewall then establish a RDP connection to the internal IP of the RDP server if the remote users are unable to establish connections from static IP locations that would allow a "white list" of IP's.  The problem with blocking a IP is that it is to easy for the attacker to change his originating IP thus allowing the attack to resume.  A vpn connection would resolve this as a secure VPN connection must be established before the RDP session.
0
 
LVL 15

Expert Comment

by:Giovanni Heward
ID: 39918500
I would like to note the remote ports the attacks originated from were in the dynamic/private range (all above 49151), and not the typical user port range, most commonly coming from port 61297.

Also worth pointing out, official sample Wireshark RDP captures show source ports in the User range:

RDP-002.pcap : 10446 <> 3389
RDP-003.pcap : 13178 <> 3389
RDP-004.pcap : 1311 <> 3389
etc..
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 39918523
To save you some time and effort, you can make the RDP use the Secure RDS connection. The clients (remote) have to have a pre-shared certificate before the connection can be established. It's like a VPN only it's built-in to the most recent versions of RDP
http://technet.microsoft.com/en-us/magazine/ff458357.aspx
http://technet.microsoft.com/en-us/library/cc730805.aspx
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
The clients will have to be Xp SP3 or greater, or they will have to have the latest RDP client install (XP sp3 has a compatible rdp client)
Changing the port does nothing, the banner for RDP can't be changed and is easily found using nmap etc... TSGrinder and others do not work against RDS.
-rich
0
 
LVL 55

Expert Comment

by:McKnife
ID: 39919032
Hi.

> The clients (remote) have to have a pre-shared certificate before the connection can be established
Are you sure about this, Rich? Without the certificate at the client side, the connection can be nevertheless established, as far as I can see. It won't be additionally secured, that's all. But you won't be able to keep out unwanted guests this way. Or did I get this wrong all the time? It's a process for server authentication, not client authentication.
0
 
LVL 38

Expert Comment

by:Rich Rumble
ID: 39919250
I confused RAS with RDS http://technet.microsoft.com/en-us/library/cc776411%28v=ws.10%29.aspx I've just tried TSGrinder and it's using the OS's installed client (MSTSC.exe) now, so it's no longer thwarted by enabling NLA in RDP.

Ncrack however couldn't make a connection with NLA enabled and tscrack was so old it wouldn't run :)

You can use pre-shared keys with the built-in IPSEC client, you can use an HIDS like Ossec to look for failed logins and issue a firewall block to that IP address.
IPSEC how-to but requires the clients to have the same IPSEC profiles
http://www.sans.org/reading-room/whitepapers/windows/windows-remote-desktop-heroes-villains-2026
-rich

Whitelisting IP's can be done in a variety of ways, you can have the users connect use a service like logmein, and only allow logmein IP's and maybe some others just in case.
-rich
0
 
LVL 15

Expert Comment

by:Giovanni Heward
ID: 39919643
Once again, it being a hosted server, we don't have access to install a hard VPN appliance

Bear in mind my mention of a VPN wasn't restricted to installation of additional hardware; there are software VPN solutions which could be installed on the server remotely (e.g. OpenVPN, RRAS, etc.)

---

I'm researching a solution which enables two-factor authentication for RDP, called AuthLite.  

Because it uses OATH-compliant time-based OTP tokens or YubiKeys (which emulate a keyboard) in the username field, there is no need to distribute additional client software.

The YubiKey provides AES one-time-passcodes (OTPs), which is immune to replay attacks (mitigating keystroke logging threats.)

See http://www.collectivesoftware.com/AuthLitePages/RDP

Of course this solution, in and of itself, would do nothing to mitigate a threat actors ability to attempt a brute force attack, the likelyhood of successfully breaching a 2fa account (without the token/OTP generator) would be virtually nil.
0
 
LVL 10

Expert Comment

by:Schuyler Dorsey
ID: 39925267
My two cents..

Changing the local port on RDP is hosted on is not an effective solution. That would be security through obscurity which is not a valid security approach..

Judging by your post, RDP access is opened to the public internet. If this is the case, this is where your issue is. Your terminal server should be behind a perimeter firewall; if you get a NGFW that is layer7-aware, it can help mitigate brute force attacks.

In addition, if you have users connecting from specific branches, I would setup an ACL on the firewall to only allow RDP connections from those IPs. Or, a better option, is to only allow connections to the terminal server after a VPN connection.
0

Featured Post

Does Your Cloud Backup Use Blockchain Technology?

Blockchain technology has already revolutionized finance thanks to Bitcoin. Now it's disrupting other areas, including the realm of data protection. Learn how blockchain is now being used to authenticate backup files and keep them safe from hackers.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Getting to know the threat landscape in which DDoS has evolved, and making the right choice to get ourselves geared up to defend against  DDoS attacks effectively. Get the necessary preparation works done and focus on Doing the First Things Right.
Let's recap what we learned from yesterday's Skyport Systems webinar.
This tutorial will walk an individual through the steps necessary to enable the VMware\Hyper-V licensed feature of Backup Exec 2012. In addition, how to add a VMware server and configure a backup job. The first step is to acquire the necessary licen…
This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012. Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…

632 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question