Excellent Windows Service Minimization Guide
In my last story I originally stated "With Windows, unless I deploy a host-based firewall, it is difficult if not impossible to disable unnecessary services." I based this assessment on previous experiences where it was difficult to get a "clean" netstat output (meaning no unnecessary listening services). Getting to this point, as described by books like Securing Windows NT/2000 Servers for the Internet, was difficult and in many cases left services functionally disabled but still in netstat output.
I found an excellent guide by Hervé Schauer Consultants called Minimizing Windows Network Services that takes a step-by-step, netstat-based approach to removing Windows services. After reading the guide, I changed my original Blog entry to say "With Windows, unless I deploy a host-based firewall, it is difficult to disable all unnecessary services."
I base this statement after interpreting advice in the HSC guide. For example, the HSC guide begins by offering this caution for interpreting netstat output:
"The netstat command does not exactly report TCP and UDP ports states... for each outgoing TCP connection, an additional line will appear in netstat output, showing a TCP port in LISTENING state. It is important to make the difference between an opened TCP port and one incorrectly reported by netstat in the LISTENING state. Note: this bug has been fixed in Windows Server 2003."
The document then describes a variety of combinations of 'net' commands and registry tweaks needed to disable various services. Near the end we read this advice, which to me exemplifies what I was trying to convey regarding the complexity of Windows service removal:
"The only remaining opened port is TCP port 135. It is opened by the Remote Procedure Call (RpcSs) service and it is not possible to disable it because this service contains the COM service control manager, used by local processes.
TCP port 135 remains opened because it is used to receive remote activation requests of COM objects. A global setting exists to disable DCOM and can be set in the registry:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
Value: EnableDCOM
Type: REG_SZ
Content: "Y" (to enable) or "N" (to disable)
This registry value corresponds to the 'Enable Distributed COM on this computer' setting that appears in the dcomcnfg tool:
C:\WINDOWS>dcomcnfg
This procedure is now documented in the 825750 Microsoft knowledge base article.
Disabling DCOM is probably a good idea, as it will at least protect systems from the recent vulnerabilities affecting DCOM, discovered by the Last Stage of Delirium Research Group and by the Xfocus team.
When DCOM is disabled, the COM framework returns the E_ACCESSDENIED error code (0x80700005) when receiving remote activation requests. Thus, exploitation of the aforementionned vulnerabilities fail.
Disabling DCOM does not close TCP port 135. To close it, one solution is to remove IP-based RPC protocols sequences from the list that can be used by DCOM. In our case, the sequence ncacn_ip_tcp (transport on TCP/IP) can be removed."
Contrast this with the ease of configuring /etc/rc.conf on a BSD system! I am glad that there are ways to shut down unnecessary services on Windows systems, but I believe guides like this prove that Windows ends up being far more complicated when services need to be disabled.
I found an excellent guide by Hervé Schauer Consultants called Minimizing Windows Network Services that takes a step-by-step, netstat-based approach to removing Windows services. After reading the guide, I changed my original Blog entry to say "With Windows, unless I deploy a host-based firewall, it is difficult to disable all unnecessary services."
I base this statement after interpreting advice in the HSC guide. For example, the HSC guide begins by offering this caution for interpreting netstat output:
"The netstat command does not exactly report TCP and UDP ports states... for each outgoing TCP connection, an additional line will appear in netstat output, showing a TCP port in LISTENING state. It is important to make the difference between an opened TCP port and one incorrectly reported by netstat in the LISTENING state. Note: this bug has been fixed in Windows Server 2003."
The document then describes a variety of combinations of 'net' commands and registry tweaks needed to disable various services. Near the end we read this advice, which to me exemplifies what I was trying to convey regarding the complexity of Windows service removal:
"The only remaining opened port is TCP port 135. It is opened by the Remote Procedure Call (RpcSs) service and it is not possible to disable it because this service contains the COM service control manager, used by local processes.
TCP port 135 remains opened because it is used to receive remote activation requests of COM objects. A global setting exists to disable DCOM and can be set in the registry:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
Value: EnableDCOM
Type: REG_SZ
Content: "Y" (to enable) or "N" (to disable)
This registry value corresponds to the 'Enable Distributed COM on this computer' setting that appears in the dcomcnfg tool:
C:\WINDOWS>dcomcnfg
This procedure is now documented in the 825750 Microsoft knowledge base article.
Disabling DCOM is probably a good idea, as it will at least protect systems from the recent vulnerabilities affecting DCOM, discovered by the Last Stage of Delirium Research Group and by the Xfocus team.
When DCOM is disabled, the COM framework returns the E_ACCESSDENIED error code (0x80700005) when receiving remote activation requests. Thus, exploitation of the aforementionned vulnerabilities fail.
Disabling DCOM does not close TCP port 135. To close it, one solution is to remove IP-based RPC protocols sequences from the list that can be used by DCOM. In our case, the sequence ncacn_ip_tcp (transport on TCP/IP) can be removed."
Contrast this with the ease of configuring /etc/rc.conf on a BSD system! I am glad that there are ways to shut down unnecessary services on Windows systems, but I believe guides like this prove that Windows ends up being far more complicated when services need to be disabled.
Comments