sordidarchetype wrote: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."
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.