botsadmins
asked on
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!
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!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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!
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!
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).
@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/
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/
ASKER
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.
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.
ASKER
@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.
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.
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.
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.
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.
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.
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..
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
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
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.
> 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.
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
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
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.collectivesoftw
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.
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.
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.
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 --
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 --
A: No, the TCP/IP stack of the client will automatically select a User/Ephemeral or Dynamic/Private source port.
Ref: http://en.wikipedia.org/wi
Ref: http://www.iana.org/assign
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.