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.

 

 

 

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 very 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 e.g. for R80), the firewall running R81 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, the authentication of SNMPv3 users with SHA1 is not supported any more. Only SHA256 and SHA512 are supported by default. To solve this issue, some additional steps are described in CheckMates. So the complete integration of a Check Point firewall into SecureTrack includes these steps:

  • 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
    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) or the WebUI
    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...
    r81_expert> set snmp usm user securetrack security-level authPriv auth-pass-phrase password123 privacy-pass-phrase password123
    r81_expert>
    and check the authentication by e.g. this command:
    r81_expert> snmpwalk -v 3 -l authPriv -u securetrack -a SHA -A password123 -x AES -X password123 127.0.0.1 HOST-RESOURCES-MIB::hrSystemUptime.0
    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 user name 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. 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

 

 

 

 

 

 

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

 

 

 

 

 

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.