3Com Embeds Firewall in PC NICs

Policy Building

All EFWs are centrally managed through a 3Com-supplied plug-in to Microsoft Management Console (MMC). The Policy Server is used to develop and distribute the policies that affect the EFWs and collect and display logs as well as the status of EFWs.

Each device set is assigned one policy, but EFWs can belong to two device sets by means of a tool called a Locator. The Locator is used to enforce policies depending on whether an EFW is on a local or remote network as determined by IP address, available DNS or DHCP servers, or connectivity to the Policy Server.

The point of differentiating local and remote is that you might want to define an open policy for the local network as it is trusted and assign a restrictive policy for remote networks because they can be more hostile.

Policies are read top down and are similar to other ACL (access control list)-based rules. You can filter traffic based on source or destination IP address, TCP/UDP port pairs, and/or protocol types. But because the EFW is a packet filter, you must have separate rules for inbound and outbound traffic to allow for bidirectional traffic, including for nearly all TCP and UDP connections.To allow outbound HTTP, for example, I created a rule that permitted TCP outbound from the EFW address from source ports 1,024 through 65,535 to any destination IP address on Port 80. I defined a second rule that allowed inbound TCP from source Port 80 to the EFW IP address and any port 1,025 through 65,535. You can reuse your rule sets as needed to define common access policies. In addition, 3Com provides several predefined policies. Once you create or modify the policy, it is pushed out immediately to all connected EFWs in the device set.

Making Connections

The Policy Server and the EFWs communicate over UDP when the EFW checks in with the Policy Server or sends events. There is a problem if the EFW is behind an NAPT router. Because UDP is connectionless, many network devices, including NAPT devices, determine that the connection is no longer active if there is no UDP traffic for a designated period of time so the NAPT association is removed. The connection to the Policy Server won't be re-established until the EFW initiates it. Unfortunately, if a policy update needs to be served but there is no established connection between the EFW and the Policy Server, the EFW policy won't be updated until the connection is re-established.

3Com offers two solutions to the NAPT problem. The Policy Server will wait for the EFW to check in periodically with its heartbeat. When this happens, the Policy Server will push the new policy to the EFW using the established UDP connection. Bear in mind, though, that intervals between heartbeats can be very long--hours, days or even a week. Better yet, you can set the EFW heartbeat for device sets that represent roaming users to update every two minutes. By using a relatively fast heartbeat, chances of the UDP connection timing out are slim, and the Policy Server will be able to reach the EFW whenever a policy changes.

Regardless of the method used, the EFW always attempts to contact the Policy Server on boot-up. If it is successful, it will get the updated policy. In the event the EFW can't contact the Policy Server, it can be configured to implement a fallback policy, such as allowing or blocking all traffic or implementing the last known good policy.Pretty Features

The EFW interface provides a detailed event log that includes an administrative and policy log for management events, which can be exported as a comma-separated-value (CSV) file. The filtering is top-notch and you can build specific queries.

Another nice feature is error processing prior to saving a filter. During my tests, I built a query that would bring up events associated with a specific policy, but I forgot to make the necessary selection. When I saved the filter, a message box told me of the error. I double-clicked on the event and it opened to the proper tab. In addition, the logs can be sorted by any of the many available fields.

The EFW policies can't be modified or removed from the EFW by end users, but the EFW device can be pulled from the laptop, thus removing the firewall protection. To ensure users can't add or remove hardware, you have to make sure the onboard NIC is disabled in the BIOS and that end users are not members of the administrator group before deploying the EFW.

Mike Fratto is a senior technology editor for Network Computing. Write to him at [email protected].