Implementing a Security Policy

Now that you have a written information security policy and a perimeter security policy, you can begin configuring and deploying Check Point NG by translating your organization's policies into a policy that can be enforced by Check Point NG.

Default and Initial Policies

Let's start by understanding the default and initial policies in FW-1 NG. The default and initial policies taken together comprise boot security for FW-1 NG. Unlike previous versions 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. 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 communications are not spoofed on any of its interfaces.

As FW-1 NG 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 14.2.

Figure 14.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.

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 can enforce. Remember that the FW-1 NG policy is composed of global properties (which are implicit, as shown in Figure 14.3) and an explicit rule base. Now let's begin translating and building a security policy.

Figure 14.3: Global Properties Implied Rules

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

In the new policy dialog as shown if Figure 14.4, you can see that you have a few options. First type a name for the policy. Now select Security and Address Translation as your Policy Type. This will now enable the Helpers portion of the dialog. In Check Point NG there are three ways to begin defining your new policy: wizard, Template, and empty policy.

Figure 14.4: New Security Policy Dialog

The wizard method is based on four template networks:

• Starter network Dual-homed firewall with one connection to the external network. SMTP mail server is on the internal network. The wizard will walk you through allowing SMTP traffic from the Internet to your mail server.

• Publisher network Dual-homed firewall with one connection to the external network. Mail server, FTP, and Web servers are located on the internal network. The wizard will walk you through allowing SMTP traffic in to the mail server, allowing FTP traffic to the FTP server with or without authentication, and allowing HTTP or HTTPS traffic to the Web server with or without authentication.

• DMZ network Three-homed firewall with one connection to an external network, one to a service net, and one to an internal network. In this template you can configure permitted services from the internal network to the external network. The wizard will walk you through allowing SMTP traffic in to the mail server, allowing FTP traffic to the FTP server with or without authentication, and allowing HTTP or HTTPS traffic to the Web server with or without authentication.

• Secure mail network Three-homed firewall with one connection to an external network, one to a service net, and one to an internal network. In this template you can provide for secure access to the mail server by SecuRemote users.

Using the template method, in contrast to the wizard method, creates an incomplete rule set. Although the rule base gets created, the objects remain undefined until you edit each one individually. In fact, all objects will require definition before you can install the policy. The wizard and template are very similar. However, the wizard walks you through the entire setup and makes you define all of the objects up front.

The wizards and templates are an easy way to get things configured to support basic services, or for new administrator with small networks. However, having a security policy that is fine-tuned for your organization is going to require that you do some manual definitions and ordering of objects and rules. So, let's start with an empty policy and begin building the policy from scratch.

Defining a Firewall Object

The first step in translating the written policy into an enforceable policy is to define the relevant network objects. After creating the network objects, you can create and/or modify the firewall workstation object. Having the networks defined first will enable you to configure anti-spoofing on the firewall object. The firewall object is something you must define before you can install your FW-1 security policy.

If you have initially installed the FW-1 Module, Management Server, and GUI 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 will start by logging into your management server via the Policy Editor GUI. If you haven't opened the Workstation Properties yet, as shown in Figure 14.5, you may do so by selecting the firewall object from the Objects List at the bottom of the window, 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 14.5: Workstation Properties with Check Point Products Installed

If you are creating the firewall object for the first time, then you can right-click Network Objects in the Objects Tree and choose New | Workstation. 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 (Domain Name System) be configured to resolve this name to the firewall's external IP address, or at least have it set up in the host's file on the firewall. 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 next field, 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 let's make this workstation a firewall. If it hasn't been checked already, check the box that reads Check Point products installed and select the version NG. This will enable the next list of product modules. Choose from the list the modules that are installed on this host. Next, in the section Object Management, you must select whether the Management Server for this firewall is Internal or External. Basically, by checking Internal, you signify that this Management Server will be able to install policies on this FW-1 module, and when you view the System Status GUI, this firewall object will be displayed. If the Management Server and firewall module are on different hosts, then 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 what products you have installed and has made the selection for you. Please double-check that the selection is correct before you continue. Finally, if an external management server manages this firewall module, then you will be able to use this external firewall in the rule base and configure it as a VPN endpoint, but you will not be able to install policies to it (another management server will do that), and it will not be displayed in the System Status Viewer. In short, you do not manage external firewall objects from this management server.

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 14.6 illustrates this configuration window.

Figure 14.6: Topology Window

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

Figure 14.7: Topology Definition

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. If you are running SNMP on the object, then you have access to the Get Interfaces feature, which will query the system for its interface information (this is the recommended method of gathering this information).

Not only will you be 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 14.7.

If the interface is internal, then it is very important to define the addresses that reside behind the interface. The first option, Not Defined, generally should not be used. 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, then these addresses will be calculated based on the address and subnet mask for this interface. Finally, you can specify an explicit range of addresses or groups of networks. Anti-spoof tracking can also be defined on a per-interface basis.

The Management branch is quite important for your FW-1 configuration. The Management window enables you to specify logging options. These options are broken down into two varieties: Local Logging Options and Advanced Settings.

The Advanced window allows the configuration of SNMP settings. If you expand the Advanced branch, you will see the following three sub-menus:

• SYNDefender

• SMTP

• SAM

The SYNDefender branch is used to configure the firewall options to defend and respond to SYN attacks. Attackers may try to create a Denial of Service (DoS) by initiating a SYN Flood attack. Taking advantage of the connection-oriented nature and initial three-way handshake of TCP/IP, an attacker can keep requesting connections that a server will accept until it is out of resources. FW-1's SYNDefender option is disabled by default. To enable it, select SYN relay, SYN gateway, or Passive SYN gateway. These options are displayed in Figure 14.8.

Figure 14.8: SYNDefender Options

SYN relay monitors all connection attempts, and verifies that the attempt is valid before sending the initial SYN to the server. SYN gateway monitors all connection attempts as well as after the server responds with a SYN-ACK; the firewall also sends an ACK to the server and opens the connection so that the server's backlog queue is available to accept more connection requests. The timeout setting determines how long the firewall will wait before either receiving a response from the client and allowing the connection or closing the connection with the server by sending a RST (reset) packet. Finally, the Passive SYN gateway monitors all connection attempts like the gateway option, but it does not send an ACK to open the connection to the server. Instead, the passive method waits the allotted timeout period, and if the connection is not valid, it will send an RST to the server. For firewall modules prior to NG, the SYNDefender setting is configured under the Global Properties, FW-1 branch. Check Point recommends using the SYN gateway method if your network is susceptible to these types of attacks.

Warning

A TCP/IP connection is established when a client requests the connection by sending a SYN packet to the server. Once the server receives the request, it will respond with a SYN-ACK acknowledging the client's SYN packet. Finally, the connection is established when the client sends an ACK back to the server completing the three-way handshake. When a SYN Flood attack is underway, a malicious client is sending multiple SYN packets to a server with spoofed source IP addresses so that when the server responds with a SYN-ACK, it does not receive a response in return to complete the connection. The server will save these initial sessions in its backlog queue and wait for a response. A SYN Flood attack works by filling up this backlog queue with bogus requests, which causes any valid connection attempts to fail, thereby creating a DoS.

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.

On the final 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.

Define Rule Base

Now let's use our perimeter network security policy to create a Check Point FireWall-1 NG enforceable policy. The first step is to map things out and identify the objects that will compose the rule base. The following 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 Web Server

Reading through your policy, it refers to the LAN, the Internet, and a Service Net. These are all network objects, which will have to be defined before you can continue. Next, traffic is flowing anywhere, to the Web server, mail server, 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. Based on the work you did earlier, you should be able to create these on your own.

Now that you have all of the objects defined, it's time to create the rule base. For your first rule, it is best to create the Clean-up rule. By default, anything that is not explicitly permitted is dropped. However, it would be nice 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 Rules | Add rule in Policy Editor. 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, service Any, action Drop, and 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 such as "Clean-Up Rule". At this point, your rule base should consist of one rule and look like the example in Figure 14.9.

Figure 14.9: The Clean-Up 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 by clicking Rules | Add rule and choose 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, Alert as illustrated in Figure 14.10. Add a comment such as "Stealth Rule" in the Comment field.

Figure 14.10: The Stealth Rule

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 doesn't call for any user authentication, you can leave your Stealth Rule at the top. Let's place this next rule beneath the Stealth Rule. Click on the icon in the toolbar that represents Add Rule below Current. The current rule will always be the rule that is highlighted in white, instead of 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 as the Source. For the Destination, select the Service Net (we'll explain why in a minute). Under the Service field, add HTTP and then HTTPS. Make sure you select Accept in the Action field. The Track field can be left at None 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 but the Service Net. The reason you had to do this is because the policy doesn't allow HTTPS from the LAN to the Service Net, as you will see in the next couple rules. Use the Comment field to enter a comment such as Permits LAN access to http and https on the Internet.

Next, 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 the DNS server for DNS queries. Let's leave SMTP and FTP for later. Start creating the next rule by right-clicking on the number two 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 Pop-3 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 anyway, so leave Track as None. In the Comments field, write in "Permits LAN access to retrieve email via pop-3." 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, let's not log this traffic because domain queries can be quite numerous and we don't need to log it. 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."

Now 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. This new rule (number four) 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. The next rule, Rule number five 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 doesn't allow your LAN to connect to the Web 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 FireWall-1 Rule Base shown in Figure 14.11. You should select File | Save or click the Floppy Disk Icon to save your finished policy.

Figure 14.11: Rule Base from Security Policy

Now, 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, then 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. You will also need to install your rule base when you are satisfied that is it set up properly. Any changes that are made through the Policy Editor do not take effect on the firewall module until the security policy is installed. The Policy menu will be 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.

Cut and Paste Rules

Rules can be cut and paste in a way that will be instantly familiar to anyone. You simply select the rule (by clicking on its number), and either copy or right-click and select Cut from the menu. The menu is shown in Figure 14.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'll 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.

Figure 14.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 reenable the rule, right-click the rule's number and deselect Disable Rule.

Notice the big red "X" in Figure 14.13 signifying a disabled rule.

Figure 14.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 click the rule's number and select Cut from the Edit menu. You can also select Cut from the right-click menu. While it is true that you can delete a rule outright, we recommend getting into the habit of cutting rules, since if you mistakenly remove the wrong rule, you can recover it quickly by pasting it back in.

Hiding Rules

Sometimes, especially with a large rule base, you don't really need to see every rule all the time. Luckily, FW1 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 its number. Next, right-click and select Hide from the menu, or select Rule | 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 14.14 you can see the thick, gray line between rules four and six. Notice how the rule numbers stay the same. Rule five still exists; you just don't see it.

Figure 14.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 in Figure 14.15.

Figure 14.15: Hidden Rules Options

Drag and Drop

There are several ways in which you can manipulate the rules by dragging and dropping within the Policy Editor. You can move a rule to a new location in the rule base by simply clicking 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 could save you some time when adding new rules or editing your existing rule base. It's worth your time to play around with this feature a little and start to get the hang of it.

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 defined queries and allows the addition, deletion, or modification of 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, add the objects you wish to include in the query to the In List box, and you're done. 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 Editor menu.

Verify

The Verify option 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 aren't doing something wrong; for example, if you have a rule on top that accepts Telnet to anywhere, and then below that you create a rule to allow Telnet to a specific host. 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

The Install option actually performs the install. You'll 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.

• Install on all selected Modules 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 other module.

• Install on all the modules of the selected Gateway Cluster This applies to Gateway Clusters and is identical in behavior to the above Install on all selected Modules option.

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

Uninstall

The Uninstall option removes the policy from the objects that you select. The object selection method is identical to that used when installing a 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.

Access Lists

The Access Lists option is used to incorporate rules into an OSE compliant device, such as a router. When a rule is installed on a router, the firewall actually is 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

The Install Users Database 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

The Management High Availability 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 highly available 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.