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.

 

 

 

 

Using Tufin SecureChange, there are some options for Decommission. Sometimes it is not clear, what is meant by the different workflow types. So here you find a brief description.

 

Access Request

When having an Access Request Workflow, new access "from - to" can be requested if the action is "accept".
Using the other option "remove" allows to decommission access "from - to".

In the example shown above, the access from 10.1.1.0/24 to 10.2.2.0/24 using the protocol https is no more needed. Because it is an Access Request ticket, many IP addresses can be used here. Besides this, more than one Access Request can be defined within one ticket. The requester does not need to care which firewalls are involved and which firewall rules are affected. So the removal of "access" might affect many firewalls and rules, respectively.

 

Rule Decommission

A ticket for a Rule Decommission Workflow always starts in Tufin SecureTrack, not in SecureChange. The ticket is opened for a specific rule configured on one firewall device. This must not be mixed up with an Access Request.
Please consider the configuration requirements, e.g. the SecureTrack user needs to be authorized to open such a ticket in SecureChange.
First, the rule is selected in the Rule Viewer.

Clicking on the button on the right side opens a menu where the option "Decommission rule" can be selected. The next step is to provide a subject for a ticket and select the workflow. Now, a new ticket is created in SecureChange, allowing to check and submit the request.

 

 Decommission of network objects

A third option for decommissioning is the use of a Decommission network object Workflow. This kind of workflow is used to remove network objects from rules and groups. So after having the ticket closed, the selected object is no more in use.
Hint: If an object that shall be removed is "last in cell", SecureChange Designer recommends removing the whole rule. This is because if the "last in cell" object is removed, the usual firewall configuration replaces the lost object with "any" by default.

The network, server, or address range needs to be provided manually.
Please regard that the object is not removed from the Firewall Management. It's still there, but unused.

 

 

 

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

    Best Support Partner 2021 in Central EMEA

After 15 years of successful cooperation, we are proud to get this award, together with warm words from Pierre Visel (Vice President Central and Eastern Europe).

 

 

 

 

 

Tufin Best Support Partner 2021 in Central EMEA
Tufin Best Support Partner 2021 in Central EMEA

After the first vulnerability in Apache Log4j has been found and is discussed on the Internet, some more have been identified. All together, until now three vulnerabilities have been found. They are described in CVE-2021-44288 (resolved in Log4j 2.15), CVE-2021-45046 (resolved in Log4j 2.16), and CVE-2021-45105 (resolved in Log4j 2.17).

Tufin has checked whether Tufin Orchestration Suite is vulnerable or not.
The latest status can be found here: https://forum.tufin.com/support/kc/latest/Content/Suite/CVE-2021-44228.htm?cshid=CVE-2021-44228.
Some official patches are available, i.e. for RTOS 19.3 and above. If you are currently using R19-2 or earlier, please upgrade to a supported version of TOS.

It is recommended to check the latest status (Tufin Portal > Security Advisories) and to subscribe to Tufin's mailing list.
Please check also the Tufin Portal also for additional information.