The Visual Policy Editor, which is where more substantial changes are evident, maintains the traditional FireWall-1 4.x Policy Editor look and feel. I tested Next Generation (NG) in our Syracuse University Real-World Labs® and was impressed by the changes.
Once the management server is defined, installation of NG and components is simple. NG installs a base package that incorporates shared components; then the modules, such as FireWall-1 NG, VPN-1 NG and the management server, are added separately. The process of adding modules has been improved. Gone are the days of the command-line putkey application. (Putkey is still there for backward compatibility with FireWall-1 4.x firewalls and older OPSEC applications.)
NG installs an internal CA (certificate authority) for interprocess security using client-side SSL. After I added managed objects, such as firewalls and OPSEC applications, to the management server, I entered a password the module would use upon initialization. Once the module authenticates to the management server, the CA issues a digital certificate to the module and all further communication is secured via SSL. When an object is deleted from the management server, its certificate is revoked and added to the certificate-revocation list. Additionally, software updates, including the OS, and licensing updates can all be handled from the central management station.
GUI Not Just Skin Deep
Three additional views in the Visual Policy Editor provide alternative methods for accessing objects (see screen shot). All the views, except for the map view, offer drag-and-drop capabilities. The multitabbed object-tree view on the left provides easy access to objects defined in NG. The objects list below the rules base shows list objects in the tree, including comments. Ready access to comments gives administrators an easy read on the purpose of each object. The network map displays the arrangement in the NG database. Creating rules is much easier with the new features.
For experienced FireWall-1 administrators, the map may seem like eye candy, but the pictorial display helps visualize security domains. Additionally, policy rules in the rule base can be displayed on the map. I displayed the links between objects when I created a VPN policy between subnets.
Because NG, and most firewalls' GUIs, operates on objects, maintaining the object database is important. NG adds the ability to query the database for specific classes of objects by IP address or subnet. Most useful, however, is the ability to clean up the object database.
I had a number of useless objects that I cleaned out using two queries: one that looked for unused objects and another that looked for redundant objects (using the same IP addressing). Notably, when I searched for redundant objects, I came up with several. When I tried to delete an object that was used in a rule, NG warned me that the object was in use, and told me the rule and how the deletion would affect the rule, in this case leaving the "Any" object in place of the deleted object.
The search for unused objects will deliver objects that are saved in the rule base but not used in the policy, so be careful if you have saved a policy but not yet enforced it.
Better SecureClient
Major improvements have also been made to VPN-1 SecureClient NG, a more feature-rich application than Check Point's other VPN client, SecuRemote. The biggest feature in SecureClient is a centrally managed desktop firewall. Previous versions of SecureClient could be configured only to block or pass traffic to the Internet while connected to a VPN. SecureClient policies are defined and applied to users through a group mechanism instead of by user IP address, because users often come from dynamic IP addresses.
Users are added to the management server either locally or through external sources, such as RADIUS, or Microsoft Windows NT or 2000 domains. Then users are grouped according to local policy, and SecureClient rules are sent to a policy server that resides on a VPN-1 gateway. SecureClient downloads the current policy when it connects to the policy server.
NG also supports failover policy servers, so if one server is unavailable, SecureClient will continue until it connects or runs out of alternatives. SecureClient also supports centralized logging and sends logs and alerts back to a log server.
Two types of SecureClient policies are developed depending on whether SecureClient can connect to the policy server. Policies using the All Users group apply to users who are disconnected from the policy server, such as when they are behind a firewall or off network. All Users policies can deny all network traffic or allow some access, like HTTP and POP3/SMTP.
When SecureClient is connected to the policy server, it downloads and applies the policies according to the group with which the user is affiliated. For example, I created a group called Traveling and used that group when I configured a VPN between SecureClient and the protected subnet behind the VPN-1 gateway. I also configured policy statements that allowed HTTP and HTTPS access, as well as POP3 and SMTP, directly to specific POP and mail servers. Then I created a group called Server and the same VPN that was used for Traveling, but I also let the host offer HTTP access. When I logged on using different user accounts in each group, the policies were updated as expected.
If you don't want to create policies for traffic not destined for the Internet, you can create your VPN rules and add a rule allowing all access from the desktop to the Internet. That implements the more common split-tunneling policy found on other VPN clients.
The security policy is saved on the user's hard drive as a text file. I shut down SecureClient and edited the rule base using Microsoft's Notepad editor in an attempt to allow traffic that had been denied by the policy sent from the policy server. When I started up SecureClient, it told me the policy was corrupted and prompted me to download a new policy. When I said "no" to the prompt, SecureClient exited. I had to get a new policy before I could launch SecureClient.
SecureClient software installation is automated through a custom packaging tool. I created packages that silently installed SecureClient complete with a security policy. SecureClient Verification is an API that helps ensure that SecureClient desktops are properly configured. It uses customized scripts and API to check installed software on the client, and can deny SecureClient from launching if the software configuration doesn't match the policy.
Check Point has made enough improvements to make installing and maintaining its VPN and firewall much more convenient.
Mike Fratto is a senior technology editor. Send your comments on this article to him at mfratto@nwc.com.
RSS
