Basics

Since some versions of the Tufin Orchestration Suite (TOS) licensing and its enforcement is a bit more flexible as in earlier times. 

If e.g. 20 devices had been licensed some time ago, adding another device resulted in problems. Now, it's more flexible and you have the possibility to add some devices more than you have licensed. This results in the need of "license usage reports" for Tufin to find out the number of licenses used. 

Working with versions up to 24-2, these reports are required, but not really enforced. The license is shown in SecureTrack via Menu > Admin > Administrator > Licenses. At the bottom of the screen License Management the section License Usage is shown.

If the option "Send automatic usage reports" is turned on and the system has Internet access, everything is fine. If it's not turned on or connected to the Internet, a manual download of the usage report is recommended. The resulting JSON file is uploaded to the Tufin Portal then. 

Starting with 25-1, the license usage reports are enforced. The screen shown above has changed to this: 

It's now necessary to upload the license usage report to the Tufin Portal - and to get the confirmation code that will be sent by E-Mail after the upload. After having uploaded the code shown in the E-Mail to TOS, a message is displayed that the licenses used has been verified. 

Not following Tufin's guidelines of today, some restrictions regarding the TOS will occur because no Information about Site Usage Monitoring has been supplied: 

  • Not providing Reports for 6 Months:
    There is no possibility to upgrade TOS

  • Not providing Reports for 12 Months: 
    No further use of TOS is possible, even if a valid subscription has been purchased

So the flexibility regarding licenses requires a mandatory upload of License Usage Reports to the Tufin Portal now. It's done here via My Account > Available Licenses > Manual Usage Upload - or if TOS is connected to the Internet, via the automatic upload process. 

 

 

 

 

There are various status messages when backing up the Tufin Orchestration Suite. One of them is 
     IMPAIRED
If any backup is in this status, it's no longer possible to continue working with the data backup.

The reason for this status is a component in the Kubernetes cluster that is not working correctly when the backup has been created. 

To solve the problem, all backups with this status should first be deleted. Then ensure that the TOS cluster is in a good state. No problems should be reported when calling the “tos status” command. Then the backup will work as desired again.

 

 

 

The message "checker failure" might occur when checking the status of the Tufin Orchestration Suite. 

When looking at Tufin's knowledge base, this message is mentioned as "known bug" that is fixed in R24-1 PHF4.1.0 and R24-2 PHF1.0.0, respectively. If you cannot upgrade or get still the message, this procedure might help: 

  • Find as root the pod that is responsible for this message by using the command
    # kubectl get pods -owide | grep node-exporter
    tos-prometheus-node-exporter-zddqg                    2/2     Running     0 …

  • Check this pod, e.g. if it's running (can be skipped)
    # kubectl describe pod tos-prometheus-node-exporter-zddqg
    ...
  • Restarting the pod helps to return to a normal status
    # kubectl delete pod tos-prometheus-node-exporter-zddqg

You can check the status of this pod by using the first command shown above. Please give the pod to start (and to show a status "ok") about two minutes. Checking "tos status" before will still deliver "checker failure" because the pod is still not running well. 

 

 

 

If users or administrators are not actively working on the command line or WebUI, the user is automatically logged out after a defined period of time.
This time can be configured.

 

Inactivity Timeout for CLI

An individual timeout can be configured for the console as well as for users connecting via SSH. To configure it for all users the file /etc/profile.d/autologout.sh needs to be adjusted. To set it to five minutes of inactivity, the file should look like this:

# set timeout for CLI
TMOUT=300
readonly TMOUT
export TMOUT

This file needs to be executable. To do so, the command

[tufin]# chmod +x /etc/profile.d/autologout.sh

is used. Checking the status is done by calling the variable

[tufin]# echo $TMOUT
300
[tufin]#

Since in TufinOS all users of the CLI are administrators, generally changing it is possible. This is documented in central logging that needs to be monitored.
For sure, setting the timeout individually per user is possible via the file .bash_profile, but not really useful in TufinOS.

If a connection to the command line is established with an SSH client, a separate time period applies here until the automatic inactivity logout. This needs to be adjusted in the /etc/ssh/sshd_config file.

ClientAliveInterval 300
ClientAliveCountMax 0

This configuration enforces a logout after 5 minutes of inactivity. To get it active, the sshd needs to be restarted

[tufin]# systemctl restart sshd

 

Inactivity Timeout for WebUI

The timeout for users of the WebUI needs to be configured also. It's done for SecureTrack by changing the configured parameter. It should first be checked using the CLI of the server.

[tufin]# tos config get -f | grep web.session.inactivityTimeout
  Global                          web.session.inactivityTimeout                   60m  
[tufin]#                       

It's also possible to use another flag

[tufin]# tos config get -p web.session.inactivityTimeout
  SERVICE  PROPERTY                       VALUE  DEFAULT  MESSAGE
  Global   web.session.inactivityTimeout  60m
[tufin]#     

In the case shown above, the timeout is 60 minutes. To change it to e.g. 120 minutes, this command shoult be used:

[tufin]# tos config set -p web.session.inactivityTimeout=120m

Besides the digit, the time period can be chosen - m for minutes, h for hours and d for days.

 

Please consider that this way to change the inactivity timeout works for SecureTrack only!
For SecureChange there is a hardcoded timeout of 30 minutes. Therefore, a changed configuration is disregarded
(Tufin SR[00134598])

 

 

 

 

A vulnerability has been found in TOS Aurora between TOS 20-2 PGA and TOS 23-2 PGA. Details have been published in the Tufin Portal (Auth required):
   https://portal.tufin.com/s/SecurityAdvisories/a86Tt000000006TIAQ/sa00009
Tufin points out that access to one API might be possible without authentication.
This issue is fixed in R23-2 PHF1.0.0, R23-1 PHF3.1.0, and R22-2 PHF4.1.0, respectively. For earlier versions it's recommended to upgrade to a supported one.

 

 

 

Many thanks to Tufin for awarding AERAsec at the Annual Partner Summit as

Tufin 2022 Best SDP+ Partner of the Year for the EMEA region

After more than 15 years of successful cooperation with Tufin, the AERAsec team is proud to receive this award.

 

 

 

 

Page 1 of 3