Large-Scale Management Issues
Check Point has historically had issues with managing a large number of firewalls. Although Provider-1 (Check Point's management product geared at large enterprise and service providers) helps somewhat, there are some inherent weaknesses in how FireWall-1 does things and how well it scales. Thus far, no really good solutions to these problems exist; however, knowing about them is half the battle, which is the purpose of this section.
Security Policies
I first need to address security policies. Although a single policy can actually be enforced on numerous firewalls, several limitations affect the ability to manage security policies in general.
Number of Network Objects
The Management GUI and the fwm process on the management module do not deal with a large number of objects very well (above 10,000 or so). Having lots of memory on your management module can mitigate this, but the fewer network objects you have, the better.
Number of Rules
Although FireWall-1 can (theoretically) handle any number of rules, large security policies (over 150 rules) on the whole take an extremely long time to compile and install on the various modules. Even managing the rules themselves becomes problematic.
Number of Rulebases
The Management GUI is somewhat inefficient in that each rulebase, whether or not it is actually being used on a firewall, is downloaded to the GUI. This causes some problems within the GUI, particularly if you have a large number of rulebases or even a small number of large rulebases. Although you can adjust time outs to increase the amount of data that can be transferred, as well as enable compression in the SmartDashboard/Policy Editor application when logging in, there are inherent limitations to downloading everything to the Management GUI.
Hierarchical Management
As it stands now, anyone with read-write access to SmartDashboard/Policy Editor can change the security policy on any firewall. For large organizations with a number of sites, it is reasonable to assume there will be different needs at the different sites. The ideal structure would be to have three classes of rules in the following order:
Organization-wide rules: A global administrator would set these rules. A local site administrator would not be able to override these rules.
Site-specific additions: A local administrator could tweak these rules to his or her liking. Anything not denied in the organization-wide rules would be placed within these rules.
Organization-wide default rules: A global administrator would also set these rules. These could include rules that take effect if neither of the two previous sets of rules apply.
Some of these rule types are addressed in Provider-1, but it would be nice to see this level of granularity in the standard management product as well.
Number of Firewalls
Although there is no theoretical limit to the number of firewalls that can be managed by a single management module, there is a realistic limit. In most cases, this number is 12; however, it varies depending on the amount of logging that is taking place, the processing speed of the management module, and the network bandwidth. Many sites employ local logging on the firewalls and regular downloads of the logging information to increase the number of firewalls that can be managed. If you plan to manage more than 12 firewalls, Provider-1 may be a better choice for a management station.
Check Point has attempted to address the "number of firewalls" issue by allowing firewalls to log locally and then, at regular intervals, transfer the logs down to the management station automatically. In addition, the Large Scale Manager product allows for managing hundreds of similar gateways. Each gateway is assigned a ROBO Gateway Profile, which defines the common properties between all the gateways. This profile is defined in SmartDashboard/Policy Editor. In Large Scale Manager, you can then define the individual gateways that use this profile. Gateways that use this mechanism are referred to as ROBO Gateways.
ROBO Gateways function a little differently than other types of gateways in terms of their policy. While you can push a policy out to a specific ROBO device, a ROBO Gateway periodically fetches its security policy from the management station. This ensures the gateway is always in sync.
Each ROBO Gateway can also have a series of dynamic objects assigned to it. Within the individual ROBO Gateway definitions in Large Scale Manager, you can assign what each dynamic object means on that specific gateway.
Actual policies for the ROBO Gateways are defined in the SmartDashboard application. Each ROBO Gateway Profile can be listed as an Install-On target for rules. In addition, defined dynamic objects can also be used in the rulebase.
Number of Logs
Having a large amount of logs is not an easy problem to solve, regardless of what you use as a firewall. However, with FireWall-1, SmartView Tracker becomes a bottleneck. Some reports have suggested that more than 300,000 log entries will cause SmartView Tracker to lock up or even cause FireWall-1 to stop logging. Frequent log switches can mitigate this. Even if you could view this many log entries, would you want to? How could you analyze such large log files or even search through them to find events you are interested in?
Reliance on GUI for Management
While the SmartConsole applications are nice, many enterprise customers prefer to use a command-line interface (CLI) to configure their security devices. The main reason is that configuration via CLI can easily be scripted. When you have to create thousands of network objects and set up lots of very similar interrelationships between these objects, not to mention creating lots of very similar rules, using a GUI is very inefficient and error-prone. Imagine trying to create a thousand very similar network objects via SmartDashboard!
In FireWall-1 4.1 and earlier, Check Point provided no way to configure the firewall via a command line. In FireWall-1 NG, Check Point provides a way to do some configuration of network objects via the command line by using dbedit. The interface to dbedit is not very well documented?Check Point provides no guidance on how dbedit can be used to create or modify all types of network objects. Furthermore, dbedit does not allow you to create rules.
Check Point provides a general application programming interface (API) called Check Point Management Interface (CPMI). This provides secure access to Check Point's management server's databases. dbedit uses this interface. Applications developed using the OPSEC SDK can make use of this interface. This means if you want your own CLI into Check Point's management server's databases, you could. To my knowledge, no such applications already exist. It's also unclear whether or not CPMI allows you to modify the rulebase.
Every aspect of FireWall-1 should be controllable via an easy-to-use, well-documented CLI. That isn't to say SmartConsole applications should go away?they provide a very important function. To appeal to a wide range of customers, both an easy-to-use GUI and a well-documented CLI are extremely important.
