In some situations, it might be necessary to add Interfaces to devices. Reasons might be a not by Tufin recognized Interface or the support of VRRP or GLBP. You need some steps to add a generic Interface to a device monitored by SecureTrack.

  1. Find the Device ID of the device that gets one or more generic Interfaces
  2. Configure a CSV file providing information about generic Interfaces
  3. Import the CSV file to Tufin SecureTrack
  4. Synchronize the Topology and check the result

 

1. Find the Device ID in Tufin SecureTrack

There are several methods to find the Device ID in SecureTrack.

In Menu > Compare all monitored devices are listed on the left side. If you click into the left window and press "t" the Device ID is shown right from the device.

It is also possible to gather this information at the CLI using the command "st stat".

You need to pay attention if you are using a Firewall Management like e.g. Check Point SmartCenter. In this case, you will need the Device ID of the firewall and NOT the Device ID of the Management (!)

To find the Device ID of the Firewall you need to go to Menu > Settings > Administration > Licenses. Here you scroll down until the window "Devices" is shown. Clicking into it and pressing "t" will show the Device ID not only of the Management but also of the Firewalls connected to it.

In this example, the Device ID of the Firewall "r81" is 344. If Device ID 343 is taken, the Management is altered resulting in an error in the Topology.

 

2. Configure a CSV file providing information about generic Interfaces

The file providing the information needs to be a plain ASCII file with a ".csv" extension. If another file type is chosen, the import will not be successful.
Each line needs to have six comma-separated entries. Even if there is no entry, the comma needs to be written.

  • Name of the generic Interface
  • IP address of the generic Interface
  • Mask corresponding with the IP address, dotted-decimal
  • VRF where the generic Interface resides
  • MPLS i.e. boolean expression if the generic Interface has configured MPLS
  • Unnumbered, blank means that the Interface is numbered, unnumbered requires a "true"

Each generic Interface requires an own line. Example for a very simple generic Interface:
   MyNewInterface, 10.2.2.1, 255.255.255.0,,,

Hint:
The information provided in this file always replaces all generic Interfaces that are configured on the device. So if you want to add a generic Interface, you will provide information about the new, but also the already configured generic Interface.

 

3. Import the CSV file to Tufin SecureTrack

The file now can be imported. This is done by the command
  /usr/local/st/topology_generic_interfaces -m <Device ID> -i <file name>

[root]# /usr/local/st/topology_generic_interfaces -m 344 -i MyGenericInterface.csv
Successfully deleted all generic interfaces for device 344
1 generic interfaces has been loaded to device 344 from input file MyGenericInterface.csv.
[root]#

If necessary, generic Interfaces can also be deleted. To delete all generic Interfaces from Device ID 344 this command should be used for this task:
[root]# /usr/local/st/topology_generic_interfaces -m 344 -d
Successfully deleted all generic interfaces for device 344
[root]#

 

4. Synchronize the Topology and check the result

If you have time, you can wait until the next morning since at 3:00 a Topology Synchronization is done automatically. If not, the synchronization needs to be started manually. This is done using the WebUI via Menu > Network > Interactive Map and the "sync button".

After a refresh, the new generic Interface is established and used by SecureTrack for Topology calculation and representation.

 

 

 

 

 

When having SecureTrack and SecureChange, revisions can be compared. Additionally, the SecureChange Ticket ID is available as a link in SecureTrack. Following this link from SecureTrack, the referring ticket is automatically opened and shown in SecureChange (if the current user is allowed to access it).

Additional information can be gathered using SecureTrack > Home > Change

In this table, all revisions are listed. Information provided is the device, the revision number as well as who did the change. The right row shows states like e.g. "Authorized". Let's have a closer look at the conditions about the shown status.

  • N/A
    SecureTrack runs without SecureChange or the option for linking SecureChange tickets with a revision is not active. It can be activated by a SecureTrack administrator via the menu:
    Menu > Settings > Configuration > Ticketing

    This option allows to restrict the search in tickets for a specific time, e.g. 3 months. If it's not restricted, the whole ticket database will be searched for possibly matching tickets. So iit's possible to have (much) more than one ticket matching the change.

  • Authorized
    The change is authorized under several conditions
    • The change has no influence on the traffic passing the device. This happens e.g. if a comment has been added to a rule or an object has got a new color.
    • The change doesn't allow any new (additional) traffic.
    • The change allows exactly the traffic that has been requested and approved by a ticket. In this case, the ticket ID is shown in the line. It might be possible that there is more than one ticket referenced. This is due to more than one ticket matching the change. Considered are all tickets in the time frame configured as shown above.

  • Unauthorized
    Then change is unauthorized under several conditions
    • There is a change regarding traffic through a device with no matching ticket for it. This is the situation if a change is done without requesting it by a ticket. The change is directly configured in e.g. Check Point SmartConsole.
    • The change done is not completely covered by a ticket. This happens if e.g. the service SSH is requested, but SSH and HTTPS are implemented. In this case, only a part of the change has been requested and approved by a ticket. The ticket ID is shown in this line.
    • The change requested a "rule modification" and not all changes are covered by a ticket. This includes also removal of e.g. services. If the service HTTP should be removed from a rule, but HTTP and FTP are removed, the change is unauthorized also (even if less traffic is allowed afterwards).

 

Manual changes on the status

Besides this, a manual change of the status is possible. This might be useful when e.g. an emergency change needed to be configured. Changing the status requires administrative access to SecureTrack. This option is not available for a "user", even for the device he or she is allowed to see.

If a change needs to be "authorized" manually, just go to the pen shown near the status.

   

In this example, an "unauthorized" change will be changed to "authorized". After confirmation, the status is changed, but a sign allows to see that the change was done manually. Besides this, the date and administrator are shown.
The same procedure can be done to "unauthorize" changes manually.

 

Hint regarding compliance

Current versions of SecureTrack don't allow to add a comment if the status is changed. That's the reason why the column "Comment" is empty in Menu > Home > Change. This column is not shown in the overview (Menu > Home > Dashboard).

The missing opportunity to provide a comment (i.e. reason for the manual change) might be problematic if the configuration is audited. So the reason for changing the status needs to be documented somewhere else.

 

 

 

 

 

 

 

 

In many situations, Firewalls not have their "productive" interfaces only, but also others like e.g. Management Interfaces. If this is the case and many Firewalls are connected not only via "productive" interfaces but also via Management Interfaces, some problems might arise. One could occur when SecureTrack Topology is used to check the path a packet takes. Even if it's not the case in real life, Topology could consider the shortest way using the Management Network... As a consequence, the Designer of SecureChange could also assume this path - and the result isn't as expected.

So in many cases, it seems to be useful to ignore single interfaces in SecureTrack Topology. This can be done quite easily, but it needs to be done very carefully and well documented (!).

Please don't continue before you have made a backup of your data!

To find out the relevant device, you first need its Management ID in Tufin SecureTrack. If it's a directly monitored Firewall (e.g. Cisco ASA, FortiGate without FortiManager or directly monitored Check Point Firewall Module) the Management ID can be found in Menu > Compare. Go to the left pane called "Monitored Devices" and press "t". The Management ID shows up beside the name of the device. In the screenshot shown below, Firewall modules have the Management ID 290 and 294, respectively.

If only the Management is listed here, another step is necessary because here only the ID of the Management is shown.

 

In this case, you need to go to Menu > Settings > Administration > Licenses. Here you scroll down to the section called "Devices", click into it, and press "t". The Management IDs of all Devices will be shown here.

Next is to find which interface shal be ignored by Tufin Topology. You can obtain this information from SecureTrack or directly from the device. 
To have an example, we will ignore the Interface "Mgmt" of the device with ID 290 and IP address 192.168.1.1 from Topology.

This information needs to be stored in the database. You can do this using the REST API or directly via CLI. In this example, we use CLI for modification of the table "ignored_interfaces".
To get a list of all currently "ignored_interfaces" this command should be used:

[root@TufinOS ~]# psql -Upostgres securetrack -xc "select * from topology_ignored_interfaces"
-[ RECORD 1 ]--+-----------------
interface_name | ethernet1/1
mgmt_id        | 2
ip             | 0.0.0.0
[root@TufinOS ~]#

To add an interface to this list, be sure to have the Management ID of the device as well as the name of the interface and its IP address. Then it can be added to this table using

[root@TufinOS ~]# psql -Upostgres securetrack -xc "insert into topology_ignored_interfaces (interface_name, mgmt_id, ip) values ('Mgmt','290','192.168.1.1')"

After having done so, this interface is listed in the table and therefore ignored by SecureTrack Topology - after a Sync of the Topology (!).
(The IP address can also be left out, then it later shows "0.0.0.0")

[root@TufinOS ~]# psql -Upostgres securetrack -xc "select * from topology_ignored_interfaces"
-[ RECORD 1 ]--+-----------------
interface_name | ethernet1/1
mgmt_id        | 2
ip             | 0.0.0.0
-[ RECORD 2 ]--+-----------------
interface_name | Mgmt
mgmt_id        | 290
ip             | 192.168.1.1
[root@TufinOS ~]#

If you look at the device in the Topology, this interface isn't listed here any more.
To remove an interface from this list and to get it back into Topology, just take the command

[root@TufinOS ~]# psql -Upostgres securetrack -xc "delete from topology_ignored_interfaces where interface_name='Mgmt' and mgmt_id='290'"

To make this change effective, don't forget to Synchronize the Topology again.

 

 

 

 

 

Having a Unified Security Policy (USP) requires to have network zones defined, filled with all relevant networks.
This is done in SecureTrack via Menu > Network > Zones. Only zones defined here can be used in an USP configuration.

There are some pre-defined zones:

  • Internet
    This zone includes all official IP-Adresses that are not defined to be in any other zone
  • Unassociated Networks
    This zone includes all private IP-Adresses (RFC 1918) that are not defined to be in any other zone
  • Users Networks
    This zone includes all networks that users connect to (e.g. used in Check Point Identity Awareness)

Based on interface information of devices, zones are allocated with interfaces automatically - except the zone Internet.

Tufin SecureChange calculates "Risk" in Access Requests in the classic way while SecureTrack uses for the calculation of "Violations" a specific configuration that can be adapted.
To modify interfaces and zones, it's necessary to go to the USP list, i.e. Menu > Audit > Compliance > Unified Security Policy. Here you select an USP to modify the relationship of Interface - Zone. This is done by pressing the button "Preferences". A window opens, so you can modify the allocations manually.

In this example, the Interface "pppoe2" has no associated zone even if (in real live) the "Internet" is connected to this Interface. To configure this, select the interface and then the button "Edit" at the top right. Here, you select the zone that shall be connected to this Interface.

After having done so, the configration is changed by pressing the button "save".

So from now on, calculations regarding "violations" consider this configuration and zone association.

Please regard: Be sure to document well all changes done this way!
In SecureTrack Audit Trail only this message is shown "Unified security policy configuration - Modify - Device - FWGW-Office - Modify was done by MeAdmin on interface/zone mapping for device FWGW-Office".

Changes done here have direct impact on "violations", so every configuration change needs to be documented well.
The calculation of "violations" is done when a new revision arrives to SecureTrack, a USP is changed or the Topology (Interactive Map) is synchronized.

 

 

 

 

 

 

Since Check Point R80 it's necessary not to connect Tufin SecureTrack to a Check Point Management using only OPSEC, but a HTTPS connection to the Check Point Management API is necessary also. This might result in a scenario shown here.

Problem and Symptom

  • Monitoring the Check Point Management R80x has been configured successful in SecureTrack i.e. connections using OPSEC and Managmenent API are configured and certificates have been retrieved.
  • Testing the connectivity by SecureTrack has been successful
  • Starting the newly monitored Check Point Management has been successful, the icon is indicated with a grren sign - so everything seems ok

BUT

  • no revisions are retrieved
  • in the file /var/log/st/checkpont.get_checkpoint_conf_<IP>_<ID>.log an information is shown:
    [main::c.t.s.c.GetCheckpointConf.handleVersionMismatch] [user:] Device Version Mismatch : The Device Got Version mismatch returning device version for updating db
    [main::c.t.s.c.GetCheckpointConf.handleVersionMismatch] [user:] Server API version 1.5, Max supported API version 1.5, argument API version 1.1

Solution

Tufin SecureTrack seems to take the wrong version of the Check Point API. This isn't always the case, but it might happen. In this case, SecureTrack tries version 1.1, but the Check Point Server uses version 1.5. This needs to be adjusted, using these steps:

  • Check if the file /usr/local/st/javatools/config.properties is present
  • If not, create a new file using vi or another CLI editor and
  • insert this line:
    checkpoint.sdk.api_version=v1.5
    This defines the version SecureTrack shall take for monitoring Check Point Management R80.x.
    The version shown above is fine for the logs above, but if necessary take another (correct) version
  • Restart the monitoring of this device in SecureTrack by
    # st restart <ID>

Short after these steps, a revision should show up in SecureTrack.

 

 

 

Besides standard functionality, Tufin offers extra tools like "Reporting Pack". This requires a special library, called PS Scripts. First of all, you need to download the file from the Tufin Portal (authentication required):

  • PS Script 5.5.7 (for Reporting Tool) Setup
    (credentials for access to SecureTrack and SecureChange are requested)

After having downloaded This file, it's necessary to install the package - and please remember to create a backup of your Tufin Server before doing so!
Then install the library (as root or with sudo on e.g. SecureTrack Server for Reporting Pack):

  •      # /bin/sh setup_tufin_ps_scripts-5.5.7.run -W

Be sure not to forget the "-W" (upper case) when installing the libary. Credentials needed are "Super Admin" for SecureTrack and "Security Administrator" for SecureChange. 
To check a successful installation of the library, run the command

     # ls /opt/tufin/securitysuite/ps/conf/WEB_ENABLED

If this file exists, everything is fine. You can also check if the service is running using the command

     # /etc/init.d/tufin-ps-web status

The service should be running. If not, you may try to start it via CLI.
To check the version of the library, use

     # cat /opt/tufin/securitysuite/ps/PS-version, Logs are stored in the directory /var/log/ps/Tufin_PS_Logger.log.

If all work is done, you can install Reporting Pack or use the library for Tufin PS or your own scripts.