Last Patch Tuesday, Microsoft released Security Update MS12-020 to close two recently discovered flaws in Microsoft's implementation of RDP (Remote Desktop Protocol). One of them Microsoft labels as "critical" because it could allow hackers to obtain LocalSystem control on a Windows box with RDP enabled.
As you've probably heard by now, this is a high-risk situation -- one that could result in an epidemic as serious as that caused by Code Red, Melissa, or SQL Slammer. Patch or remediate now!
[ The story of the RDP exploit and its patch just keeps getting more convoluted. | Download InfoWorld's Malware Deep Dive Report by security expert Roger Grimes. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
Microsoft will help you do both. You can either install the patch or run an online Fix It script to mitigate the problem until the patch is applied. The script enables Network Level Authentication, which requires authentication before a remote system can connect.
But I have other advice. As I've been recommending for more than a decade, administrators should consider running Internet-connectable services on nondefault ports if possible. In this particular case, RDP should be run on some other port than port 3389.
This advice extends to other areas. Admin websites should not be run on port 80 or even 443. SSH shouldn't be listening on port 22. Telnet hosts shouldn't be listening on port 23. The only widespread common service I haven't been able to get reliably working on a nondefault port is FTP: It uses ports 21 and 22 (in passive mode), and even its active mode (where you can indicate other ports) doesn't work well through firewalls.
In RDP's case, you can change the default port by following this guidance. When you change the default port, though, you have to indicate the nondefault port in the connection string (for example, mstsc.exe 192.168.1.12:50045).
