Implementing a Security Policy | Check Point NG[s]AI

Now that you have a written Information Security Policy and a Perimeter Security Policy, you can begin configuring and deploying Check Point NG AI by translating your organization s written security policies into a technical policy that can be enforced by Check Point NG AI.

Default and Initial Policies

The default and initial policies taken together comprise boot security for FW-1 NG AI. Unlike previous version of FW-1, FW-1 NG automatically applies the default policy upon restart. The default policy is intended to protect the firewall and the networks behind it by blocking all traffic while it is loading the firewall services. Additionally, boot security will disable IP forwarding to keep the operating system (OS) from routing traffic while the firewall is booting. However, there are some things that the default filter will allow. You can view the default filter by viewing the $FWDIR/conf/defaultfilter.pf file. Specifically , the default filter will allow the following:

Outgoing communication from the firewall itself,
Incoming communications that are a response to communications initiated by the firewall.
Broadcasts.

Because the firewall is allowing something, the firewall also enforces anti-spoofing measures to ensure that the allowed FW-1 NG AI communications are not spoofed on any of its interfaces.

As FW-1 NG AI boots up and the default filter takes effect, the interfaces are configured and the FW-1 services are started. At this point, FW-1 applies an initial policy made up of implicit rules. The purpose of the initial policy is to add rules that will allow a graphical user interface (GUI) to be trusted and connect to the firewall. After the GUI is able to connect to the firewall, a new security policy can be installed. The initial policy is only installed on a module after cpconfig is executed and there is no security policy. The initial policy is replaced after a regular policy is written and installed by the administrator to the module. Thereafter, the enterprise Security Policy will follow the default filter and interface configuration. The enterprise Security Policy will be composed of the defined rule base and implicit rules. This process is illustrated in Figure 4.2.

Figure 4.2: Boot Security

Boot security ensures that at no time is the firewall left unprotected . Ensuring that FW-1 starts at boot will allow boot security to be enforced. It is possible to alter boot security and enable IP forwarding and disable the default filter. However, this is not recommended.

After the default policy is loaded, the firewall will attempt to fetch the policy from the management station or, in the case that it cannot load the policy from the management station, load the locally cached policy. In the event that this is a new installation and no policy has been pushed to it, the Initial Policy will be installed. The initial policies are defined in the $FWDIR/conf directory named initial_management.pf and initial_module.pf depending on whether the firewall is installed with or without a management station, respectively. There is no policy for systems that are only management stations , due to the fact that there is no firewall configured for the host. Each policy includes the following communications with the aforementioned default filter applied appended afterwards:

GUI client connections to the management station (from addresses in the $ FWDIR/conf/gui- clients .def file)
HTTPS and Secure Shell (SSH) connections (if the system has any addresses in the $FWDIR/lib/webgui-clients.def file defined)
CPD_Amon, FWD, CPD, and FW_ICA_Push from the management station to the firewall
You can view the policy which is currently being enforced by typing fw stat at the command line.

Translating Your Policy into Rules

At this point you can take your written policy and your network map and start translating your documented security policy into a policy that Check Point FW-1 NG AI can enforce. Remember that the FW-1 NG AI policy is composed of global properties, which are implicit, as shown in Figure 4.3, and an explicit rule base.

Figure 4.3: Global Properties Implied Rules

The first thing you have to do is create a new policy. To create a new policy, choose from the File menu in SmartDashboard and select New .

As shown if Figure 4.4, you have a few options in the new policy dialog window. First, type a name for the policy. Now select Security and Address Translation as your Policy Type. By default, you will be presented with a simplified mode security policy. If you wish to utilize Traditional Mode or be given the option, select your preference in the Global Properties.

Figure 4.4: New Security Policy Dialog

Defining A Firewall Object

The first step in translating the policy into an enforceable policy is to define the relevant network objects. The first object you will create is your firewall object. The firewall object must be defined before you can install your FW-1 Security Policy. The setup process has been streamlined in NG AI to allow for the automatic creation of network objects known to the firewall. This requires that the appropriate routing is configured on the firewall.

If you have initially installed the FW-1 module and management server on the same box, then the firewall object will be created and partially configured. If the components are installed in a distributed environment, however, you will have to create the firewall workstation object. You start by logging into your management server via the SmartDashboard GUI. If you have not opened the Workstation Properties as shown in Figure 4.5, you may do so by selecting the firewall object from the Objects List, right-clicking, and choosing Edit by double-clicking the firewall object from the Objects List, or by going through the Manage Network Objects menu. You will need to create one firewall object for each firewall module that will be enforcing a security policy and that will be managed by this management server.

Figure 4.5: Workstation Properties with Check Point Products Installed

If you are creating the firewall object for the first time, you can right-click on the Network Objects in the Objects Tree and choose Check Point Gateway from the New menu. After selecting Classic Mode to configure the gateway, the first field you will be challenged with is the name of the firewall. This field should be the firewall module s TCP/IP host name. For better performance, it is recommended that DNS be configured to resolve this name to the firewall s external IP address, or better yet, have it set up in the host s file on the firewall and management module. By defining this in a hosts file, it removes the reliance on DNS functioning.

The next field should contain the external IP address of the firewall. If DNS is configured and you click Get address . DNS will be queried and the address will be filled in for you. Otherwise, you can just type in the value. In the Comment field, be as descriptive as possible. Using comments is a good way to document what you are doing so that others can understand more quickly and easily. The next decision is what color to give the object. This should be based on a scheme that will help you to read the rules and logs more easily.

Now select the version as NG with Application Intelligence . This will enable the appropriate next list of product modules. From the list, choose the modules that are installed on this host. If the management server and firewall module are on different hosts, you will need to configure Secure Internal Communication (SIC) to establish communication between these two machines. To do so, click on the Communication button and enter a shared password. If this object was created for you, Check Point already knows which products you have installed and has made the selection for you. Double-check that the selection is correct before you continue. The second branch on the Workstation Properties is the Topology window. This enables you to define the networks reachable behind the internal and external interfaces that exist on your firewall object. Figure 4.6 illustrates this configuration window.

Figure 4.6: Topology Window

To define the interface, make sure that you have selected the right one. After selecting an interface to define, as shown in Figure 4.6, click Edit . This will open up the dialog box, as shown in Figure 4.7.

If you are configuring an interface manually, it is important to use the proper name. For example, the name as displayed by the ifconfig -a Unix command. Failure to properly define the interfaces may cause features such as anti-spoofing to not function, and may leave the network open to attack. The easiest way to define the interfaces is to use the Get Interfaces feature, which will query the system (encrypted via SIC) for its interface information and is the recommended method of gathering this information. To make your job even easier, the Get Interfaces with Topology option will also fill out your anti-spoofing definitions as well as create the necessary network, host, and group objects. This is dependent on your firewall having the correct host and network routes pre-defined, so make sure that they are configured before you get to this point.

When defining the interfaces manually, you are not only able to specify this interface as internal or external, but you can also specify the range of addresses that reside behind the interface for enforcing anti-spoofing and generating NAT rules. This is done while manually adding or editing interface information from the topology tab, as illustrated in Figure 4.7.

Figure 4.7: Topology Definition

If the interface is internal, it is very important to define the addresses that reside behind the interface. The first option, Not Defined , generally should not be used unless the interface is present in the system but not connected to any network. If selected, anti-spoofing will be disabled on this interface. Generally speaking, it only makes sense to have anti-spoofing configured either for all or none of the interfaces. If you select the second option, these addresses will be calculated based on the address and subnet mask for this interface. Lastly, you can specify an explicit range of addresses or groups of networks. Anti-spoof tracking can also be defined on a per-interface basis. Anti-spoofing will stop someone from creating packets which, by address, seem to come from one network, though they are actually coming from another. A full discussion of address spoofing is available in Appendix B.

The Logs and Masters branch is important for your FW-1 configuration. The Logs and Masters window enables you to specify logging options. The options are broken down into three sections: Additional Logging, Masters, and Log Servers. This branch is covered in more detail in Chapter 8.

The Advanced window allows the configuration of Simple Network Management Protocol (SNMP) settings. If you expand out the Advanced branch, you will see five submenus as follows :

SMTP
Security Account Manager (SAM)
Connection Persistence
Permissions to Install
SYNDefender

A new GUI option in Check Point NG AI is the Connection Persistence option. This defines how Check Point NG AI will treat existing connections when a new policy is installed. These options are displayed in Figure 4.8.

Figure 4.8: Connection Persistence Options

The three options have three discrete functionalities:

Rematch connections , the default, is the safest selection. After a connection has been accepted, the connection is entered into the connections state table on the firewall. Upon a new policy installation, previously accepted connections are marked as old . When a packet matching an old connection is received, it is matched against the security policy and, if it matches a connection that is allowed in the rule base, the state of the connection is changed back to its previous state and communications continues.
Keep all connections represent a different stance to the question of how to deal with previously accepted connections. It does not mark any as old and allows any connections that were allowed to continue communicating.
Keep data connections allows an administrator to have functionalities of the other two options. With Keep data connections all control connections will be rematched to the rule base, but data connections will function in the same way as Keep all connections operates.

The SMTP page enables you to set local options on how the SMTP security server handles mail. Typically, the defaults on this page are appropriate, although you may have to define the postmaster name. These values are stored in the firewall s $FWDIR/conf/smtp.conf configuration file.

The Permissions to Install page is a new addition as well. You can create groups of administrators and allow certain groups to install polices on certain firewalls. This functionality used to only be available with a large enterprise and managed service provider product Check Point produces called Provider-1.

On the SAM page, you will not need to modify anything unless your SAM server is external to your management server. In most cases, you will skip this section. Changing these values will affect the firewall s $FWDIR/conf/fwopsec.conf configuration file. SYNDefender options are discussed in more detail in Chapter 13, along with SmartDefense.

Define Rule Base

Now let s use the Perimeter Network Security Policy to create a Check Point FW-1 NG AI enforceable policy. The first step is to map things out and identify the objects that will compose the rule base. Below is the relevant excerpt from the policy.

TCP/IP suite of protocols allowed through the firewall from the inside LAN to the public Internet is as follows:
- HTTP to anywhere
- HTTPS to anywhere
TCP/IP suite of protocols allowed through the firewall from the inside LAN to the service net is as follows:
- HTTP to Web server
- SMTP to Mail server
- POP3 to Mail server
- DNS to DNS server
TCP/IP suite of protocols allowed through the firewall from the service net to the public Internet is as follows:
- DNS from DNS server to anywhere
TCP/IP suite of protocols allowed through the firewall from the public Internet to the LAN is as follows:
- None
TCP/IP suite of protocols allowed through the firewall from the public Internet with specific source, destination, and protocols is as follows:
- SMTP to Mail server
- HTTP to Web server
- FTP to FTP server

Reading through your policy, it refers to the LAN, the Internet, and a service net. These are all network objects that will need to be defined before you can continue. Next, traffic is flowing anywhere, to the Web server, the mail server, the DNS server, and through the firewall. These three servers on the service net will be defined as hosts or workstations. Now that you know what objects are needed, you can create them.

Note

For simplicity purposes, when creating this rule base disregard the cluster of firewalls shown in the diagram at the beginning of this book as well as the servers and networks (172.17.1.x and 172.17.2.x) attached to them. To reiterate, the service net is the 172.16.0. x network attached to the ExternalFW firewall.

Now that you have all of the objects defined, it is time to create the rule base. For your first rule, it is best to create the Cleanup rule. By default, anything that is not explicitly permitted is dropped. This is called the Implicit Drop Rule. Anything not matching the rule base will be dropped and not logged.

However, it would be smart to log those events, and the only way to accomplish that is to define an explicit drop rule in the policy and enable tracking. For your first rule, select Add rule from the Rules menu in the SmartDashboard. This is your first rule, so bottom or top does not matter, although eventually this rule will be the last rule in the policy. From the rule that appears, confirm the following: source Any , destination Any , VPN Any , service Any , action Drop , and track Log. The only thing you will need to change is the track cell from none to Log , and add a comment in the Comment field of Cleanup Rule. At this point, your rule base should consist of one rule and look like the example in Figure 4.9.

Figure 4.9: The Cleanup Rule

Another good rule to have in your rule base is the Stealth Rule. This rule is defined to protect the firewall and alert you of traffic that is directed to the firewall itself. This time, create the rule from the Rules menu by clicking Add rule and selecting Above . You can also achieve this by right-clicking on the rule number and selecting Add Rule Above . From the newly created rule, change the destination field by right-clicking and selecting Add from the context menu. From within the Add dialog, select your firewall object. Next, in the Track field select Alert . This rule should read Any , Firewall , Any , Drop , and Alert , as illustrated in Figure 4.10. Add the comment Stealth Rule in the Comment field.

Figure 4.10: The Stealth Rule

At this point, you may be wondering how you will be able to communicate with the firewall after this policy is installed. This communication is enabled through the implied rules in Global Properties FireWall-1 Accept VPN-1 & FireWall-1 control connections , discussed in Chapter 3.

Now you have the beginnings of a good rule base. Let s start adding some rules that are based on your policy.

The first element in the security policy states that you allow HTTP and HTTPS to anywhere. Because your policy does not call for any user authentication, you can leave your Stealth Rule at the top. Place this next rule beneath the Stealth Rule. Click on the icon in the toolbar that represents Add Rule below Current . Your current rule will always be the rule that is highlighted in white, instead of being gray like all the other rules. You should see a new rule sandwiched between your two previous rules. There are many ways to create this rule. However, the best way is to select LAN (172.16.3.x) as the Source. For the Destination, select the Service_Net . Under the service field, add HTTP, then HTTPS , and finally FTP . Make sure you select accept in the Action field. The Track field will be changed to Log for this rule. Now right-click on the Destination Service_Net and choose Negate . A red X should now appear on the service net object in your rule base. What you have done is created a rule that allows LAN users the use of HTTP and HTTPS to everywhere except the service net. The reason you had to do this is because the policy does not allow HTTPS from the LAN to the service net, as you will see in the next couple of rules. In the Comment field, write in Permits LAN access to HTTP, FTP, and HTTPS on the Internet .

Second, you must define what is allowed to the Service_Net from the LAN. In these rules, you will allow the LAN access to the mail server for POP3 and Internet Message Access Protocol (IMAP), and the DNS server for DNS queries. Start creating the next rule by right clicking on the number 2 from the previous rule and choosing Add Rule below . Just like the previous rule, the Source is the LAN; however, the Destination is now the Email_Server . In the Services field, add POP3 and IMAP and select accept in the Action field. As far as the Track field is concerned , there are no requirements to log this traffic, and it might make the logs pretty large, but for debugging and forensical purposes, choose Log . If the logging is too much, it can easily be turned back to None . In the Comments field, write in Permits LAN access to retrieve e-mail via POP3 and IMAP . Since the next rule will probably generate a lot of traffic (DNS queries), place it just below your stealth rule. So, add a new rule below rule one, and enter LAN in the Source field, DNS_Server in the Destination, domain-UDP as the Service, and accept in the Action field. Again, you may not want to log this traffic because domain queries can be quite numerous , but it is a good practice and will help during the implementation when debugging problems. Enter Permit LAN access to DNS server for DNS name resolving in the Comment field.

Next, let s create a rule that allows your DNS server in the service net to perform queries to the Internet for domain name resolution. Add this rule beneath the rule you just finished. Set the rule to read Source- DNS_Server , Destination- LAN (Negate), Service- DNS , Action- accept , Track- None, and Comment, Permits DNS server access to Internet for domain name resolving.

For your final rules, what will you allow in from the Internet? According to the policy you will allow SMTP to the mail server, and HTTP and FTP to the Web server. Create a new rule beneath the current rule. Rule number 4 should be defined as Source- Any , Destination- Email_Server , Service- SMTP , Action- accept , Track- Log, and Comment, Permit anyone to send e-mail to the e-mail server via SMTP. Notice that this rule also permits your LAN users to connect to the mail server for SMTP. This will not only allow users on the Internet to send mail via SMTP to the mail server, but also users on the LAN. Rule number 5 should be defined as Source- Any , Destination- Web_Server , Service- HTTP , Action- accept , Track- Log, and Comment, Permit anyone access to Web pages via HTTP on the Web server. This rule also allows access for your LAN. Add one more rule below 5, and define it as Source- LAN (negated), Destination- Web_Server , Service- FTP , Action- Accept , Track- Log , and Comment, Permit anyone on the Internet access to FTP on the Web server. Since your policy does not allow your LAN to connect to the FTP server for FTP, you had to negate it in the source.

Now you are pretty much done. Your rule base will have nine rules and should look like the FW-1 rule base shown in Figure 4.11. You should do a File Save or click on the floppy disk icon to save your finished policy.

Figure 4.11: Rule Base from Security Policy

With these rules, the ordering is critical. Keep in mind that the firewall matches packets on the first three columns (Source, Destination, and Service) by using top-down processing. Each packet starts at the top rule and moves down until a rule matches. When a packet is matched, no further processing is performed. This is called top-down processing. If you wrote your rule base directly from a piece of paper, there may be a few problems to sort out. There will always be more than one way to define your policy; the trick is finding the best method for your organization.

As you fine-tune your policy, you can try to simplify the way you say things. By moving rules, consolidating rules, or just by stating rules differently, you can improve the effectiveness and performance of your rule base. (Performance implications and optimization is discussed in Chapter 8.) You will also need to install your rule base when you are satisfied that it is set up properly. Any changes that are made through the SmartDashboard do not take effect on the firewall module until the Security Policy is installed. The Policy menu is explained later in this chapter.

Manipulating Rules

FW-1 features a very flexible rule base. It provides the ability to alter both content and context very simply. The next few sections focus on manipulating the rule base.

Copy, Cut, and Paste Rules

Rules can be cut and pasted in a way that will be instantly familiar to most anyone. You simply select the rule (by clicking on its number), and either copy or cut the rule by right-clicking on the rule number or selecting the appropriate selection from the Edit menu, as shown in Figure 4.12. Alternatively, you can select from the Edit menu. Pasting a rule is just as easy, but there is one additional selection to make. When you select paste from the Edit menu, you will also have to decide on the placement of the rule. Your choices are top, bottom, above, or below, with the choices indicating a relation to the currently selected rule. Top and bottom are only available when using the Edit menu.

Figure 4.12: Context Menu for Manipulating Rules

Disable Rules

Disabled rules are one step from being deleted. They are not part of your security policy and are not installed when you install the policy. They are, however, displayed in the rule base window. Disabling rules is a handy method of troubleshooting, providing an easy way of recovering the rule s functionality. To disable a rule, simply right-click on that rule s number and select Disable Rule from the menu. To re-enable the rule, right-click the rule s number and deselect Disable Rule.

Notice the big X in Figure 4.13 signifying a disabled rule.

Figure 4.13: Disabled Rule

Delete Rules

Deleting a rule eliminates it from both the security policy and your rule base view. To delete a rule, simply select the rule s number and select Edit Cut . You can also select Cut from the right-click menu. While it is true that you can delete a rule outright , it is recommended you get into the habit of cutting rules, since if you mistakenly delete the wrong rule, you can recover it quickly. It is also a good idea to use the database revision control to mitigate this possibility.

Hiding Rules

Sometimes, especially with a large rule base, you do not really need to see every rule all the time. Luckily, FW-1 allows you the ability to hide rules. These rules are still part of the security policy and are still installed when that policy is loaded, but they are not shown in the rule base window.

To hide a rule, select the rule by clicking on its number. The easiest way is to right-click and select Hide from the menu, or you may select Hide from the Rules menu. A hidden rule is replaced with a thick, gray divider line, giving you an easy visual indication that a hidden rule exists.

In Figure 4.14 you can see the thick, gray line between rules 4 and 6. Notice how the rule numbers stay the same. Rule 5 still exists; you just do not see it.

Figure 4.14: Hidden Rules

You also have the ability to both view and manage hidden rules. To view hidden rules, select View Hidden from the Rules menu. Managing hidden rules is even more flexible, as it enables you to create and apply masks to the rule base. These masks can be applied or removed to alter the view of the rule base. For example, suppose you have hidden all of the rules with a specific destination. You can store this view as a mask by selecting Rules Hide Manage hidden and then storing this view. Later, if you choose Unhide All from the Rules menu, you can easily reapply the filters via the same menu options. The options for working with Hidden Rules are shown in Figure 4.15. View Hidden will show all the hidden rules, but with a dark gray background.

Figure 4.15: Hidden Rules Options

Drag and Drop

There are several ways in which you can manipulate the rules by dragging and dropping within the SmartDashboard. You can move a rule to a new location in the rule base by simply clicking on its rule number and dragging it to the new position. You can also drag network objects and services into your rules from the Object List pane and drop them in the appropriate fields. You can even drag an object from one rule into another. This can save you time when adding new rules or editing your existing rule base. It is worth your time to become familiar with this feature. For practice, and for the next section, drag rule 7 to rule 8. This will place the LAN access to the Internet rule at rule 8.

Section Titles

When working with a large rule base, it can sometimes be beneficial to break it down into logical or functional groupings. Section Titles can add this functionality to a policy. Section Titles allow an administrator to visually collapse sections of rules together for concise viewing and quicker rule locating. Figure 4.16 shows the policy with some section titles added. Rules 2 and 3 can be easily shown by double-clicking the section title or clicking the + at the right of the section title. The information about which rules are encompassed by the section title is automatically added and updated by the GUI. Section titles can be added by right-clicking a rule number and selecting Add Section Title . You can go back and edit the text by right-clicking a section title and choosing Edit Text .

Figure 4.16: Policy with Section Titles

Querying the Rule Base

The rule base can be viewed in many different ways. Sometimes it is beneficial to view it in its entirety, while at other times you may need to see only specific items. This is especially true when dealing with a very large rule base on a very complex network. One way to achieve this narrower view is through the ability to query the rule base.

To query the rule base, select Query Rules from the Search menu. A query builder will appear. This window lists queries and allows for the addition, deletion, or modification of these queries. Select New to define a new query. A window will appear that enables you to strictly define the criteria to query against. Enter a name for your query and then click New again to begin entering search clauses. This window, the Rule Base Queries Clause window, is similar to that presented when creating a group. Simply select the column you wish to query and add the objects you wish to include in the query to the In List box. You also have the ability to create a negation, that is, a query that will match only if the specified criteria are not present. The final option is to enforce the query explicitly. What this means is that the match must be exact. For example, if you select Explicit , then a query that contained a workstation object would not match a rule that used a group containing that workstation.

Policy Options

Once you have created your Security Policy, you are ready to put it into action. The next few sections describe the options available for working with the policy you have built. Access to these options is available by selecting Policy from the Policy menu.

Verify

Verify is used to test the policy. It compiles the objects and prepares them for installation, but it does not actually perform the install. This is useful when you are in the process of editing and modifying your security policy and wish to make sure that you are not doing something wrong. Selecting Verify from the Policy menu would tell you that Rule 1 blocks Rule 2 for service Telnet. This means that Rule 2 is redundant, and will never be matched on a packet, and therefore it is misplaced.

Install

This option actually performs the install. You will be presented with a list of possible firewall objects and can select the proper firewall or firewalls to install on from this list. The policy is then compiled and pushed out to the selected modules. You have a choice as to how these modules are treated.

Install on Each Selected Module Independently This is useful when you are dealing with a large number of gateways. With this option, each module is treated as a single entity, and failure to install policy on one will not impact the others negatively.
For Gateway Clusters Install on All Members, If it Fails do not Install at All This checkbox determines whether or not to allow the policy to be installed if it cannot be installed on all systems within the cluster.
Install on All Selected Modules, If it Fails do not Install at All This is an all-or-nothing proposition. If you are concerned with configuration integrity, this is the option for you. Failure on any single module will preclude the installation on any module.

You will need to install your Security Policy whenever you make changes through SmartDashboard and wish for those changes to be enforced. Nothing you do in SmartDashboard will take effect until you push the policy to the appropriate firewalls.

The Database Revision Control section allows an administrator to create a new version of the policy, which can be viewed or restored at any time. This eliminates the need for saving a new policy each time a change is made. Saving a completely new policy each time a change is made leads to very large files (specifically rulebases_5_0.fws) and can lead to slow times loading the GUI and installing policies. In addition, the objects database does not get saved each time a new policy is saved, but changes are saved and can be restored using Database Revision Control. (Database Revision Control is discussed later in this chapter.)

Uninstall

This removes the policy from the objects that you select. The object selection method is identical to that when installing policy.

View

The View option enables you to view the compiled security policy; that is, it enables you to view the inspect statements, which allows you to view and save the actual inspect scripts. Saved files can be manually altered and loaded with the command-line interface (CLI) of FW-1, though it is not recommended and likely not supported by Check Point.

Access Lists

This is used to incorporate rules into an Open Security Extension (OSE)-compliant device, such as a router. When a rule is installed on a router, the firewall is actually generating an access control list (ACL) for that router and applying it as needed. You can also import the existing ACL entries for the OSE device and verify and edit them. This menu option allows for all three functions. When selected, the OSE Device Access List Operations window is displayed. This window enables you to select the OSE device you want to interact with and perform the specified operation. When fetching an ACL, you can further specify the direction you are interested in and the format you wish the ACLs to be presented in (ASCII or GUI). This requires additional licensing.

Install Users Database

This option, available from both the Policy menu and the User Management function, propagates the user database defined on the management server to the selected modules. Note that the user database is also loaded when a security policy is published (pushed/installed) to the modules, but this manual process allows the updating of user information without interfering with the firewall operations.

Management High Availability

This option of the Policy menu enables you to modify the behavior of your Management High Availability groups. This feature allows multiple management modules to synchronize and support each other, just as with HA FW-1 modules. This option loads a maintenance panel, which allows for both manual synchronization and preempting of the primary management server.

When performing a manual synchronization, you have two modes of behavior to select from.

Synchronize Configuration Files Only If this is selected, only the database and configuration files will be synchronized between management modules.
Synchronize Fetch, Install and Configuration Files This mode also synchronizes the Fetch and Install files, allowing the interaction with a standby management server.

You can also change the current state of the management module, from Primary to Standby and vice versa. Note that a Standby management module cannot be used to push or edit configurations until it is promoted to Primary status.