Thoughts on Windows Server 2003 SP1 RC
Microsoft announced that Windows Server 2003 Service Pack 1 Release Candidate is available for testing on non-production servers. I installed it remotely using Rdesktop on a 180 day evaluation copy of Windows Server 2003 with hotfixes installed. The whole process went smoothly, and after a reboot I was still able to connect via Rdesktop and PsExec. Microsoft published Top 10 Reasons to Install Windows Server 2003 SP1, which I found interesting reading. The majority of the reasons sound helpful. Point one is especially revealing. Microsoft now recommends "reducing the attack surface," which is code for disabling unnecessary services via the "Security Configuration Wizard" (SCW). Microsoft says "With SCW you can disable unused services easily and quickly, block unnecessary ports, modify registry values, and configure audit settings." I heartily endorse this and many other changes.
Points nine (Help secure Internet Explorer) and ten (Avoid potentially unsafe e-mail) indicate there are still problems with the way Microsoft approaches system administration. A fundamental tenet of good system administration is to avoid browsing the Web or reading external email on production servers. In some ways this has not been a problem for UNIX administrators who do not install X on their servers. They could use Lynx and Mutt in a text environment, but on servers they tend not to casually surf the Web or read email using either tool. Even if they do, there have been orders of magnitude fewer attacks against text-based Web and email clients -- and what general attacker targets such programs?
Some (such as Macintosh devotees) believe the GUI was one of the great advancements in personal computing. I agree as far as personal computing goes, but I believe the GUI should stay on the PC and away from servers. A GUI invites trouble when it wrongly empowers administrators to use powerful and potentially exploitable Web and email clients. Suddenly a user with administrator privileges can be hit by client-side attacks. The best way to avoid such a situation is to not allow Web or email clients to run on servers, not simply improve the security of such programs. I have seen Microsoft encourage users not to do so, but I do not see Windows administrators breaking this mind-set any time soon.
The GUI is an example of a feature that is not really needed to provide services to clients. What client needs a server-side GUI to offer Web pages, carry email, or serve SQL queries? If a Windows system could be installed without a GUI, we might see less successful exploitation of Windows systems. Microsoft is taking a step in the right direction by providing tools to limit the services activate on its systems. I would like to see Windows machines install no listening services by default, except for an OpenSSH-like remote administration client. Then, using a wizard, administrators could add in the services they believe they need.
It would also be helpful for Microsoft servers to offer individual services on specific ports, and not group everything under the sun on a few well-known ports. An administrator who can look at a port listing and know the meaning of seeing port X and Y, but not Z, is an empowered administrator. Individual services on specific ports simplifies network-based access control and identification of rogue services.
Comments
I'd like to chime in here with two comments that go right along with what you're saying. The first is that MS still needs to do a much better job of documentation. One of the biggest impediments to obtaining information is actually finding it. "Check TechNet" is not a sufficient answer. In many cases the documentation is available, but only after sinking significant time into searching, and very often, you finally find what you're looking for by accident.
As an example, I've been trying to find out how the Win32_Thread WMI class is populated. I've gone to MS and have yet to receive a response. Does the class actually get all of the running threads from the system (and if so, how?), or does it enumerate processes and then get the thread listing from there?
Tools...MS needs to do a better job of providing tools, or a framework. I've been working with WMI, for example, and as yet have been unable to get, say, the Win32_Process class to return the same CommandLine information as is available in tlist.exe from the MS Debugging Tools. In addition, the CommandLine property is not available in the Win32_Process class on Windows 2000, but tlist.exe can easily get this information.
These are just small examples, but I think they make my point.
H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
Thanks for your comments. The BSDs are famous for their good documentation, but they are not perfect. Often the man pages are truly "written by programmers, for programmers." A disappointing example is netgraph,, an incredibly powerful way to access networking functions. Does this make any sense, however?
"The netgraph system provides a uniform and modular system for the implementation of kernel objects which perform various networking functions. The objects, known as nodes, can be arranged into arbitrarily complicated graphs. Nodes have hooks which are used to connect two nodes together, forming the edges in the graph. Nodes communicate along the edges to process data, implement protocols, etc."
It only gets worse. I haven't found any Netgraph "how-tos" newer than about 4 years ago. Everything I know about the system is pieced together from newsgroup postings. It would be great to see a developer bring knowledge of Netgraph to the non-developer masses.
The other very interresting thing I've been looking at lately is GEOM and it's modules, but the same thing can be said about it, very little documentation available on the subject, and man pages lacking enough information to be useful.
Well, just my 2ç anyway.