...and avoid mistakes when updating your configurations.


When performing an address change on your servers (e.g. due to reorganization of your data centers, virtualization, consolidation...), you will have to reflect these changes in your firewall configurations. Depending on how large and numerous your firewall configurations are, locating the firewall(s) to change and finding the places in their configuration that need updating, can be tedious and error prone.

 

This blog reflects a fairly frequent real-life use case, and explains how FSM - Firewall Security Manager - can help making these changes quickly and safely, by double checking them before they are put in production.

The concrete example will be to detect where to make changes so that the IP of 2 servers 192.168.253.34-35 can be changed for the new addresses: 192.168.253.160-161, while keeping the protection of your firewalls in place.

 

Finding the firewalls impacted by the change

The Query/Search Rules function searches in the configurations of your firewalls, even within subnet masks. Note that a simple text search in your configs will usually not be efficient because a) it would not find the address you are looking for, within a subnet definition and b) searching on the beginning of the address, e.g. 192.168.253 could return 100's of hits in a real life config.

FSM Rule Query.PNG

The blue window shows how to define the query.

Note that in order to avoid finding all the rules that have ANY in the searched parameters, check the box at the bottom of the window.

Then select all firewalls in your inventory (left portion of the pain window) and run the query.

We recommend saving it before the run (notice the Saved Queries tab at the bottom left corner)

 

FSM finds the impacted firewalls, and the objects to modify in their configurations

FSM Rule Query finds impacted firewalls and objects.PNG

The result will show up in a new tab on the right, and will contain one sub-tab per firewall vendor that contains the searched address. In this example, we will focus on the Cisco Firewalls tab, but in reality, you would have to check all vendor tabs.

In this example, the Cisco firewall HV-FW-01 contains a destination network object called Servers_in_Public_DMZ (used in a rule that appears in config line #570) that refers to 2 addresses that we are trying to change: .34 and .35.

The statement to change is 192.168.253.32    255.255.255.248, that "contains" .34 and .35

 

Preparing the change by using the Change Modeling session

A change modeling session is a very convenient feature that creates a safe environment (basically a copy of your production configurations) that you can use for all your tests and changes, without affecting your production configs.

Select the impacted firewall(s) that you identified with the above steps and click Analyze Change / New Change Modeling Session, and name your session (e.g. Server IP Change session)

FSM Change modeling session.PNG

Notice the new TAB on the right (this is your testing environment), that contains a copy of the config tile (config.txt), routing tables, and the tools available to test your changes (icons on the right)

 

Performing the changes

Double click on the config.txt to open a text editor that you will use to modify the configuration.

Search (CTRL F) for the impacted network object: "Servers_in_Public_DMZ" and modify this section:

 

object-group network Servers_in_Public_DMZ

network-object host 192.168.253.15

network-object 192.168.253.32    255.255.255.248

network-object 192.168.253.64    255.255.255.248

 

as follows:

object-group network Servers_in_Public_DMZ

network-object host 192.168.253.15

network-object 192.168.253.32    255.255.255.254

network-object 192.168.253.36    255.255.255.252

network-object 192.168.253.160   255.255.255.254

network-object 192.168.253.64    255.255.255.248


Then save your new config.

At this point you have impacted the copy of the config that sits in the Change Modeling Session, but not the main version of the config within FSM.

 

Verifying that the changes are valid

You have several tools available, that you can launch via the icons on the right, to test the impact that you have made with your change.

In essence, all these tools highlight the differences between the main and copied/modified versions of the versions.

 

We will focus here on the Compare Rule/Object tool.

The result is an Excel report that is generated within the Change modeling session:

FSM Change modeling session details.PNG

Open the report and look at the different tabs:

  • Rule Compare reminds you of the change that has been performed at the rule level (on line 570, an ACL statement is impacted because the destination Servers_in_Public_DMZ has changed)

FSM Change modeling session details - Rulle diff.PNG

  • Network Object Compare highlights the changes that happened to the modified Network Object: Servers_In_Public_DMZ in this example. Red denotes removed lines and green is used for added ones.

FSM Change modeling session details - Object diff.PNG

  • Traffic Flow Compare confirms that you have removed and added the expected traffic, so the traffic to the new server, after the IP address change, remains unchanged

FSM Change modeling session details - Flow diff.PNG

You can find more about this report here.


Putting these changes in production

Now that you are comfortable with these changes, click on the Generate Change Scripts tool on the right side of the Change Modeling Session window.

FSM Change modeling session details - Script.PNG

Here is what the generated script looks like, in this example:

 

!-- Object <Servers_in_Public_DMZ> Change summary

!-- Modified object

!-- Deleted member 192.168.253.32/29

!-- Added member 192.168.253.32/31

!-- Added member 192.168.253.36/30

!-- Added member 192.168.253.160/31

object-group network Servers_in_Public_DMZ

network-object 192.168.253.32 255.255.255.254

network-object 192.168.253.36 255.255.255.252

network-object 192.168.253.160 255.255.255.254

no network-object 192.168.253.32 255.255.255.248


!-- ACL Rule Change summary

!-- Modified rule

!-- Modified destination Servers_in_Public_DMZ

!-- No change command needed as this is an indirect change caused by modifications to object/object groups used in the ACE.

!-- access-list outbound extended permit tcp object-group DM_INLINE_NETWORK_14 object-group Servers_in_Public_DMZ object-group DM_INLINE_TCP_3

 

After you review the proposed changes, you are ready to put them into production by executing these commands in the firewall console

If this device was managed by NCM (not the case in this example), you can actually execute the script via NCM (right click menu Execute Script), so you don't even have to connect to the device console (NCM does it for you)

FSM Change modeling session details - Script exec.PNG

 

You can then use this button to update the configuration into FSM, from whatever source it was taken from - NCM or the device itself - and make sure that your changes were taken into account.

FSM Update configs.PNG

 

I hope that was helpful and would really welcome reading your FSM use cases - does not have to be that detailed :-) .

[thanks to Lan Li, FSM dev, for his contribution]