SecureTrack

Details

Category: SecureTrack

Last Updated: 05 November 2022

This article is about a legacy license feature. This feature cannot be licensed anymore. If you purchased and installed it on your SecureTrack Server earlier, it still can be used for Check Point up to Version R80.x without problems.
-------

When having a Check Point firewall, it is possible to monitor the Check Point management. All information about a connected firewall is gathered from here. Sometimes it is wanted that this information is collected directly from the firewall using SNMP. This works since many versions of Check Point and SecureTrack quite well, following the configuration guide published by Tufin - as far as the license has been purchased (TF-SECTRK-CP-GAIA-OS-MONITOR).

Hint:
If you import a Check Point firewall, all topology data are derived from here, no more from the Check Point management. So if there is a problem with SNMP (e.g. connectivity, authentication), no topology data are available for this firewall.

Problem when having Check Point R81:
Independent of the configuration (that has worked for R80.x and earlier), the firewall running R81.x delivers "wrong password" in Menu > Settings > Administration > Status.

Therefore no data are imported into SecureTrack and also no topology information is available for this firewall.

Following a discussion in the Check Point CheckMates community and also Tufin Technical Support, the authentication of SNMPv3 users with SHA1 is not supported anymore.
Only SHA256 and SHA512 are supported by Check Point R81.x. To solve this issue, some additional steps are required.

So the complete integration of a Check Point Firewall R81.x into SecureTrack includes these steps:
(examples used here: SNMPv3 user: securetrack, Interface: 127.0.0.1, Password: password123)

• Open the WebUI of GAiA
  • Activate SNMP agent running SNMPv3 and select the corresponding interface
    
    
    
  • Define a user (e.g. username "securetrack", passphrase "password123")
    
    
    This user shows up in GAiA then.
    
    Due to the selected Authentication Protocol, this user cannot authenticate when configured in SecureTrack.
    
    
    
• Open a console window on the GAiA system after having closed the WebUI.
  In Expert Mode check that this user can authenticate, using e.g. this command:
     r81_expert> snmpwalk -v 3 -l authPriv -u securetrack -a SHA-256 -A password123 -x AES -X password123 127.0.0.1
     HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (27949040) 3 days, 5:38:10.40
     ...
     r81_expert>
  
  
• Now it is necessary to change the authentication protocol. The corresponding values can be gathered e.g. from a system running GAiA R80 (file /config/active).
  By default in R81, the user is listed in this file with this entry for using SHA256:
     r81_expert> cat /config/active | grep auth:proto
     snmp:v3:user:securetrack:auth:proto .1.3.6.1.6.3.10.1.1.5
  
  To change the authentication protocol for the user defined above to SHA1, go to the console in expert mode:
     r81_expert> dbset snmp:v3:user:securetrack:auth:proto .1.3.6.1.6.3.10.1.1.3
  
  
• The authentication type now has been changed to SHA1. This can be checked using the console (clish)
     r81> show snmp usm user securetrack
       Username securetrack
       Permissions read-only
       Security Level authPriv
       Authentication Type SHA1
       Privacy Type AES
  
  
  
• Since the authentication protocol has been changed, the password needs to be set again - don't forget this step...
  (it needs to be done via CLI / clish. In case, just copy / paste it to the CLI from an editor on your PC)
     r81> set snmp usm user securetrack security-level authPriv auth-pass-phrase password123 privacy-pass-phrase password123
     r81>
  
  and check the authentication by e.g. this command in expert mode:
     r81_expert> snmpwalk -v 3 -l authPriv -u securetrack -a SHA1 -A password123 -x AES -X password123 127.0.0.1
     HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (28182734) 3 days, 6:17:07.34
     ...
     r81_expert>
  
  
• Now everything is prepared to import the firewall module into SecureTrack via Menu > Settings > Monitoring > Manage Devices
  
  
  
  
• Select the firewall you want to import (this management has connected only one firewall)
  
  Be sure to fill in the correct username and password as configured before. Press Next
  
  
• Now select the network interface SecureTrack shall connect to
  
  and import the interface. The configuration is saved automatically then.
  
  
• In Menu > Administration > Status, the firewall shows up below the management server. It is necessary to check the status. It should be "green" and "started"
  
  
  
• It this is the case, the first revision should have shown up. This is to be checked via Menu > Compare
  

Details

Category: SecureTrack

Last Updated: 18 May 2021

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.

Details

Category: SecureTrack

Last Updated: 18 April 2021

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.

Details

Category: SecureTrack

Last Updated: 21 October 2020

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.

Details

Category: SecureTrack

Last Updated: 12 September 2021

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 a 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.