Solved

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

Posted on 2014-03-10
16
4,986 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
  • 6
  • 3
  • 2
  • +4
16 Comments
 
LVL 14

Expert Comment

by:Giovanni Heward
Comment Utility
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
Comment Utility
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
Comment Utility
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
 
LVL 14

Expert Comment

by:Giovanni Heward
Comment Utility
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 14

Expert Comment

by:Giovanni Heward
Comment Utility
@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
Comment Utility
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
Comment Utility
@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
Comment Utility
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
Backup Your Microsoft Windows Server®

Backup all your Microsoft Windows Server – on-premises, in remote locations, in private and hybrid clouds. Your entire Windows Server will be backed up in one easy step with patented, block-level disk imaging. We achieve RTOs (recovery time objectives) as low as 15 seconds.

 
LVL 14

Expert Comment

by:Giovanni Heward
Comment Utility
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
Comment Utility
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 14

Expert Comment

by:Giovanni Heward
Comment Utility
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
Comment Utility
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 53

Expert Comment

by:McKnife
Comment Utility
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
Comment Utility
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 14

Expert Comment

by:Giovanni Heward
Comment Utility
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
Comment Utility
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

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Many companies are looking to get out of the datacenter business and to services like Microsoft Azure to provide Infrastructure as a Service (IaaS) solutions for legacy client server workloads, rather than continuing to make capital investments in h…
OfficeMate Freezes on login or does not load after login credentials are input.
This tutorial will give a an overview on how to deploy remote agents in Backup Exec 2012 to new servers. Click on the Backup Exec button in the upper left corner. From here, are global settings for the application such as connecting to a remote Back…
This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…

772 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now