Information security starts with knowledge of, and control over, both our software-based and human-based processes. The dangers of running unmonitored processes listening on open ports are well known. In preparing to release Windows XP Service Pack 2, Microsoft has taken the unprecedented step of admitting it might have made a mistake in forcing Windows machines to listen to the network and accept arbitrary, anonymous and unsolicited inbound communications. Go to http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx for information about the upcoming SP 2 release.
Windows XP Service Pack 2 will enable Windows Firewall (a.k.a. Internet Connection Firewall) by default so that the numerous insecure Windows processes that bind to network ports and listen for network traffic don't have to be turned off explicitly. Since the very first Windows NT and Windows for Workgroups release that exposed a listening port, Microsoft has known that default open ports are very dangerous.
Microsoft still seeks to improve security by adding features. To this end, it is adding a "white list" of processes that Windows Firewall will allow to open network ports and listen for incoming connection requests and packets. In other words, once you explicitly allow an application, it will be able to provide network services to clients or receive unsolicited inbound peer-to-peer communications in precisely the same way as if there were no firewall present. Considering that there are time-tested and proven solutions to the problem of hardening Windows services through shutting off everything that should not be running in the first place, it's not entirely clear that Windows XP SP 2 is progress.
There really is no reason for the vast majority of Windows boxes to run more than a few of the numerous default services supplied by Microsoft. One of the best resources to consult as a guide to hardening Windows processes and port bindings is the Service Configurations guides published by Black Viper. These guides can be found at the following URLs or with the help of your nearest Google cache:
http://www.blackviper.com/WinXP/servicecfg.htm
http://www.blackviper.com/WinXP/service411.htm
http://www.blackviper.com/WinXP/xpprofiles.htm
http://www.blackviper.com/WinXP/registry.htm
In addition, every Windows box should have its SMB and NetBIOS (port 445, 139, etc.) services disabled. If you want to provide file and printer sharing, you should set up a secure VPN. Be careful, though: With zero network services listening to unsolicited network traffic on your Windows boxes, you may be lulled into an unwarranted sense of security. Remember that there are still many other ways for attacks to occur with the help of the network—you can get owned without hanging your open ports out the window and asking to be attacked.
NetBIOS can be disabled with the help of the Network control panel. Just uninstall Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks for each network adapter. Then select Internet Protocol (TCP/IP) Properties, click on the Advanced button, and select the WINS tab. There you will find a radio button labeled "Disable NetBIOS over TCP/IP" and you will see that it is not selected by default. Selecting this setting will disable NetBIOS over port 445, but the only way to disable SMB entirely so that port 445 is no longer exposed as an open listening port is with the following Registry setting:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\SMBDeviceEnabled REG_DWORD (0) = disabled REG_DWORD (1) = enabled
To mitigate the obvious risks that default listening services and open ports have always exposed, Microsoft is altering the behavior of RPC and similar vulnerable network processes but not getting rid of them entirely. Under XP SP 2, RPC will, by default, not accept any communication from the network that is not authenticated. Attackers will thus have to first crack a password (such as through intercepting a LAN Manager hash of a user's credentials) or find a vulnerability in the authentication procedure before RPC commands will be processed locally.
Beginning with XP SP 2, Microsoft will be adding support for nonexecutable memory pages. This feature can be enforced in software alone with some degree of success, but it's unclear at this time whether or not Microsoft's implementation will even function unless a CPU that supports execution protection is present on the system. In this security enhancement Microsoft has found something of an ally against Java, since Just-In-Time compilation can be prevented on the grounds that it would require dynamic allocation of an executable memory block-we can already hear the Microsoft Security public relations spin: "That's not a safe thing to do."
The XP SP 2 enhancements reportedly will appear in future service packs for Windows 2000, the .NET Framework, and Windows Server 2003. Of all the additional features that Microsoft is preparing to deploy under this code name, the one that I recommend you enable immediately is "shielded mode" for the Windows Firewall. Microsoft says that this mode is for emergency situations where a Windows service has been found to be vulnerable to something specific and the patch is not yet ready to be automatically installed using Windows Update. Note to Microsoft: this is Windows we're talking about here. This is the OS for which severe vulnerabilities are always being discovered-and lately, we've seen a trend toward keeping vulnerabilities secret for months while people argue over whether or not the heap buffer overflow is exploitable, market early-access to the vulnerability proof-of-concept, and perhaps do who-knows-what with the exploit in military operations.
"Shielded mode" will prevent any open ports from being exposed on a Windows box. Client connections to TCP-mode network services (web browsing, SMTP, etc.) are the extent of network access from an XP SP 2 Windows box set in Windows Firewall Shielded Mode. This means we're getting close to having the level of security under Windows XP/2K/2K3 that we once had under Windows 3.1 with Trumpet WinSock and Netscape.
In my article "Analyzing the Mescaline Worm" August 5, 2003 (http://www.windevnet.com/documents/s=8854/win1060103399135/), the SMBDeviceEnabled Registry setting was presented along with a recommendation that we stop exposing listening ports on all network interfaces. Thousands of other people have been demanding this very same thing for years-I'll accept Microsoft's "shielded mode" Windows security enhancement as the company's official response.
Jason Coombs works as forensic analyst and expert witness in court cases involving
digital evidence. Information security and network programming are his areas
of special expertise. He can be reached at [email protected].
