After plowing through more than 200 pages of documentation about the extensive changes in Windows XP Service Pack 2 (SP2), I wasn't optimistic about testing the XP SP2 beta. With the introduction of a real firewall; security controls for Distributed COM (DCOM), remote procedure call (RPC), and WWW Distributed Authoring and Versioning (WebDAV) operations; secure wireless networking; the ability to kill pop-ups; and hands-on management of Microsoft Internet Explorer (IE) plug-ins, SP2 has more in common with a new OS than a service pack with bug fixes. The upgrade also changes the open access paradigm to limited or no access, which in theory can wreak havoc with network connectivity and server-based operations.
The monstrous 264MB download expands to consume 323MB of disk space containing 2902 files in 102 directories. You can install the service pack via all the usual methods: Double-click the self-extracting download file, expand the download file on a local or network drive, and run i386\update\update.exe; or deploy the upgrade via Group Policy and the Windows Installer package i386\update\update.msi.
With more than a little trepidation, I skipped the compatibility check and started the upgrade. Much to my surprise, the release candidate (RC) installed without errors in under 40 minutes on a generic XP Professional Edition system. My test system wasn't running Microsoft Office or any client-type applications and wasn't connected to Microsoft Exchange Server or SQL Server. After the mandatory reboot, the system prompted me to enable Automatic Updates before presenting the logon screen. Not wanting to muddy the waters, I enabled Automatic Updates, logged on, and went straight for the firewall.
The firewall in XP SP2 addresses nearly all the shortcomings I uncovered in the Windows Server 2003 original implementation. (You must be logged on as a member of the local Administrator group to configure the firewall). The number-one premise of the Windows firewall in SP2 is that it blocks all unsolicited incoming traffic—period. If you want to offer network services on an XP system, you must specifically enable the services in the firewall by checking one or more of the four preconfigured choices or by adding an application name or port number. By stopping unsolicited incoming traffic, the firewall can effectively stop the spread of most Trojan horses and worms on local networks and the Internet. When you add programs or ports to the permitted list for unsolicited incoming traffic, the firewall opens the allowed port for the time period required to satisfy the incoming request. When the operation is complete, the firewall closes the port.
Even better, you can enable firewall logging of successful and blocked connections, which lets you monitor traffic to the local system. Logging of connections isn't enabled by default, so you need to modify the settings to monitor local connections. The log file is pretty rudimentary—a simple text file with the default location of %systemroot%\pfirewall.log. To avoid cluttering the system folder with log files, you should place the firewall log file in another location.
You can access Windows Firewall via the Windows Firewall Control Panel applet; you can also right-click the network icon in the lower right corner of the screen. When you do so, you’ll see the new Change Windows Firewall settings option. Click this option to open the firewall configuration screen. The General tab controls whether the firewall is enabled—simply select the On or Off check box.
When you check Don’t allow exceptions, XP won't accept incoming connections for network services that appear on the exceptions list. This feature is handy when you suspect your machine is the target of malicious activity, as well as when you’re connected to the Internet using a public, possibly unsecure, connection. So, for example, when you’re connected to the corporate network, you might need to share databases or printers with other employees, but when you’re on the road you don’t want anyone to access these shared resources. When you check Don’t allow exceptions, XP will refuse requests to access applications and ports on the exception list, which effectively blocks access to your applications by Internet users. This mode also is useful when a Trojan or worm attempts to propagate across a network. If detected early, you might be able to prevent a machine from becoming infected by disabling access to local shared resources and services. When the threat has passed, you permit XP to accept incoming requests for applications on the Exception list by clearing the Don’t allow exceptions check box.
To permit server-based applications such as File and Print Sharing and third-party workgroup-style networking applications such as Top Producer to accept unsolicited incoming connection requests, you must add the applications or the ports they use to the Exception list. You should restrict the scope of the four choices on the Exception list, plus any other exceptions you add, to the Local Subnet only. This additional security measure ensures that locally published resources are available only to systems on the same subnet. If you need to share resources with machines not on the same subnet, you can add other subnets and unique addresses to the scope definition.
Use the Advanced tab to adjust the firewall logging options and the location of the log file (Security Logging), to enable incoming Ping requests (ICMP), and to reset the firewall to its default settings. You might need to reset the firewall if you accidentally add a rule that restricts needed incoming connections. If so, I recommend you restart the Windows Firewall service. When you reset the firewall, remember that the default mode doesn't log successful and blocked connections, so you’ll need to enable these options.
Windows Firewall also secures a system reboot against all but necessary startup DNS and DHCP traffic, protects all network connections with the same set of rules, and lets you override the rules for a specific network connection (e.g., one set of rules for wireless and another set for traditional Ethernet). The Windows Firewall on my test system operated flawlessly after the SP2 upgrade and a few modifications. I did encounter some problems with the new netsh firewall commands, but no show-stoppers in the first go round. Although it’s been only a few days, my expectations for the security portion of SP2 are much higher than when I began this exercise.
End of Article
)
)
)
Register
Jay555 July 27, 2004 (Article Rating: