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.

 

 

 

 

 

 

 

What happens with USP if a Network is not member of a SecureTrack Zone?

Having a Unified Security Policy (USP) matrix defined requires zones configured in SecureTrack Network Topology. Networks are assigned to these zones, which are referenced in a USP. In this matrix, traffic can be allowed or forbidden explicitely. The compliance of a connection with USP is tested in SecureTrack Violations as well as SecureChange Risk checks and SecureApp Compliance checks.

Besides individually configured zones a zone called Internet is available by default. This zone includes all networks that are not configured to be in other zones and that are not defined as Private Networks (RFC 1918). So in many cases this Internet Zone can be used to forbid "all other traffic" in the USP. So all official networks which aren't assigned to an individually configured zone will result in "RISK".

What happens if a private network like e.g. 192.168.1.0/24 isn't assigned to a zone, but used as SRC or DST?

 

Behaviour before R18-2 HF1

Private networks not assigned to a zone referenced in the USP are not mentioned here, so they are not tested - and therefore such a network in SRC or DST will not lead to "RISK". Result of USP check is "no risk". 

 

Behaviour since R18-2 HF1

Tufin has introduced a new row to configure this behaviour. This can be done quite easily: 

  • Navigate to https://<SecureTrackHost>/stcgitest.htm
    to be redirected to https://<SecureTrackHost>/securetrack/admin/stcgitest.htm
  • Find Edit StConf and follow the link to Edit StConf

  • Press the button to Fetch Current Conf

  • Now search for this entry and modify the severity as needed

<unmatched_internal_address_risk_severity>0</unmatched_internal_address_risk_severity>

  • When ready, safe the configuration using the button Submit New Conf

You can select the Severity by changing the number in the middle of the expression. Possible options are

0 - No Risk (Default, same behaviour as before R18-2 HF1)
1 - Severity low
2 - Severity medium
3 - Severity high
4 - Severity critical

Based on this information a USP can be configured in a way that also "unknown" private networks lead to "RISK"

 

 

Tufin SecureTrack supports Check Point R80.x since a longer time now. Using a Check Point Management R80.20 may result in a problem.

A Check Point Management R80.20 can be connected to SecureTrack without a problem - at the first glance. All checks regarding OPSEC and Management API are ok, the device is shown in green pointing out that everything is ok.

But getting a revision seems not possible. Everything is green, but no revision shows up. In the corresponding log the statement "Checkpoint error code: http_forbidden" can be found.

This problem can be solved by using the correct version of Tufin SecureTrack.
Check Point R80.20 is supported from TOS R18-2 HF 1.2 and TOS R18-3 GA on (not by RC).
Upgrading to one of these versions solve the problem.

 

 

 

 

Some months ago, an article about potential problems connecting SecureTrack to a Check Point R80 Management Server has been published here. Most of the points are still true - except the option
   Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity
is now also testing the API connect to the Check Point Management Server (e.g. in R18-3).

As pointed out in Tufin Knowledge Center #10413, one reason for an API client error is the API itself. At the CLI of this machine an "expert" user can (and should) check the status of the api to be sure it's up and running. Tufin points out the resolution to allow access to the API from "All IP addresses", which is correct.

It might happen that access isn't possible even if the change has been configured, published via SmartConsole and the API has been restarted using CLI. Assuming that access to port 443/tcp is granted, another reason might be possible. In our lab this problem has been found using Check Point R80.20 with SecureTrack R18-3. It might happen in your environment also, but not necessarily.

Even if the change of allowed IP addresses has been published and the API has been restarted, it might not be active for the API. This can be checked by an "expert" user

[Expert@SMS]# api status
API Settings:
---------------------
Accessibility:                      Require ip 127.0.0.1
Automatic Start:                  Enabled

So in this case, the change hasn't become active and the API allows access from 127.0.0.1 only. This might also not change when the API is restarted again. In this case, try the command

[Expert@SMS]# api reconf
API reconfigured successfully

[Expert@SMS]# api status
API Settings:
---------------------
Accessibility:                      Require all granted
Automatic Start:                  Enabled

After the completion of the first command, the change is active and SecureTrack can access the API.