This section includes the following topics:
Many of the parameters in a firewall configuration are common to several, or in some cases, all firewalls within an organization.
Service definitions are good examples of such parameters. The HTTP service, for instance, is most likely to be defined as using the TCP protocol, destination port 80, regardless of in which firewall it is used. Another example is the all-nets network definition, which is defined as network address 0.0.0.0 with a netmask of 0.0.0.0. The chance that this definition is different for different firewalls is non-existent.
An example where a parameter is shared between only some of the firewalls might be a scenario, where three firewalls are participating in a LAN-to-LAN VPN solution. The Pre-Shared Key and the IPsec proposal lists used by the VPN solution are common to all three firewalls involved. Furthermore, any firewall NOT participating in the VPN solution should of course not be aware of the Pre-Shared Key in use.
One way of managing shared parameters is of course to define them individually in each firewall configuration. Now, this method surely works, but presents an administrative nightmare. First of all, the actual operation of creating and managing all parameters will be quite time consuming. Secondly, the risk of errors is quite obvious as the administrative effort grows. Imagine updating the Pre-Shared Keys in a large VPN solution involving hundreds of firewalls!
Clavister Firewall provides a sophisticated solution to this problem
by introducing Namespaces. A namespace is basically a container where
firewalls and folders can be placed. Actually, a namespace can also contain
additional namespaces, meaning
that advanced configuration scenarios can be designed. One way of looking
at a namespace is to consider it as a possibility to group
firewalls that have some parameters in common.
In the tree view of the Security Editor, a namespace is represented as a node with an icon displaying a pair of folders in front of a globe. In the example to the right, a namespace called My_Namespace has been created. As can be seen from the example, a number of configuration sections exist in this namespace. The sections currently available in namespaces are: Hosts & Networks, Application Layer Gateways, Services, Log Receivers and VPN Settings. The final Firewall node is the folder where the firewalls (and namespaces) belonging to this namespace are placed.
All configuration items defined in a namespace can automatically be used by all the firewalls (and namespaces) defined in that namespace. This means that if we have defined a network called WebServerNet in a namespace, we can use this network definition in all the underlying firewalls. If we later need to modify that network definition, we only need to modify it in the namespace; all firewalls using the definition will automatically have their configurations updated. Naturally, the changes are never deployed to the actual firewalls without the administrator knowing it.
The concept of namespaces is of course most useful when Clavister Firewall Manager is used to manage several firewalls, for instance in larger corporate networks or in managed firewall solutions. But even in smaller installations, with only two or so firewalls to manage, namespaces will simplify day-to-day administration.
By default, there is always one namespace created in the management data source. This namespace is called the Global Namespace and is the root of all firewalls and other namespaces. The Global Namespace is used to define parameters that can be used globally, that is, by all the firewalls in the data source.
The Global Namespace contains a number of pre-defined configuration items to simplify administration. For instance, the Hosts & Networks section contains the network all-nets, defined as 0.0.0.0 with netmask 0.0.0.0. The Services section contains all common service definitions, for instance HTTP, SMTP and NetBIOS. The VPN Settings section contains default IKE and IPsec proposal lists.
Naturally, configuration items can be added or modified in the Global Namespace just like in any other namespace. However, the Global Namespace can neither be deleted nor renamed.
To create a new namespace, locate and select the Firewalls node in the namespace where the new namespace is to be created. Right-click the selected Firewalls node and choose Namespace... in the New submenu. A dialog box requesting the name of the new namespace is displayed. Enter a descriptive name and click OK to create the namespace. To abort the creation process, click Cancel.
To rename a namespace, first check out the actual namespace, then right-click the namespace and choose Properties... from the context menu. A dialog box is shown containing an edit box where the new name can be entered. Click OK to save the new name and to close the dialog box. To abort the renaming process, click Cancel. Finish by checking in the namespace.
Note: The Global Namespace cannot be renamed.
A namespace can only be removed if all underlying nodes in the Firewalls folder first have been removed. To remove an empty namespace, right-click the actual namespace, choose Delete from the context menu and answer Yes to the confirmation question.
Note: Removing a namespace is an irreversible operation. The Global Namespace can never be deleted.
The concept of namespaces is easier
to understand if explained in a context. The screen shot to the right
illustrates a sample corporation with four deployed firewalls. Three of
the firewalls, London, Paris and Rome, are used to
interconnect three offices in a VPN. The fourth firewall, Interior,
is used to protect an internal network.
The three VPN firewalls share the same VPN parameters, such as Pre-Shared keys and proposal lists. Furthermore, the networks residing behind each firewall need to be known by all three firewalls in order for the VPN tunnels to work. For this reason, the administrator of this network has chosen to create a namespace named Corporate_VPN (1). The VPN parameters have been added to the VPN Settings section (2). The network definitions that the VPN firewalls need to be aware of have been added to the Hosts & Networks section (3).
The Interior firewall is not a member of the VPN, and has thus been placed outside the Corporate_VPN namespace. The result is that the VPN parameters defined under (2) are not available for the Interior firewall to use.
All of the firewalls, however, use the same set of services for their rule-sets. For instance, HTTP is allowed between the offices (in the VPN), and it is also allowed through the Interior firewall. Therefore, all the firewalls are using the HTTP service defined in the Services section (4) in the Global Namespace.
Now, the administrator needs to modify the definition of the network residing behind the Paris firewall. This modification is performed in the Hosts & Networks section (3). As all of the VPN firewalls use this network definition for their VPN tunnels, the Security Editor will automatically update the three firewalls with this new definition. The Interior firewall, on the contrary, is not affected by the modification.
The default mode of operation is that if a configuration item is modified in a namespace, all underlying firewalls using that item will automatically have their configurations updated. This mode of operation is called Automatic configuration inheritance, and refers to the fact that configuration items are automatically inherited to underlying nodes.
In some scenarios, however,
this behavior is not the preferred way of working. First of all, when
modifying a namespace, the namespace itself and all the underlying
nodes will be locked for editing during the modification operation. In
a multi-administrator solution, this can cause unwanted resource conflicts.
(This is described in more detail in the section Configurations
and version control). Secondly, if different administrators are
responsible for the configuration of specific firewalls (for instance
in a managed firewall scenario), they probably prefer to have strict control
of all changes made to “their” firewall configurations.
To solve this problem, the Automatic configuration inheritance mode can be disabled for specific namespaces. This is done by un-checking the corresponding checkbox in the properties dialog box of the namespace. Please note that the namespace needs to be checked out before any changes can be performed in the properties dialog box.
To easier understand how this setting affects the operation, we will use the sample namespace scenario above. Imagine that we disable Automatic configuration inheritance for the Global Namespace, but leave it enabled for the Corporate_VPN namespace. The behavior of the Corporate_VPN namespace will remain unchanged, which means that a modification to, for example, the VPN Settings section (2) will instantly be reflected by the three VPN firewalls.
Modifications to the Global Namespace, on the other hand, will behave differently. First of all, when modifying a namespace with the Automatic configuration inheritance mode disabled, the operation will no longer lock all underlying nodes. Secondly, underlying firewalls will not automatically have their configurations updated.
Instead, when the underlying firewall gets checked out next time, the administrator will be notified that one or several of the configuration items that the firewall uses have been changed. The administrator can then choose whether to accept the changes or not. The section Name Collisions covers this in detail.