More New ICF Features

 
 
By Larry Seltzer  |  Posted 2003-12-18 Print this article Print
 
 
 
 
 
 
 


..."> SP2s Internet Connection Firewall will include a new lockdown feature, tentatively called "Shielded Mode," which blocks all unsolicited inbound traffic. In other words, you could get the data for a Web page in response to an HTTP request, but no incoming HTTP requests would be allowed. Turning something like this on clearly will stop some programs from running, but its meant for times when you suspect there have been compromises on the network and you need to deal with them, not as a normal mode of operation. There will be a new ICF Permissions List to which an administrator may add a trusted application. When an application on this list needs to open a port, ICF will open it automatically.
In earlier versions, apps had to call APIs to open the ports. When the application closes, Windows closes the port, relieving the application of the need to do so. Using the Permissions list means that the application need not be run in a security context sufficient to open a port, i.e. with the administrator. The application can run with relatively-low privileges.
If a computer is joined to a domain, you can set up more than one ICF profile for it, with different sets of restrictions. The settings for when youre inside the domain might be more permissive, on the assumption that the network is protected; and when youre not on the domain, such as when youre on the road dialing into the Internet, the policy could be more restrictive. Incidentally, the standard ICF is IPv4 only; Microsofts IPv6 stack comes with an ICF of its own in the Windows XP Advanced Networking Pack. That ICF was always on by default. At boot time, prior to SP2, there is a gap between when the network has started and when ICF begins effective filtering, which creates a window of vulnerability. SP2 adds a new feature called boot-time policy to perform filtering from the earliest points. The system can still perform DNS and DHCP queries and communicate with a domain controller, but other operations are restricted. If ICF is disabled, so is boot-time policy, but it cannot be configured. Why, you might ask, didnt Microsoft do all this to begin with? The reason is that turning on a stateful inspection firewall causes some applications to break, and thats something Microsoft has always worked hard to avoid. In the document, Microsoft is pretty open with the fact that there will be application problems in the default configuration of SP2. This means that there will be problems with Windows that didnt occur in the past. The world has changed. At the same time, some folks might say that the world changed long ago where it comes to security, and Microsoft didnt change fast enough. Theyd have a fair point. Version 1 of ICF was little more than an item on a feature chart for Windows. Sure, they had the firewall in there because security is important and Microsoft needed to give everyone with Windows some way to protect themselves. But they couldnt bring themselves to go into the deep end of security and make the tough decisions that will put a real barrier against attacks, which at the same time would also increase the security burden on Microsoft. Lets hope Microsoft will take up that burden by helping customers to work within restricted environments and not to toss protections aside when they become inconvenient. Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. More from Larry Seltzer


 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel