SecureTrack

Details

Category: SecureTrack

Last Updated: 27 April 2022

When monitoring a Check Point Management Server and its firewalls with SecureTrack, sometimes an issue is found after upgrading Check Point.
The error message regarding a device is "Inconsistent SSL data stored in db for device...".

To solve this problem, a backup needs to be done first (!).

A first approach to solve this issue is to renew the certificate of the Check Point Management. This can be done using these steps:

TOS Classic:
Go to Menu > Settings > Administration > Monitoring. Select the device delivering the message and select "Edit configuration". Go through the first steps using "Next". In step 4 the user name and password are provided for the connection to the Check Point Management. Provide these data and press "Establish connection". By doing so, the certificate is going to be replaced. After going through the remaining steps with "Next", save the modified configuration. This should solve the problem.

TOS Aurora:
Go to Menu > Monitoring > Manage Devices. Select the device delivering the message and select "Edit configuration". Go through the first steps using "Next". In step 4 the user name and password are provided for the connection to the Check Point Management. Provide these data and press "Establish connection". By doing so, the certificate is going to be replaced. After going through the remaining steps with "Next", save the modified configuration. This should solve the problem.

If the steps shown above don't solve the problem, direct access to the database is necessary. This is officially supported for TOS Classic only. If you need this procedure for Aurora, please contact AERAsec directly.

First, find the Management-ID of the problematic Check Point Management device. This can be done via WebUI (see also here) or via CLI with administrative permissions (e.g. root or using the sudo command). These steps will help:

• # st stat
  This command will deliver the Management ID <id> of the device. It's needed in the next steps.
  
  
• # psql -Upostgres securetrack -c "select certificate_id from management_certificate where mgmt_id =<id>"
  The output should deliver (at least) two certificate IDs (if there is only one, the message would not be shown).
  Example for the output:
  certificate_id
  ------------------
    6
    28
  
  
• Now, the certificate with the lowest id (i.e. the id of the oldest certificate) needs to be deleted. This is done with the command
  # psql -Upostgres securetrack -c "delete from management_certificate where mgmt_id = <id> and certificate_id = 6"
  DELETE 1
  
  
• The corresponding device now needs to be restarted using
  # st restart <id>

This procedure should solve the issue. If not, please contact Tufin Support.

Details

Category: SecureTrack

Last Updated: 06 April 2022

If you use Tufin TOS Classic R21-3 you surely have seen the EOL message on the login screen. 

There might be one or another situation not allowing this message, e.g. if auditors complain about why this message is shown (and you currently cannot upgrade to TOS Aurora because SecureTrack and SecureChange need to run on different systems due to security reasons).

It is possible to remove this EOL message by a script. Just go to the CLI and call this script with root permissions:

[root]# /opt/tufin/securitysuite/scripts/eol_message_disable.sh

From then on, this message isn't shown anymore.
But - please don't forget that TOS Classic still has its EOL at the end of the year 2022 (!)

If you need this message to be shown again, access to the database is necessary. As always, never ever do anything with the database without a current backup!
To turn the message on again, issue this command to alter the field within the corresponding table:

[root]# psql -Upostgres keycloak-db -c "update custom_properties set value='false' where id='eol_message_disabled'"

(this command needs to be typed using one line only)
After having issued this command, the EOL message is turned on again.

Details

Category: SecureTrack

Last Updated: 02 March 2022

Before doing anything with a device, e.g. adding an Interface or restarting the device via CLI, it is necessary to know the SecureTrack Management ID of the device.

If this device is a simple unmanaged Firewall, finding the Management ID is quite easy by navigating to the Device List shown in Menu > Compare (in TOS Aurora: Menu > Reports > Compare Revisions).
A click into this list on the left side and pressing "t" shows the number.

When having a Firewall Management (e.g. Check Point, FortiManager, Panorama...) this list shows the Management only, not the relevant Firewalls.

In this case, the information can be retrieved by going to Menu > Settings > Administration > Licenses (in TOS Aurora: Menu > Settings > Licenses). Scrolling down to the window "Devices", click into the field, and pressing "t" delivers the Management ID of the firewall itself.

In this example, the Management has the ID 285 and the Firewalls have 286 and 287, respectively.

Details

Category: SecureTrack

Last Updated: 03 March 2022

Building the SecureTrack Topology (Interactive Map) so it represents the network reality sometimes is a challenge.

Some improvements can be done manually, e.g. to define a Generic Device. There might be situations, SecureTrack doesn't recognize all routes configured on a monitored device. In this case, one or more routes need to be added manually to SecureTrack Topology by defining Generic Routes.

Today's versions allow to add them in the Interactive Map directly, but also using the CLI is a way to configure Generic Routes. Once integrated into SecureTrack, Generic Routes will be persistent until they are removed manually. So let's have a look at

• Configuration of Generic Routes in the Interactive Map
• Configuration of Generic Routes using the CLI
• Listing and removing Generic Routes from Topology

Configuration of Generic Routes using the Interactive Map

Using one of the recent versions of SecureTrack, a Generic Route can be added directly in the Interactive Map.
To do so, login to SecureTrack with administrative rights and go to
   Menu > Network > Interactive Map (TOS Aurora: Menu > Map)

Then, find the device you want to provide with an additional, generic route. In this example, the Check Point Firewall will get an additional route. To show all routes stored in SecureTrack for this device, right-click and select "show routes".

A new window opens, showing all routes configured for this device.

To add a route, click on the "+" at the top right corner. A new window opens that allows defining a new (generic) route. Here information needs to be provided:

• Destination
  IP-Address and Prefix
• Interface
  optional
• Virtual R&F
  optional
• Next Hop Type
  IP or VR
• Next Hop
  e.g. IP address of the next hop / router

By pressing "Add" the configuration is taken into the window shown below.

In this phase, the route can be deleted by clicking on the dustbin on the right side. The configuration is finished by pressing "Save".
The newly configured route is shown and active in the interactive map after synchronizing the Topology

Please be aware that this Generic Route cannot be deleted via WebUI. To delete a Generic Route access to the CLI is necessary, shown here.

Configuration of Generic Routes using the CLI
(TOS Classic only)

Some administrators prefer using the CLI. If an elder version of SecureTrack is used, the configuration of Generic Routes is possible using the CLI only.
Doing so, the Management ID of the device needs to be known (also called Device ID).
To configure it, a CSV file needs to be prepared. It has to have the following content:

• Destination
  IP-Address
• Mask
  Dotted decimal subnet mask
• Interface
  name of the Interface to be used
• Next Hop
  IP address of the next hop / router
• Next Hop Type
  IP or VR
• VRF
  optional

Here is an example of the content:

# cat /home/tufin-admin/route.csv
10.1.2.0,255.255.255.0,eth1,10.1.1.254,IP,
10.1.3.0,255.255.255.0,eth1,10.1.1.254,IP,

It needs to be considered that the number of fields needs to be always the same. So if a VRF isn't configured, the "," still needs to be in the file.
Besides this, it needs to be known that an import of the file replaces all Generic Routes configured before. So each Generic Route that needs to be configured on the device needs to be included in this file.

The next step is to import the file. This is done by the commands

• cd /usr/local/st
• ./topology_generic_routes -m <DeviceID> -i <file.csv>, e.g.
  ./topology_generic_routes -m 286 -i /home/tufin-admin/routes.csv

The next step is to synchronize SecureTrack Topology. This can be done using the WebUI (see above) or via CLI by the commands

• cd /usr/local/st
• ./topology_graph_builder

After this procedure, the content of the CSV files is shown in the Topology.

Listing and removing Generic Routes from Topology
(TOS Classic only)

If one or more Generic Routes are configured, they can be displayed in the WebUI - but there is no option to remove or alter these routes. To do so, using the CLI is necessary. One option is to use "regular commands", the other is to "hack the database". The second option is not really recommended by Tufin.

To check Generic Routes the easiest way is to check the routing table of the device in the Interactive Map. Here it needs to be considered that there is no difference shown between a regular and a generic route. Checking the Generic Routes via CLI requires knowing the Management ID of the device (the example below refers to 286 and the configuration above).
It is a command to query the database of SecureTrack:

# psql -Upostgres securetrack -c "select * from topology_generic_routes where mgmt_id='286'"
 id | mgmt_id | destination |     mask      | interface_name |  next_hop  | next_hop_type | vrf
----+---------+-------------+---------------+----------------+------------+---------------+-----
 26 |     286 | 10.1.2.0    | 255.255.255.0 | eth1           | 10.1.1.254 | IP            |
 27 |     286 | 10.1.3.0    | 255.255.255.0 | eth1           | 10.1.1.254 | IP            |
(2 rows)

The output shows two Generic Routes that have been added to the device with Management ID 286.

If one or more Generic Routes need to be removed from SecureTrack Topology, this should be done with a CSV file as shown above. An import of a CSV file with Generic Routes always replaces all of them. So if an empty file is imported, all Generic Routes are removed after Topology Sync.

Details

Category: SecureTrack

Last Updated: 04 October 2021

Some messages can be delivered by SecureTrack using syslog. Looking at the WebUI, only a syslog server can be selected. At first glance, it looks as if SecureTrack supports syslog via UDP and the default port only. In the example below, the syslog server has the IP address 10.0.0.100.

Other references, e.g. in "Policy Change Notifications", "SecureTrack Administrative Alerts", and "SecureTrack Audit Trail" only have buttons to "send by syslog".

Many companies don't allow to use syslog via 514/UDP in their networks. At least TCP has to be used. To configure this, open the URL
     https://<IP_SecureTrack>/stcgitest.htm
In the menu select "Edit StConf".

If you follow the link, a short menu opens. Press the button "Fetch Current Conf".

After having done so, the SecureTrack configuration is shown in XML. Now it's necessary to find the section <syslog>

<syslog>
            <syslog_server>127.0.0.1</syslog_server>
            <port>514</port>
            <protocol>udp</protocol>
            <policy_syslog>0</policy_syslog>
            <admin_alerts_syslog>0</admin_alerts_syslog>
            <audit_trail_syslog>1</audit_trail_syslog>           
            <original_syslog_format>1</original_syslog_format>
</syslog>

Here it's possible to change the IP of the server, the protocol as well as the port. To change it, just fill in the required entries - e.g. syslog shall be sent to 10.0.0.100 using 9000/TCP
Please be aware that currently this configuration is not active for policy notifications!

<syslog>
            <syslog_server>10.0.0.100</syslog_server>
            <port>9000</port>
            <protocol>tcp</protocol>
            <policy_syslog>0</policy_syslog>
            <admin_alerts_syslog>0</admin_alerts_syslog>
            <audit_trail_syslog>1</audit_trail_syslog>           
            <original_syslog_format>1</original_syslog_format>
</syslog>

Besides this, you can also turn on the options shown in the top screenshot by changing the "0" to "1". It's not necessary to do the change here, because this can be configured via WebUI also.

To save changes, press the button "Submit New Conf". This button shows up at the bottom of the right page.