Sometimes it's neccessary to improve SecureTrack Topology. Reasons might be islands in the topology, the integration of unsupported devices or if devices don't support every option, e.g. VPN. In this case configuring "generic" things help to get the "real topology".

IMPORTANT - before doing steps mentioned below, be sure to have a current backup of your SecureTrack server!

Let's consider the situation that there is a supported device and a generic device - and that a VPN is needed between these two devices. In the first step the supported device and the generic device don't have any connection between them.

The problem is: There has been no VPN detected between the devices R80_lab and VPN_Router. So this VPN needs to be configured manually.
Before configuring anything, some data need to be collected:

  • Type of the VPN devices
    • m - the device is monitored by SecureTrack
    • g - the device is a generic device that has been added manually to topology
  • Device ID of the VPN device. They can be found out in these ways:
    • m - monitored device
      • from CLI issue "st stat" and find the device in the list, e.g.
        MANAGEMENT          IP              ID    TYPE                  PID   LICENSE        STATUS
        R80_lab             10.0.0.1        285   SmartCenter       10917     valid         Connected
        In this case, the device ID is 285
      • from WebUI > Menu > Compare
        find the device in the left tree and press t to get the device ID
    • g - generic device
      • from data base directly, using CLI:
        [root@TufinOS ~]# psql securetrack -Upostgres -c "select * from topology_generic_devices"
         id | customer_id |       name
        ----+-------------+------------------
          4 |           1 | CP-Remote
        14 |           1 | VPN_Router
        (2 rows)
        [root@TufinOS ~]#
        In this example, the device ID is 14
  • Name of the interface where the VPN is configured on this device
  • Source IP address of the tunnel (not necessarily the IP address of the interface)
  • Destination IP address of the tunnel (not necessarily the IP address of the interface)
  • Name of the VPN (any name can be choosen)

After having collected all information, the generic VPN can be configured via WebUI:
https://<IP_SecureTrack>/tools

The next step is to fill in the parameters collected above. This example configures a VPN between a monitored device and a generic device for both directions.
Syntax: <device_type>,<device_id>,<interface_name>,<tunnel_source_ip>,<tunnel_destination_ip>,<vpn_name>
No spaces are allowed between the entries.

Configuring a VPN in both directions using these parameters

  • Device 1 is monitored by SecureTrack, ID 285, VPN uses Interface eth2, Source IP 10.3.62.227, Destination IP 112.12.12.12, name is MyVPN
  • Device 2 is a generic device, ID 14, VPN uses Interface interface1, Source IP 112.12.12.12, Destination IP 10.3.62.227, name is MyVPN

results in these two lines that need to be filled in:

m,285,eth2,10.3.62.227,112.12.12.12,MyVPN
g,14,interface1,112.12.12.12,10.3.62.227,MyVPN

 

It's possible to have many lines at once, so different generic VPN can be configured simultaneous. If all data are entered, the configuration is saved by pressing the "Submit" button.

The next step is to synchronize the topology to get this new information into it. After this, a refresh is necessary so the new topology is displayed:

The VPN is also "used" in the Topology, as it can be seen in a path:

 

To get an overview of generic VPN configured, it's necessary to use a data base query via CLI:

 [root@TufinOS ~]# psql securetrack -Upostgres -c "select * from topology_generic_vpn_connections"
 id | is_generic | device_id | interface_name | tunnel_source_ip_addr | tunnel_dest_ip_addr | vpn_name
----+------------+-----------+----------------+-----------------------+---------------------+----------
  9 | f          |       285 | eth2           | 10.3.62.227          | 112.12.12.12        | MyVPN
 10 | t         |         14 | interface1   | 112.12.12.12         | 10.3.62.227         | MyVPN
(2 rows)
[root@TufinOS ~]#

To delete a generic VPN, the ID of the VPN is needed. The command to remove the VPN is (example for id 10):

[root@TufinOS ~]# psql securetrack -Upostgres -c "delete from topology_generic_vpn_connections where id=10"
DELETE 1
[root@TufinOS ~]#

Issuing the command above will show that only the VPN with the ID 9 is left.

 

 

 

 

 

When F5 devices are monitored with Tufin SecureTrack, every part of the configuration can be found here (except ACLs).
It might happen that in SecureTrack > Menu > Settings > Administration > Status the status sign is yellow, stating "Error: Wrong arguments". At the first glance, there seems to be a problem regarding authentication or version of F5. But this isn't necessarily so complicated.

Looking at the Client Log in /var/log/st for example this information can be found:

FAULT: 14713 20191221 08:24:06.041 what() -> Error occurred when pulling configuration from the device: Wrong arguments
"send_error "\n$expect_out(buffer)\n""
send_error "\nsent username\n"
send_error "\nsent username\n"
11255 20191221 08:24:05.030 Error occurred when pulling configuration from the device: Wrong arguments
FAULT: 11255 20191221 08:24:05.031 what() -> Error occurred when pulling configuration from the device: Wrong arguments

If you find the error mentioned above, just check the connection. Even if it isn't obvious, a connection time out might have occurred.
"Wrong arguments" is also displayed if there is no ssh connection possible between SecureTrack Server and F5.

 

 

 

When upgrading Check Point Management, MDS or CMA from R77.x to R80.x it seems quite easy to upgrade it in SecureTrack, too. Just go to Menu > Settings > Monitoring and select the device that has been upgraded. The Menu on the right side shows the option "Upgrade to R80", you select it and provide the credentials for the API user at the Check Point Management. After that, the device monitoring has been changed to R80 and everything runs fine.

 

Problem

What happens if "st stat" or Menu > Admininstration > Status shows an error:

myDevice        10.1.1.1  14   CMA  1001   valid        Error: Upgrade device to R80 in Settings > Manage Devices > Monitored Devices

The situation seems a little bit confusing - the upgrade has been done in Check Point as well as Tufin SecureTrack, but the status shows an error as if the Management Server has not been upgraded in SecureTrack.

 

Reason for this error

The reason for this error is a change of the management type in the data base - and the change has not taken place in the data base. This is not the "normal way", but it might happen that the change is not recognized in SecureTrack. The differences are:

SmartCenter R77.x is referred as cp_smrt_cntr
SmartCenter R80.x is referred as cp_smc_r80plus

CMA R77.x is referred as cp_cma
CMA R80.x is referred as cp_domain_r80plus

 

Solution

First - as every time you work on the data base: Perform a backup (!)
For a Check Point CMA the necessary next procedure looks like this:

  • Check the ID of the device using "st stat". This example uses the Management ID 14
  • Check the current status of the device:
    [root@TufinOS]# psql -Upostgres securetrack -xc "select cp_type from managements where management_id=14"
    -[ RECORD 1 ]---
    cp_type | cp_cma
    [root@TufinOS ~]
  • Update the variable in the data base and re-check the status
    [root@TufinOS ~]# psql -Upostgres securetrack -xc "update managements set cp_type='cp_domain_r80plus' where management_id=14"
    UPDATE 1
    [root@TufinOS ~]# psql -Upostgres securetrack -xc "select cp_type from managements where management_id=14"
    -[ RECORD 1 ]--------------
    cp_type | cp_domain_r80plus
    [root@TufinOS ~]
  • Restart the monitored device
    [root@TufinOS~]# st restart 14
    Stopping SecureTrack process for server myDevice - 10.1.1.1 (Id: 14)
    SecureTrack process stopped for server 10.1.1.1 (Id: 14)
    SecureTrack for myDevice - 10.1.1.1 (Id: 14) was started successfully
    [root@TufinOS ~]

 

After some seconds the status should have been changed - this can be checked either "st stat" or the WebUI.
The error shown above should not be shown any more. If other errors are shown, you need to continue troubleshooting. Maybe these links help:
https://www.tufin.club/index.php/24-securetrack/52-check-point-api-client-error
https://www.tufin.club/index.php/24-securetrack/73-check-point-api-client-error-part-2

 

 

 

 

In some cases it's necessary to change the IP address of the SecureTrack Server. Some facts need to be considered before. The change itself consists of two parts - changing the IP address of the system as well as changing the IP in the SecureTrack Server.

Things to be considered before

Esp. in complex scenarios, some facts need to be considered before changing the IP address of SecureTrack, e.g.

  • Check and configuration of IP addresses/netmasks for all NIC (see below), incl. update of file /etc/hosts
  • Check and configuration of routes

  • Check if switch configuration is affected (e.g. VLAN,  Port Security...)
  • Check if there are changes necessary for using DNS, NTP, syslog etc.
  • Check if changes are needed at other servers, e.g. SecureChange, Authentication, E-Mail, LDAP
  • Check if firewall rules need to be changed for communication between SecureTrack and SecureChange (and vice versa), SecureTrack and monitored devices...
  • If Check Poiint is monitored: Check if API access is still possible after changing the IP address, modification of OPSEC Application is needed
  • Other devices need to be configured to send syslog data to the new IP address
  • If Access Control is configured, access from the new IP address needs to be allowed, e.g. for downloading a new revision
  • ...

Don't forget to update the documentation / operation manual

Changing the IP address of TufinOS

Since TufinOS is based on CentOS, changing the IP address of an interface (eth0) is done by editing the file

/etc/sysconfig/network-scripts/ifcfg-eth0

In this file the parameters IPADDR and NETMASK need to be adapted. If necessary, changing GATEWAY might necessary also. To make the changes effective, a restart of the network component (service network restart) or a reboot of the system is necessary. After this successful change SecureTrack Server has the other IP address.

Changing the IP address in SecureTrack

Before making any change using the command psql, create a backup of your configuration!

If only the IP address of the system is changed, SecureTrack shows the "old" IP address in the WebUI. Everything works fine, but this address should also be changed.
Btw., the same issue happens if a backup is restored to a machine with a different IP address.
In Menu > Settings > Administration > Status, the "old" IP address is 10.100.200.206 is shown. It should be the "new" IP address 10.0.0.20.

To change the IP address it's necessary to connect to the CLI with administrative rights.
First thing to do is to find the ID of the SecureTrack Server.

[root] psql -Upostgres securetrack -c "select * from st_servers"
id |       ip       | display_name | services_stat |   services_last_update    | disk_usage | server_type | software_version | cgi_stat |      cgi_last_success
----+----------------+--------------+---------------+---------------------------+------------+-------------+------------------+----------+----------------------------
  1 | 10.100.200.206 | TufinOS      | ok            | 2019-09-05 15:25:13.32552 |         15 | standalone  |                  | up       | 2019-07-15 10:57:36.657694
(1 row)
[root]

The next step is to change the IP address of this server.

[root] psql -Upostgres securetrack -c "update st_servers set ip='10.0.0.20' where id='1'"
UPDATE 1
[root]

Now it can be checked that also in the data base the IP address is changed:

[root] psql -Upostgres securetrack -c "select * from st_servers"
id |       ip       | display_name | services_stat |   services_last_update    | disk_usage | server_type | software_version | cgi_stat |      cgi_last_success
----+----------------+--------------+---------------+---------------------------+------------+-------------+------------------+----------+----------------------------
  1 | 10.0.0.20 | TufinOS      | ok            | 2019-09-05 15:25:13.32552 |         15 | standalone  |                  | up       | 2019-07-15 10:57:36.657694
(1 row)
[root]

After a new login at the WebUI also here the correct IP address is shown.

 

 

 

 

 

 

 

 

When setting up a USP, first of all the networks need to be assigned to Zones. This is done via Menu > Network > Zones. Here Zones and corresponding networks can be edited and/or imported.

In many cases a "joker" is needed to fetch all IP addresses which are not mentioned in a Zone. Since longer time the default Zone "Internet" is available here. It matches for all official IP addresses not being in another Zone.
Big enterprises have possibly also private IP addresses (RFC 1918) they don't trust. So here another "joker" is necessary. Current versions of SecureTrack allow to use:

  • Internet
    Zone of all official IP addresses that are not belonging to any other Zone in SecureTrack

  • Unassociated Networks
    Zone of all private IP addresses that are not belonging to any other Zone in SecureTrack

So it's quite easy to set up a USP that matches for all IP addresses (official as well as private). It might look like e.g.

In this example, allowed and forbidden traffic between the Zones "Internal", "DMZ", "Internet", and "Unassociated Networks" is described, matching for all (official and private) IP addresses.

 

 

 

 

What is Policy Analysis?

Since a long time SecureTrack offers Policy Analysis to check the way a packet takes through the topology. Besides the corresponding firewalls and routers, it's also shown if the packet is allowed to pass or not. Queries can be saved and run later. So it's possible to have many queries configured and to run them when needed, e.g. when a change in the Topology has taken place. As shown below, queries as well as results are quite easy to understand.

 

Policy Analysis in TOS 19-1 - upgrade

When upgrading to TOS 19-1 the Policy Analysis is still there and can be used. Additionally, the "Interactive Map" allows now to save queries.

 Policy Analysis in TOS 19-1 - new installation

When TOS 19-1 is not upgraded but newly installed, Policy Analysis can't be found in the menu any more. This points out, that Tufin is going to remove the Policy Analysis and to move the functionality to the "Interactive Map". If Policy Analysis is needed in a new installation of 19-1 it can be activated via stconf:

  • Using the WebUI
    Log in to SecureTrack and open https://<IP_of_ST>/stcgitest.htm
    Here you find the section Configuration > Edit StConf > Fetch Current Conf

    When clicking the button, the configuration is shown. Browse down to the line that refers <show_legacy_pa>
    Change <show_legacy_pa>0</show_legacy_pa> to <show_legacy_pa>1</show_legacy_pa>
    and don't forget to press the button "Submit New Conf"
    When you log in again, the menu shows Policy Analysis as wanted.

Even if you can use Policy Analysis in 19-1, please be aware that this feature will probably removed in one of the next versions.
Currently there is no way known, how to migrate queries of Policy Analysis to queries of Interactive Map.
If you know a way, please send me a note - thanks.