This section includes the following topics:
Version control, the ability to save and track changes made to a security policy, is an important tool when managing firewall configurations. Security administrators need to know what was changed, when it was changed, and who did the changes.
To assist administrators with these tasks, Amaranten Firewall features a comprehensive version control system, which is an integral part of both the management system and the firewall core.
The version control system in Amaranten Firewall is designed to track virtually all changes made to a firewall. The result is that not only firewall rulesets, but entire firewall configurations are kept under strict version control.
This means that whenever a modification to a firewall configuration is done, the actual modification is recorded along with the username of the administrator performing the modification. In addition, the current date and time and an optional version comment is stored. This design allows an administrator to roll back to any given version in time, and deploy that configuration to a running firewall, knowing that it will operate in the exact same way as it did when the configuration was first created.
The version control system is built up mainly by two features; the ability to archive several configuration versions in the management database and the concept of checking out and checking in configurations in the Security Editor. This section will focus only on how to operate the version control system. For details on how the actual configuration versions are stored, please see the section Management Data Sources.
Note: The version control system is enabled from start and cannot be deactivated. The reason for this is security. All changes to a firewall configuration need to be accounted for. This means that it is important to understand the concept of version control in order to properly manage Amaranten Firewall.
Each version of a firewall configuration in the management database is associated with a version number, an index, set to 1 when the configuration is first created. Every modification of the configuration will generate a new version, and the version number gets incremented by 1. In this way, the most recent configuration version is always associated with the highest version number.
The DB cfg column of the firewall list in the Security Editor displays the highest version available for each configuration. In normal cases, the highest version in the database is the version being used by the Security Editor for configuration. There are however scenarios when this is not true. Please see Get Latest Version for more information about these scenarios.
The Core cfg column displays the version currently being used by the firewall core. If the version number is equal to the DB cfg version number, the firewall core is using the most recent configuration.
The usage of the version control system is often described as the "Check Out and Check In" concept. The term refers to the operations that an administrator performs in the Security Editor in order to work with firewall configurations. All commands related to version control are accessible from the Version Control submenu available in the Edit menu of the Security Editor. The commands are also available as toolbar commands, keyboard shortcuts and from the context sensitive menu brought up by right-clicking an object in the tree view pane of the Security Editor.
The figure below gives an overview of the ?heck Out and Check In?concept.
A configuration in the management database can be in one out of two modes, namely "checked in" and "checked out". The default mode is "checked in". An administrator accessing a configuration in "checked in" mode will find the configuration to be read-only, that is, all configuration dialogs are blocked for editing, and no modifications can be done to the configuration. Several administrators may access the same "checked in" configuration simultaneously from different management stations.
Whenever an administrator wants to start
modifying a configuration, the configuration needs to be checked out.
This is done by first selecting the actual firewall or namespace that
is target for the modification in the tree view pane of the Security Editor.
Then choose Check Out from the Version Control submenu,
or press Ctrl+O.
Small red dots in front of the icons in the tree view indicate that the firewall or namespace has been checked out. The administrator who performed the Check Out operation has now exclusive write access to the configuration. As long as the configuration is in ?hecked out?mode, all attempts to check out the configuration from another management station will fail. This prevents that two administrators accidentally modify the same configuration simultaneously.
Check Out is a recursive operation. This means that if a namespace configuration is being checked out, and the Automatic Configuration Inheritance option is enabled for that namespace, all underlying configurations will be checked out. The reason for this behavior is that a modification of the namespace configuration can affect underlying configurations inheriting the namespace.
The Security Editor will watch for name collisions. When checking out a configuration that contains name collisions, a dialog is shown where these name collisions may be resolved. For more information about name collisions, please see section Name Collisions.
In a multi-administrator scenario, good practice is that a configuration should not be in ?hecked out ?mode longer than necessary.
When all necessary changes have been made to the configuration, the administrator needs to perform a check in operation in order to commit the changes to the database. The check in operation stores a new version of the configuration in the management database and changes the mode to ?hecked in? meaning that the configuration once again is read-only.
To check in a configuration,
first select the actual firewall or namespace that should be checked in.
Then choose Check In from the Version Control submenu, or
press Ctrl+I.
The dialog box shown below will be displayed.
The Username field
contains by default the Microsoft Windows username of the logged on administrator
performing the Check In operation. The Version Comments edit box
can be used to write a short comment describing the changes made to the
configuration. Click OK to continue the Check In operation, or
Cancel to abort and leave the configuration in ?hecked out?mode.
The DB cfg column in the firewall list will now display the new version number. As the DB cfg version is now higher than the Core cfg version, the Security Editor will notify the administrator that the new configuration needs to be uploaded to the firewall. This is indicated by the text ?eeds Deployment?in the Status column of the firewall list. Please see Remote Management for more information about communication with the firewall.
Check In is a recursive operation. This means that if a namespace configuration is being checked in, and any underlying configurations is checked out, the Check In operation will cause all underlying configurations to be checked in as well.
It is possible to undo all changes made
to a configuration. First select the actual firewall or namespace, and
then choose Undo Check Out from the Version Control
submenu, or press Ctrl+U. All changes made since the latest check
out will be discarded.
An administrator can open any of the previously checked in configuration versions. When an earlier version is opened, it will automatically be checked out for editing. If the administrator modifies the opened configuration and checks it in, it will not replace the old configuration. Instead, a new version will be created and thus becomes the latest version in the management database.
To open a previously checked in configuration
version, first select the actual firewall or High Availability Cluster,
and then choose Open Specific Version... from the Version Control
submenu.
The dialog box shown below will be displayed.
This dialog lists all configuration versions checked in since the first creation of the configuration. Apart from the version number, the username, date and time and version comments are displayed for each version. Select the version to open and then click Open. The selected configuration version will now be read into the Security Editor and automatically checked out.
In normal cases, the highest version in
the database is the version being used by the Security Editor for configuration.
This is however not true when Amaranten Firewall Manager is used in a
multi-administrator scenario.
Consider two administrators, Alice and Bob. They are using the Amaranten Firewall Manager on different workstations, but connected to the same management database. The database contains, among others, a firewall named Paris. This firewall has undergone a number of configuration changes and has now, say, 42 as its highest configuration version number. The Security Editor in both Alice? and Bob? Firewall Manager correctly reports that the DB cfg version is 42.
Now, Alice decides to perform some changes on the Paris firewall. She checks out the firewall, makes the changes and checks it back in. Alice? Security Editor now reports that the DB cfg version is 43 and that a configuration deployment is needed.
Now, what has happened to the Paris configuration in Bob? Security Editor? Actually, nothing has happened. If Bob looks through the configuration of the Paris firewall, he will not be able to detect Alice? changes. This is because he will still be looking at version 42 of the configuration. But, the DB cfg column will report that version 43 is the latest version. To make Bob aware that Alice has updated the configuration, the icon of the Paris firewall will be displayed with an Information sign, and the Status column will display the text ? more recent configuration version exists in database?
Bob can now choose Get Latest Version from the Version Control submenu. The latest version available in the database will be read by the Security Editor and replace the current version.