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

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!
botsadminsAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
Alan HardistyConnect With a Mentor Co-OwnerCommented:
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
 
Giovanni HewardCommented:
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
 
botsadminsAuthor Commented:
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
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
Giovanni HewardCommented:
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
 
Giovanni HewardCommented:
@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
 
botsadminsAuthor Commented:
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
 
botsadminsAuthor Commented:
@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
 
Alan HardistyCo-OwnerCommented:
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
 
Giovanni HewardCommented:
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
 
tmoore1962Commented:
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
 
Giovanni HewardCommented:
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
 
Rich RumbleSecurity SamuraiCommented:
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
 
McKnifeCommented:
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
 
Rich RumbleSecurity SamuraiCommented:
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
 
Giovanni HewardCommented:
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
 
Schuyler DorseyCommented:
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
 
iistechIT ArchitectCommented:
Even though this post is very old, it still comes up at the top of some searches. While there is an accepted solution, it doesn't address the security (or lack of security) at all, as others have mentioned. Besides the obvious firewall, which doesn't matter if you are allowing RDP in, I noticed that IPsec was mentioned once. IPsec seems to really be the best solution for the question and the apparent usage, and will help if you have clients coming from an unknown IP address, though there are more complexities in the setup. IPsec will secure the traffic along the way as well as insure that only allowed clients are able to connect from the outside. It would be like whitelisting on steroids.

I know this is long past the questioner's needs, but for others that run across this, IPsec is another option to seriously look into and is easier to set up on newer Windows OS platforms.

-- Rob Ingenthron --
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.