Network Security

[compuls1v3]

Hello everyone,
I need some opinions on blocking unauthorized, external to internal, RDP connections to a network. I work for an IT company that has a firewall in place for a client. The firewall allows RDP traffic to Windows 2008 Server. Now, after checking the logs on the server, I noticed thousands of failed login attempts using unknown user names because of bad username/password. The server log gives an external IP address from different countries.

I don't know of anyway to make the hardware firewall perform an action based upon the event logs of the server. Therefore, the only 2 options I see are as follows:
1) Turn off RDP access to internal servers from the outside.
2) Setup an SSL VPN for users to access internal servers from outside the network.

Does anyone have any other thoughts on how to solve this problem?

[fashizzlepop]

I feel like there should be an allowed IPs setting for a given port. So you can whitelist trusted IPs and block all others. This may prove unwieldy for a large operation so the VPN option might be your best bet.

Although, if you're logins and passwords are strong enough, I wouldn't worry too much about brute-force attacks, especially if you lengthen the time interval between valid attempts. Personally, I use ssh key only authorization. Ie. no password based loging in. So when I see people trying to guess default passwords and usernames on my server, I just laugh.

[hellow533]

If you're a smaller corporation I'd actually put my vote towards a whitelist, or a requirement that they log in to their computer at work to use a home-based user agent and internal IP/specific mac, assuming you can access the internet without going through your server.

I'd also look in to who's doing these brute force attacks and block them one by one. Or like lidmis (or whoever is above me) said, more time between failed attempts. Another idea is if there are so many failed attempts within a small amount of time (10 failures within a minute for example) the IP is blocked, and to get it unblocked they have to talk to you personally (or whoever heads the IT department I suppose). If their IP keeps getting blocked and they have to keep switching around, they'll get bored extremely fast and forget the whole damn thing. There's no way to brute force 10 at a time, chance IPs, and continue in a well paced matter.

(edit) Sorry for just about explaining everything you two said, I guess I'm used to explaining everything like I'm talking to children.

[fashizzlepop]

The problem with whitelisting is people often don't have static IPs through their ISPs. Also, blocking the attackers one-by-one is a slow process, not to mention there will *always* be more just around the corner, unaffiliated, just trying to login.

I've seen these kind of attempts before. They aren't targeted in the sense someone is pointing all their firepower at you. Chances are they are scanning for ports and trying the basic user/pass combos.

Also, blocking IPs when dealing with botnets (most likely the origin of these attacks) is not going to be effective.

[hellow533]

^It is when you block them after only 5 or 10 tries. They won't have the >5 thousand systems needed to get past a basic brute force. You're not manually blocking them either, the system locks them out permanently until manually taken off the blacklist.

[fashizzlepop]

They aren't trying that many combos anyways. In reality, there are probably fewer than 30 login attempts by each attacker.

[hellow533]

I was under the impression somebody set up a botnet or has multiple attackers attempting to take this company out. That's why I suggested a blacklist, so if there are 5-10 failed attempts within a certain time (3 minutes perhaps?) they will be put on a black list, and will have to be manually taken off. If there is a botnet at the root of the problem, this would surely put a damper on them.

That with the extended time between attempts means attacks not only take longer, but don't cut down the server with multiple failures within a small amount of time. The base idea is spamming defenses, if it takes too long with too many individual attackers, they won't find it worth going for, and you won't have your bandwidth sliced.

[sordidarchetype]

Honestly, this is a common issue with RDP. There are many bots setup to just scan ip blocks for 3389 and try a blast of common combinations. If unsuccessful, move on.

Usually, it's not a big deal, but you are right to want to lock it down anyway.

Since you are using Windows Server 2008, has your company considered setting up a Terminal Services Gateway? (R2 and newer now call it Remote Desktop Gateway, I believe). The TSG is actually a server that offers an SSL encrypted web service to the outside world that tunnels to RDP on the private machines. This way, you can close port 3389 in the firewall altogether and just let your clients use their browsers to access RDP. It's all built into Windows Server, and it allows you to do some more friendly access filtering on the IIS level.

[hellow533]

Honestly, this is a common issue with RDP. There are many bots setup to just scan ip blocks for 3389 and try a blast of common combinations. If unsuccessful, move on.

Usually, it's not a big deal, but you are right to want to lock it down anyway.

Since you are using Windows Server 2008, has your company considered setting up a Terminal Services Gateway? (R2 and newer now call it Remote Desktop Gateway, I believe). The TSG is actually a server that offers an SSL encrypted web service to the outside world that tunnels to RDP on the private machines. This way, you can close port 3389 in the firewall altogether and just let your clients use their browsers to access RDP. It's all built into Windows Server, and it allows you to do some more friendly access filtering on the IIS level.

Yes, typically you can set up a man in the middle attack, and if successful, have full access to the network. It seems with this terminal service gateway, all information is sent directly to and from the server, and not seen by anybody else. I also noticed this however limits users, as they cannot access all internal network resources. I would also suggest OP makes sure he is on a switched media. Switching technology works by building up a large table of MAC addresses and sending traffic destined for a particular MAC through a very fast silicon chip. As a result, the packet arrives at only the intended destination and is not seen by anybody else (so they say).

Sniffing tools like tcpdump (and many others) are simply unable to do dirty work if they cannot receive packets carrying lovely, private information, which this gateway limits.

As mentioned before, the traditional countermeasure for sniffing cleartext passwords has always been to change your Ethernet-shared media to switched media. However, unhardened switches provide little to no protection in preventing sniffing attacks, so be sure to actually secure them.

"The best countermeasure for dsniff and other sniffing devices is to employ some sort of encryption for all your traffic. Use a product such as SSH to tunnel all normal traffic through an SSH system before sending out in cleartext, or use an IPSec based tunnel to perform end-to-end encryption for all your traffic."

*edit*
By the way, most of what I just said was nearly directly copied/pasted from the article on OSI Layers and network security I just submitted. Maybe more people will find a use for it than I thought.

[sordidarchetype]

I also noticed this however limits users, as they cannot access all internal network resources.

If you mean it limits resources as opposed to using something like VPN, then that becomes irrelevant. He mentioned his client was using RDP to begin with, and the TSG should over the exact same functionality as MSTSC would. Users should still be able to transfer clipboard data seamlessly, and share serial and peripheral devices to the host (I believe this all requires activex controls).

It actually has some advantages over traditional RDP. For starters, early RDP protocols (I think before 6?) were not encrypted at all and passwords could be caught plain text. If I remember correctly, TSG requires SSL.
Additionally, even with later RDP protocols, not all data is encrypted, and it may still be possible to sniff keyboard input from an RDP session.

IPSec, as you mentioned, is actually a great option if it's available. I've had clients setup with no external access to RDP, but once authenticated to the VPN they aan simply RDP directly to the private subnet. That may be a bit outside the scope of his client's needs though. I guess the original poster would need to determine that. (For example, does the client's firewall support IPSec, and is it within their budget to purchase a device that could support it, etc)