10

I'm running Windows Server2008 R2, and seeing the following error multiple times with various IPs in the event log:

The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP xxx.xxx.xxx.xxx

I checked the IPs and they are definitely not from anyone on my team or anyone who should have access. One of the IPs was even blacklisted.

I'm assuming here that someone is trying to access my server via RDP.

Normally I would configure the firewall to only accept RDP from "allowed" IP addresses. However the issue that I face is that I dont have a static IP with my ISP, and it changes from time to time.

Is there any recommended way / solution to deal with this issue considering that I dont have a static IP at home?

AlexVPerl
  • 243
  • 2
  • 9
  • It would probably be easier to have a whitelist. Make note of your home IP and do a whois lookup to find its range or cidr. Then whitelist the ranges. Otherwise your blacklist will grow a lot over time. I block more than just RDP, so my list is 137k entries long. – cybernard Jul 19 '16 at 23:18
  • Is that possible with large ISP providers like Verizon? If so could you please forward a tutorial or explanation on how to find the range. Thanks! – AlexVPerl Jul 19 '16 at 23:37
  • Goto http://www.whois.com Then put in your IP address, and click search. The first line back is the range and the second the CIDR. In the my region the range is 192.16.0.0 - 192.16.63.255, but in your region it maybe be different – cybernard Jul 19 '16 at 23:51
  • I disagree with a whitelist, as if you need access while on a mobile network or while traveling this list would not be pre-defined – Aaron Jul 20 '16 at 13:29
  • May I ask would using a VPN be more feasible in your situation? Not answering to your question but I am trying to understand why some Administrators prefer RDP over VPN... – Davis Jul 20 '16 at 02:07
  • I think there's some confusion over RDP (https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) vs VPN (https://en.wikipedia.org/wiki/Virtual_private_network). They both serve different purposes, and can be used together. Hope this helps :) – AlexVPerl Jul 20 '16 at 02:16
  • Thanks! I was reading this article from https://community.spiceworks.com/topic/213495-rdp-vs-vpn-what-s-the-difference – Davis Jul 20 '16 at 02:24
  • 1
    @AlexVPerl just to make sure it's mentioned: you can still use RDP over VPN tunnel. Or almost any other protocols like SSH, the available protocols list depends on the actual VPN implementation used. – Ivan Kolmychek Jul 20 '16 at 14:50

6 Answers6

10

Not exactly proven security, but Port Knocking can allow you to open up closed ports by sending a special set of packets to the server first.

You could also rent out a cheap server with a dedicated IP address and set up a VPN, then explicitly set the firewall to only allow connections from the VPN IP.

Jedi
  • 3,936
  • 2
  • 24
  • 42
  • 1
    Port Knocking sounds like an interesting concept, definitely new to me, will have to do some further research. VPN is a great idea though, something that I can do quick and now, I can just pay for a VPN service that has dedicated/static IP and just restrict the firewall. Thanks for this! – AlexVPerl Jul 19 '16 at 23:59
  • I find that using a VPN only moves the burden to the VPN server, then the VPN server will bombarded just like the RDP server. – Aaron Jul 20 '16 at 13:26
  • So the question becomes how to implement port knocking. I don't see and good (current) open source port knocked implementations for windows. – Aaron Jul 20 '16 at 13:27
  • 1
    @Aaron I think the Jak meant in this answer that **you** should use the VPN when **you are connecting** to the server. This way the **you as RDP client** will have the static IP and you can whitelist it. So, you connect like `client -> encrypted link with dynamic source address -> vpn -> non-encrypted link with static source address -> server` – Ivan Kolmychek Jul 20 '16 at 14:46
  • @IvanKolmychek I wasn't thinking that way, but even then the server's VPN port can be scanned the same way that the RDP ports are being scanned. Again we are just shifting the burden from the RDP server to the VPN server (same server, different app) and RDP is considered Secure when property implemented. If your VPN has better use cases/auditing/etc. then use that, but setting up a VPN just to use RDP seems like a waste. – Aaron Jul 20 '16 at 17:45
  • 1
    A VPN most emphatically DOES NOT just shift the problem. It intrinsically provides another layer of authentication, another layer of isolation and (in most cases) is specifically designed to be highly resistant to attack. Further if you use client certificates or key pairs then its also very resistant to brute force attacks and is two factor. Confusion arises due the corruption of the term VPN as applying to anonymization proxies. I'm talking about ipsec, ssl and similar (would recommend stunnel if you can roll your own certificates, openvpn otherwise). YOU DO NOT NEED TO RENT A CHEAP SERVER. – symcbean Jul 20 '16 at 19:21
8

Most of the RDP attacks are being targeted on standard 3389 port. Changing that port to any non-standard port like 8123 will make your remote desktop service listening to it.

How-to-change-the-listening-port-for-Remote-Desktop

Once you change it, you will need to specify the port number while initiating remote desktop connection. eg. IPaddress:8123

Mitesh Gangaramani
  • 81
  • 1
  • 4
    Just to note, this is not protection.. Of any kind actually. – Pogrindis Jul 20 '16 at 13:22
  • indeed it's not a good protection against targeted attacks, however it's a useful way to avoid widespread scanning and recognize legitimate threats (more detail http://security.stackexchange.com/a/2431/37) – Rory McCune Jul 20 '16 at 14:41
  • Security through obscurity is a form of protection, just generally considered to be a very bad one. Sounds like we may be arguing a semantic issue, as I recommend against using it as well. Bad is a kind of protection. – Aaron Jul 20 '16 at 17:48
5

You may want to check out RDPGuard (Essentially fail2ban for rdp) and of course try your best to enforce a good password policy.

Nick Mckenna
  • 507
  • 2
  • 8
5

I realize that this question has already been marked as answered, but Microsoft has a service included in Server 2008 R2 called Microsoft TS (or RDP) Gateway

What this does is allow you to put another server (the Terminal Services Gateway) in front of your actual terminal server which listens on TCP 443 rather than 3389. In addition to cloaking the existence of your terminal server, the TS Gateway server adds another layer of authentication as your users can have both TS Gateway credentials as well as domain credentials.

DKNUCKLES
  • 9,247
  • 2
  • 37
  • 48
  • This sounds like an extra layer of protection. Curious as to the setup effort, will research further. Thank you for suggesting. – AlexVPerl Jul 20 '16 at 02:08
  • @AlexVPerl setup is pretty straight forward. It will require a server that faces the internet so some put it on a web server as it typically has to expose port 443 to the internet. You'll specify which of your users can use the gateway and which resources that gateway allows them to access (which I imagine would just be the terminal server in your case). In any event setup is relatively easy if you already have a server that can use the role. – DKNUCKLES Jul 20 '16 at 10:10
1

You should probably consider using the options in GPOs to restrict RDP to a specific set of known and trusted IPs.

root1657
  • 131
  • 2
  • Agreed, that would be the preferred approach, however the limitation that I had was the lack of static/dedicated IP. – AlexVPerl Jul 20 '16 at 04:14
  • You should at least be able to restrict it to inside your own networks by assigning the network address to the RDP rule. Set it to 10.10.10.0/24 and only hosts 10.10.10.1-10.10.10.254 will be able to use RDP to that host. Change the addressing for your environment, but that should help a lot. Additionally, set the permissions for WHO can RDP. By default if you turn the rule on, only admins can RDP. These 2 things together are really going to lower your attack profile. – root1657 Jul 20 '16 at 04:19
  • If you're expecting to allow employees to dial in remotely to this RDP server (I assume this is a terminal server) then I would advise against this - it will be an administrative nightmare. – DKNUCKLES Jul 20 '16 at 12:32
  • I travel and need to access a server via RDP over my mobile phone, so these ranges would never work for me. – Aaron Jul 20 '16 at 13:28
  • Ah, I was answering as if it were rdp inside the network, not as if you were doing remote access from outside the organization. My answer remains the same, however I'll add that you need to VPN into your network to gain access, and then be using the whitelist addresses and account permissions. – root1657 Jul 20 '16 at 14:58
1

I wrote a windows service a few years ago that monitors the event log for this, and firewall block IPs after a configurable number of failed attempts to authenticate over RDP. Details, download links (incl. source code) here:

http://huagati.blogspot.com/2014/02/blocking-rdp-brute-force-logon-attacks.html

KristoferA
  • 347
  • 3
  • 11
  • Similar, but in Powershell scripts: http://jonsdocs.org.uk/wiki/index.php/PSLogonFailures – Andee Jul 20 '16 at 15:50