We now know first-hand why, say, an electric hand mixer needs a warning label advising users to switch it off before licking icing from the beaters.
We recently ran a detailed article describing the default insecurity of a Windows XP Pro box with SP2 installed, and produced a long list of Windows features, components, and services that we believe should be disabled by default.
Note that there is a crucial difference between saying that Windows should ship with X features off, and saying that, if you find X feature running, you should immediately panic and turn it off yourself. Some things need to be enabled for other things to work, and your system's dependencies will vary widely according to how you connect to the Internet, which applications you run, what you actually do with your machine, and so on.
Our point was - and remains - that it is the box's owner who should enable the needed services, features, and components, not Microsoft (or Dell, or HP, etc). And we faulted Microsoft for making this business entirely too difficult for the average user to accomplish.
Nevertheless, Reg readers have, in rather large numbers, been dutifully going through our list of questionable features and services, disabling everything in sight, and innocently sabotaging their Windows boxes.
We beg you to stop.
The article was a critique of a single, deliberately stripped-down, stand-alone test system - probably very different from yours - as well as a critique of Microsoft's enduring feature-rich efflorescence. It was NOT a practical guide to hardening a Windows system. This is why we didn't include instructions: to discourage inexperienced users from tinkering and blowing up their systems. Unfortunately, many of you did. (There is a tech manual available that provides the instructions, caveats, and background information needed to harden - that is, to simplify - a Windows or Linux system without unpleasant surprises.)
Blaming the victim
Some readers, and quite reasonably if incorrectly, faulted us for expecting users to enable services and features that they may need, but may not understand, and may have great difficulty controlling. In a sense, we were 'blaming the victim' for not knowing how to run Windows safely on the internet, and for expecting users to sort things out for themselves.
This is a very important point, but we believe that the fault lies with Windows' many confusing, and varied, GUI system configuration interfaces. If secure system configuration is currently too difficult for most users to achieve, then we believe that Microsoft should put serious effort into making it far, far easier.
We believe in particular that the Services configuration interface is far too difficult for most home users to handle (and for too many professional admins, for that matter), yet we wish that Microsoft would ship Windows with most of its networking-related services disabled. This is not as contradictory as it might appear. It should not be at all difficult to enable only the networking services and components that one needs.
For example, Microsoft could make much better use of its GUI setup 'wizards' by tying them to services and networking components.
Let's consider DNS. The setup 'wizard' could, if it were designed properly, ask whether the user 1. wants to specify the DNS servers they'll use, or 2. get DNS automatically from their ISP, or 3. have no idea what this puzzling question implies. The first option would bring users to the TCP/IP settings, where they could specify the DNS servers they wish to use. The second and third options would enable the DNS client. How hard is that?
Carry that idea forward, and you can see that Microsoft could do a great deal to ensure that only the networking components and services that one needs will be installed and enabled.
Again, for example, instead of installing and enabling file and print sharing by default, the 'wizard' could ask if the computer will be providing these services to, or demanding these services from, other machines on the local network. It could then install and enable what's needed, and no more. Installing Windows would take longer, and it would become more interactive, requiring some actual user attention and input, all right, but that's a very small price to pay for significantly enhanced security.
But instead, by default, Microsoft installs and enables almost everything that a user might need.
Nothing attracted more, or ruder, flames than our contention that the Windows DHCP and DNS clients should be disabled by default.
As usual, those commentators who were most sure of themselves were also those most mistaken. We were, however, lectured numerous times, with emphatic all caps, multiple exclamation points, and profanity, that it is "IMPOSSIBLE!!!!" to connect to the internet without the DNS and DHCP clients, "YOU FU**ING MORON!!!!"
It should surprise no one to learn that it's quite easy to connect to the internet without the Windows DHCP and DNS clients. You simply enter an IP address for the box, a subnet mask, and a gateway (e.g., your router), and choose a DNS server or two, in your TCP/IP advanced settings. It's hardly brain surgery.
But why would you want to shut them off? Surely they're not dangerous; they're clients, after all. We heard this many times.
This comes down to being proactively defensive. It is always wise to turn off any service that you don't need or intend to use - and this goes for *nix as well. We know of no current exploits against either client mentioned, but if one should be developed tomorrow, people not using these services will not be affected. We recall that everyone thought DCOM was a harmless little gimmick - until the Blaster worm struck. But people who had DCOM turned off were blithely unaware of it.
No one can say which Windows component will be attacked next with some worm; therefore, it is only prudent that you should not run any feature, component, or service that you don't need. Fewer routes to exploitation, and fewer potential routes, means more fun and less trouble for you. Period.
Our previous list of candidate services that should be shipped disabled included one very big blunder. We said that the "Remote Access Connection Manager" should be disabled. In fact, many users will need it. We meant to say that the "Remote Access AUTO Connection Manager" should be disabled. That was a careless space-out. We apologize.
Many readers faulted us for testing SP2 with Win XP Pro, and then bitching about how difficult it is for home users to configure it for decent security. Actually, we happen to know that XP Pro and XP Home are virtually identical in their dangerous feature richness, but we feel that it's only fair to test an XP Home system with SP2, just as we did with XP Pro, and compare the results. We will post our finding soon. Stay tuned. ®
Thomas C Greene is the author of Computer Security for the Home and Small Office, a comprehensive guide to system hardening, malware protection, online anonymity, encryption, and data hygiene for Windows and Linux.