Desktop Firewalls Bring Security Closer to Home

How They Work

Software-based desktop firewalls act as a kernel shim between the networking hardware device and the IP stack, which intercepts and inspects all network traffic. The traffic is compared to an ACL (access-control list) and run through signature scanners. If approved, the traffic passes through. Rejected traffic is dropped or logged to a file, and an alert is sent to the user. (Some desktop firewalls attempt to detect buffer overflows and abnormal code as well, but dedicated host intrusion-prevention systems do a better job at this. See "All-in-One Desktop Security," page 82, for more on these hybrid systems.)

Hardware desktop firewalls are specialized PCI or PCMCIA cards. They come with their own operating system via an onboard CPU and work like a standalone hardware firewall. The trade-off is they can't do application blocking or system-policy verification like software firewalls can. But unlike software ones, hardware firewalls can't be disabled from the operating system purposely or by malware.

Off-Limits to Users

Choose a desktop firewall suite that supports centralized policy management so you don't have to touch each user's machine to configure or verify a policy. And don't let users disable or set security policies on the firewalls, such as which ports are open and which programs can access the network. Internet Security Systems' RealSecure and Zone Labs' Integrity desktop firewalls make this easy for you by hiding the firewall interface from the user, with no visible user-interface components and no shutdown option. A user might disable the firewall if he or she wants to download a game, for example, but some files--like "Shoot Osama"--are Trojans masquerading as games. Disabling the firewall leaves your organization wide open to an attack.In addition, users typically can't tell the difference between legitimate programs or actions and malware: Microsoft Windows has a multitude of cryptic- sounding files in the system directory, for instance, and some that require network access. The bogus "MSNetConnect.exe" might look legit to the average user, so he may allow it with the firewall. Subtle differences in program characters can also trick users. A lower case "L" looks the same as the number "1" in Windows, for example, so a user could inadvertently run a nefarious program called IEXP10RE.EXE, which looks just like iexplore.exe when it's written in lowercase. The safest bet? Keep users out of firewall configuration altogether.The simplest and least sophisticated type of desktop firewall is the port blocker. This firewall blocks traffic based on source or destination ports and by IP address. The original Windows XP built-in firewall and open-source IPTables program are both port blockers.

When configuring a port blocker, set up a blanket block of all incoming connections. Obviously, attacks can be initiated locally or remotely, so by blocking all incoming TCP SYN connections, you lower the probability of successful remote attacks.

Remote attacks typically attempt to exploit running services, such as unpatched Web or FTP servers. You can run these services on your desktops while denying access to them from outside your network. Block incoming connections from all IP addresses except those from your own network.

In addition, you can limit the services a user can connect to by blocking destination ports. Allow only DNS and Web access, block everything but destination Ports 53 and 80. There will be exceptions for users who must run network services, such as Windows File Sharing for sharing directories, so you'll need to keep those ports open in some cases, too. This pure port-blocking approach also falls short with protocols that must open random listening ports or use a wide range of ports.

Not surprisingly, port-blocking is becoming less popular as a method of network access control. Just because you allow Port 80 doesn't mean you're allowing only Web traffic. Any protocol can run on any port. We've set up an FTP server on Port 80 in our Syracuse Real-World Labs®, for example, specifically to prove inherent limitations or defects in security products. We found that many products and protocols fall back to Port 80 to get around gateway firewalls, and port blockers can't tell when a malicious program is transmitting sensitive data.A better firewall model is application control, where you specify which applications can access the network, rather than which ports are open or blocked. If a rogue Trojan horse comes along, it won't be able to access the Internet or set up a listener port. Zone Labs' ZoneAlarm is the most famous application blocker; this functionality is also available in Sygate Secure Enterprise and InfoExpress CyberArmor.

Application control requires some administrative overhead, however. You must get a list of all programs your users require, such basic Windows OS components, Internet Explorer and Outlook, and then approve them. Some firewall products, including ZoneAlarm, initially work in a passive learning mode, during which they gather a list of all network programs used over a period of time. Be sure to approve the programs that are rarely used, too.

Another feature of application control is integrity checking. A checksum is computed for each approved executable program. If the end user's executable has a different checksum than the one specified in the policy, it's denied. This is a key tool because viruses and other attacks sometimes piggyback onto an executable, injecting their own functions and code into it. Always compute checksums against a known clean system.

Component-integrity checking, meanwhile, is an advanced feature of application control. Sygate, ZoneAlarm and InfoExpress all use it: Every DLL (Dynamic Link Library) a program accesses is recorded and verified with a checksum. When a DLL has been modified, the program is denied.The downside of integrity checking is that you must keep the checksum up to date. In addition to tracking every program needed by each user, you must maintain a list of checksums for every version out there. A simple patch could alter the checksum, which would cause it to be denied. Make sure you conduct a comprehensive and orderly change- or patch-management process to keep this manageable. If users associate patching with system breakdown, they'll stop patching their software. Use a dedicated clean test machine or environment for generating checksums before you send the software out to the entire organization.

No Pain, No Gain

Of course, not all desktops in your organization will have the same security policy. There will be exceptions for groups as well as individual users.

If your firewall suite ties into an authentication directory, such as LDAP or Active Directory, use it. This will help ensure that users who are promoted or transferred between departments are automatically updated with their new security policies.

Tiered administration support is also handy in desktop firewalls. This lets a department head handle all policy requests and updates for his or her own department or group. Beware, however, of running separate users and groups between your firewall management console and the authentication directory. They may get out of sync as new employees are hired and others are promoted, transferred or fired. Keep the lines of communication open between IT and HR to keep user access policies up to date.Desktop firewall management may not be much fun, but it's crucial to your organization's security. The more advanced security features you deploy, the harder it gets, so make sure you have a change- management process in place, and train your helpdesk to deal with common complaints and to inform users about security policies. The benefits of a host-centric security model outweigh its costs--especially as an increasing number of desktops suffer from security breaches and attacks.

Michael J. DeMaria is an associate technology editor based at Network Computing's Syracuse University's Real-World Labs®. Write to him at [email protected].

Does it make sense for users to receive security alerts from their desktop firewalls?

Consumer desktop firewalls are notorious for their pop-up warning messages. We've seen them announce that the default gateway had attempted to ping the host machine--not very useful information. This type of data is confusing to the user, plus he or she can't do much with the information, anyway.

It's best to keep the user out of the loop on blocked security attacks. Instead, provide a centralized reporting and alerting system with only security or network administrators keeping tabs on attempted attacks.A user should get information from his desktop firewall only when he's denied access to a specific application or protocol. If a user opens a program and it doesn't connect to the network, for example, he'll probably assume something's wrong with his system. Then the helpdesk gets tied up with diagnosing a problem, when it's really a firewall-rule issue. All a user needs is a message stating that the application is denied, why it was denied and how to get it approved. You may want to use a special error code in the alert that explains to the helpdesk it's an access-control violation, not a system problem. Applications that don't match checksums, however, require immediate attention because they may indicate hostile code running on the user's machine.

Make sure that alerting information is logged centrally. You don't need to log everything, just direct attacks and blocked applications. Desktops directly connected to the Internet, for instance, don't need to send reports on port scans, which are common and harmless. And unless a desktop is running Microsoft IIS or Apache, it doesn't need to send reports on attempted Web server attacks either.

But log all blocked applications. Then you can explain to users your acceptable-use policies, and keep track of possible Trojaned machines. Make sure, too, that your helpdesk has access to these reports.

Desktop firewall suites aren't just about access-control lists. These tools now come with intrusion detection, denial-of-service prevention and other security features. Network ICE (now owned by ISS) used to make an IDS that was sold as a firewall. Over time, more firewall features were added. Meantime, other firewall vendors added IDS functions to their products. Antivirus and VPN vendors are partnering as well.

These converged desktop products should save you some money and management overhead. You'll maintain just one set of users, groups and policies. They also ensure compatibility between the firewall and VPN, for instance, so you can create a set of firewall rules for users connected to the Internet, and change or relax these rules when the user initiates a VPN connection. The firewall can verify the antivirus engine is running, and if the antivirus shuts down, the firewall can block all traffic.0