My recommendation to change the default listening port on an enterprisewide service is often met with criticism. My central argument is this: In most cases, an enterprise can change the default listening port, which causes no problems beyond admin education and one-time reconfiguring some scripts and tools, and it significantly diminishes the risk of weaponized attack.
Although hackers and malware can use a port scanner like Nmap to find the new port, no weaponized exploits have ever done port scanning, though they easily could. That fact alone gives you a lot of protection.
Some people call this sort of recommendation "security by obscurity," as if it were a bad thing. If you ask me, security by obscurity is one of the best defenses. Otherwise, each nation would publicize where its missiles and nuclear submarines were instead of keeping the information secret.
To me, the SQL Slammer worm is one of the best arguments for putting common services on nondefault ports. Released in 2003, it exploited nearly every possible unpatched and unprotected SQL server connected to the Internet in 10 minutes. It went off early on a Sunday morning, and by the time most admins had awakened, damage had been occurring for almost a full business day.
Basically, by the time we had wiped the crusty salt out of our eyes, it was over -- then we spent the next 48 hours (or longer) trying to clean up the mess. It was a wake-up call.
No one who had enabled SQL on a nondefault port (that is, a port besides 1433 and 1434) had to do anything -- other than calmly watching everyone else deal with their disasters. Those who switched ports didn't have to clean up a huge mess. They didn't have to rush out patches. They didn't have exploited servers. One change with minimal operational impact and they were able to avoid tons of risk.
Certainly other mitigations work just as well, such as requiring a valid VPN connection before connecting to the service, requiring a combination of prior port contacts before enabling the service, or requiring successful authentication before the service responds (this is Microsoft's Fix It solution), and anything else that might protect you against weaponized attacks.
But I can think of no other simple security solution that diminishes risk so effectively than changing the default port, when possible. If you follow this advice, move the port to a fairly high number, above 10,000 or 12,000, to avoid possible port conflicts with other existing services. Test all production equipment and update any needed firewalls or proxies. The readers who followed this advice in the past aren't in a big hurry this week.
This story, "How to defeat the new RDP exploit -- the easy way," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.