- Details
- Category: SecureTrack
Sometimes there are requirements regarding redundancy and high availability. In most cases, firewalls are configured to act as a cluster. So if one cluster member fails, packets are still possible to pass the firewall. In this case, the firewall cluster has a virtual IP address that is addressed by the packets.
Check Point Management HA
Check Point offers not only firewall clusters but also redundant management. In this case, there are two management servers running as active and standby, respectively. The administrator connects to the active management server and makes changes to the firewall configuration. These changes are synchronized to the standby management server. If the active management server fails, the administrator can connect to the other management server to continue the work and install the policy on the firewalls. Regarding this situation, there are two different IP addresses the administrator connects to; no virtual cluster IP address is in use.
Management HA and SecureTrack
Tufin has supported Check Point Management HA for many years. After the first server is defined in Tufin SecureTrack, the second server is imported using the WebUI via "/tools". This is described in the Tufin Portal. Everything works as expected if only rule changes are tracked.
Restrictions of SecureTrack regarding rule metadata
Today's SecureTrack works with metadata for each rule. These metadata include further information about the rule, e.g. "last hit", "last modification date", "rule owner", etc. Many companies need information stored in the metadata, e.g. reference to a "ticket number" in SecureChange that is related to this rule or a "rule recertification date". This date can be set with e.g. the Rule Lifecycle Management (RLM) tool. Recertification is often required esp. for companies working in the finance sector.
When metadata are created or modified, they are written to the corresponding rule on the active Check Point Management server - and these data are not synchronized (by design). So if e.g. rule 2 has been certified until 2024, this information is stored on the active server only. After a failover the other management server becomes active - and rule 2 is not certified here. The same situation occurs if a rule is modified: Ticket information is stored on the active server only, and is not synchronized to the standby server.
Lesson Learned
Tufin SecureTrack doesn't support "modern features" like rule recertification or ticket information per rule if Check Point Management HA is deployed.
Update 26.11.2023:
AERAsec has developed a procedure to circumvent the restrictions of SecureTrack regarding rule metadata when using Check Point Management HA.
- Details
- Category: SecureTrack
SecureTrack has two kinds of users: "Administrator" and "User".
An "Administrator" has access to every part of SecureTrack, also to SecureTrack Topology. The permissions of this user cannot be restricted.
In TOS Classic a "User" had the possibility to access SecureTrack Topology. The requirement was that this user has permission to view "all devices". In this case, Topolgy has been shown and could be used. For sure, when a new device has been added, the permission of the user needed to be updated (because otherwise the requirement for accessing the Topology was not fulfilled).
The access to the Topology for users has been classified by Tufin as a "security flaw". Therefore, in TOS Aurora there is no possibility for a "User" to access the Topology. If this access is needed, the permissions need to be extended to "Administrator" (with all consequences). If only some information is needed, a user is able to use the API for calling specific information from the Topology. Examples of this API access are shown here:
https://forum.tufin.com/support/kc/rest-api/R22-2P/securetrack/apidoc/#!/Network_Topology/getPathCalc
https://forum.tufin.com/support/kc/rest-api/R22-2P/securetrack/apidoc/#!/Network_Topology/getPathCalcImage
- Details
- Category: SecureTrack
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
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
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.
- You are here:
-
Home
-
data privacy statement
- SecureTrack