www.tufin.club

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.

After upgrading to R23-1 it might happen that configured workflows have "less steps" as expected (e.g. 7 steps instead of 21). While the WebUI shows the first steps only, the XML output via API is fine and every step is still configured.

Tufin support has confirmed this behavior as a bug that will be corrected in R23-2 PGA2.00 which will be published on December, 20th. Until then, it's recommended to use the zoom function of the browser.

Tufin has released TOS R23-2, the second version of the Tufin Orchestration Suite of 2023.
TOS R23-2 is available as GA and can be downloaded from the Tufin Portal (authentication required).
Some improvements of TOS Aurora R23-2:

Change Monitoring, Automation, and Orchestration

• SecureChange (Palo Alto Networks)
  Automation for Panorama URL Categories allows design and provisioning for URL Categories also.
  
  
• SecureChange
  Rules from different devices can be added to a single ticket using the Rule Viewer. This is available for Rule Decommission, Rule Modification, and Rule Recertification tickets.
  
  
• SecureChange
  Extension Apps have been added to the SecureChange menu.
  
  
• SecureChange
  A new page for "My Requests" has been integrated into SecureChange.
  
  
• SecureTrack
  Topology and Automation now support Internet Objects, that can be directly inserted into Devices by Check Point and Forcepoint.
  
  
• SecureCloud
  SecureCloud now displays a risk assessment for assets exposed to the internet based on the data returned from the firewalls monitored by SecureTrack.
  
  
• SecureTrack
  The Rule Viewer now offers the option to view the change history of a rule by the new tab "Rule History".

Deployment

• License
  In order to monitor license consumption and accurate auditing, a mechanism for tracking the license usage is introduced. The licenses of SecureTrack+, SecurecChange+, and Enterprise can be sent automatically to Tufin. More information here.
  
  
• License
  The License Management in SecureTrack has a new user interface that can be accessed by SecureTrack Super Administrators.
  
  
• Appliances
  New appliances for TOS are available now. They come pre-installed with TufinOS and TOS Aurora. There are two different appliances available: T-820 and T-1220.
  
  
• Operating Systems
  In June 2024 CentOS 7 as well as TufinOS 3 are going to be End-of-Life. TufinOS 4 and Red Hat Enterprise Linux / Rocky Linux 8.6 are the successors. They are available for on-premise installations, cloud deployments require Rocky Linux 8.6.
  
  
• Google Cloud
  Tufin now supports high availability for GCP over three availability zones.

Devices and Platforms

• AWS
  VMware NSX-T on AWS (VMware cloud) is supported for TOS, providing the same features as with on-prem NSX deployments.
  
  
• Azure
  Network Security Groups (NSG) can be used as targets in SecureChange Access Requests. The verifier is now able to check automatically implemented policies.
  
  
• Azure
  The deployment of TOS in Microsoft Azure is supported for very large installations also. Sizing requires help from Tufin.
  
  
• Check Point
  The management of Check Point devices can be done in the cloud using Check Point Smart-1 Cloud. This is supported by Tufin now.
  
  
• Cisco
  Cisco Viptela is now supported in SecureTrack Topology, including OMP routes as well as SD-WAN interfaces and SD-WAN labels.
  
  
• Cisco
  The Designer now can automatically create rules with custom logging for Cisco ASA devices.
  
  
• Palo Alto Networks
  Tufiin is now able to monitor Palo Alto Networks Prisma Access Policies managed by Panorama devices.
  
  

GraphQL API

• Enhancements for SecureTrack
  • A new query returns all changes made in a selected revision that affect a specific rule.
  • A new query returns a list of revisions in a specific time frame that affects a selected rule.

REST API

• Enhancements for SecureTrack
  • NAT information can be retrieved per revision, not only for the last revision.
  • Dynamic Topology data can be retrieved from a specific device tree. This subset can be refreshed without the need of a Topology "Full Sync".
    
    
• Enhancements for SecureChange
  • URL Category Zones can be set and get for path calculation and target selection.
  • It is possible to run "commit now" for a specific device in a SecureChange ticket for Check Point R8x, FortiManager, and Panorama.
    
    
• Enhancements for SecureApp
  • It is possible to search network objects not only by their name but also by IP address, subnet, and comment.

Further improvements, as well as corrections, are included in R23-2.
The latest version of the Tufin Orchestration Suite can be found at the Tufin Portal: https://portal.tufin.com

It is possible to set an Expiration Date within e.g. an Access Request Ticket in Tufin SecureChange. This Expiration Date has a default value of 180 days, i.e. half a year. To increase this time limit, access to the pod and database is necessary. The Expiration Date can be set up to a limit of 10 years. This is useful for rules that shall be valid "forever".

Please be aware that users might not be able to work with SecureChange due to a (necessary) restart of the pod

To change the maximum Expiration Date, these steps are recommended:

• Check the currently configured time for the Expiration Date:
  # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration"
  A list of value is shown. Look for an entry like this:
  

  -[ RECORD 1 ]-+------------------------------------

  id            | 10

  key           | expirationField.maxExpirationPeriod

  value         | 180

  default_value | 180

  If this key doesn't show up, it's useful to filter for the key using the command
  # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration where key='expirationField.maxExpirationPeriod'"
  At least then the record shown above will be displayed, the relevant ID can be found out this way.
  
  
• If the record has been found, the value for the maximal Expiration Date can be set with the command
  # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "update general_configuration set value='36000' where id='10'"
  The ID needs to be adapted to the result of the step before. In this example, the time is set to approximately 10 years which is the maximum time supported by Tufin
  
  
• After having set the time it's useful to check the entry in the database again
  # sudo kubectl exec -it stolon-keeper-0 -- psql  -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration where id='10'"
  Again, the ID is 10, as shown in the example above.
  

  -[ RECORD 1 ]-+------------------------------------

  id            | 10

  key           | expirationField.maxExpirationPeriod

  value         | 3600

  default_value | 180
  
  

• In TOS Classic it was necessary to restart the Tomcat Server. In TOS Aurora, the pod needs to be deleted. Once done this, the pod will start again - using the newly set value.
  First, the exact name of the pod needs to be found using the command
  # sudo kubectl get pods | grep sc-server
  

  sc-server-a76994ab9-98236 3/3 Running 0 19m

  (the number shown with the pod varies, so here it's an example only). Once found, this pod should be deleted using
  # sudo kubectl delete pod sc-server-a76994ab9-98236
  
  
• It's useful to check the restart and watch the pod coming up again
  # sudo kubectl get pods | grep sc-server
  After the successful restart of the pod, It's possible to take the new (maximum) value within tickets.