Basics

For administration of Tufin SecureTrack and Tufin SecureChange you need at least one administrative account. This account must not be lost and the password must not be forgotten. If it is forgotten, there is a way to reset the admin account if CLI access is possible as root.

SecureChange / SecureApp

It's not possible to create a new user, so a reset of the user "admin" is done. Resetting the admin account requires access to the correct pod in the Kubernetes Cluster. You need to enter the pod, then use a command and leave the pod afterwards: 

# kubectl exec -it deploy/sc-server -- bash
pod$> scw reset-admin
pod$> exit
# 

This procedure resets the admin account to the password "admin", so access with admin/admin ist possible. For sure, the password admin needs to be changed at the next login.

SecureTrack

The procedure shown for SecureChange doesn't work for SecureTrack. But there is a command that will allow you to define a new local (administrative) user. As before, you need to configure it via the correct pod. After calling the command, the needed information is requested by the system. 

# kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r add_st_admin_user
Username: <user>
Password: <pass>
Confirm Password: <pass>
Admin user <user> is added.
#

After having finished the command, a new user with permissions "administrator" is known in SecureTrack. As usual, the system requires a password change at the first login. 
It's not reasonable to add a person with the permissions of "user" to the system, because it's possible with the newly created admin user after login. 

 

 

Usually, the Tufin Orchestration Suite (TOS) is going to be installed on TufinOS. In virtualized environments, TufinOS requires VMware ESXi as basis. 
Some companies don't continue using VMware, they are switching to Proxmox. This environment is not supported by TufinOS, so the installation of Rocky Linux is necessary to have an OS for TOS. This combination is supported by Tufin.

In Rocky Linux, the sudo environment is not enforced as it is when installing TufinOS. This is a problem if a Tufin Extension like e.g. Rule Lifecycle Mangement (RLM) is going to be installed. 
The routine installing the Extension states errors like e.g. "kubectl - command not found" or "tos - command not found" - even if TOS is installed and working correctly, i.e. these commands work when using them at the command line as root. 

The reason for this behavior: using "sudo" is hardcoded in the code of the Extensions. If it's not configured, the script doesn't work.

If the installation is done at the console with the permissions of root, editing the Extension might help. 
Open the Extension using e.g. vi / vim and remove all "sudo" references in commands. So if there is the command
   "sudo kubectl" 
replace it with a simple "kubectl". Doing the same procedure for "sudo tos" and saving the file allows an installation without this kind of error. 

 

 

 

The Tufin Orchestration Suite (TOS) provides the option to use a multi-domain management in SecureTrack as well as in SecureChange. This is useful e.g. when there are several companies or parts of a big enterprise using the same TOS instance. Some hints about it below. 

SecureTrack

Introducing Domains in SecureTrack is quite easy. In SecureTrack you go in the menu to "Monitoring - Domains" to define one or more domains. After this, managed devices can be assigned to different domains. Users as well as administators can be restricted to see only domains they are allowed to. 



Hints: 

  • Domains can be changed later, as well as the membership of a device. 
  • Users / Administrators might get their permissions per domain. 
  • Users cannot see the Map / Topology in multi-domain mode, even if they have the permission to view all devices in all domains (!)
    If this is needed, the multi-domain mode needs to be switched back to single-domain mode
    • Remove all devices from any domain, except default domain
    • Go to https://<securetrackVIP>/stcgitest.htm
    • Fetch the configuration using the link "Configuration - EditStConf - Fetch Current Conf"
    • Change the parameter <is_mssp>1</is_mssp> to <is_mssp>0</is_mssp>
    • Save the change by pressing "Submit New Conf" at the bottom of the page

SecureChange

If you have configured domains in SecureTrack, there is an option to use them in SecureChange, too. There are two options for domains in SecureChange that can be configured via the menu "Settings - Multi Domains". Please read the text below before clicking an option (!)

  • Segregated domains
    Users are restricted to see only devices ot the domain(s) as configured in SecureTrack. In SecureChange there are additional restrictions: Ticket Handlers have to be in the same domain as the Requester who created the ticket - also only targets and objects of this domain can be seen. Addtionally, Target Suggestion, Designer, and Verifier can analyze access requests only within this domain. 
  • Interconnected domains
    The restrictions shown above are not present, so Target Suggestion, Designer, and Verifier to analyze access requests across domains     (same as the default "none"). In this configuration, the "Clone Network Object Policy Workflow" is not supported. 

When considering to configure domains in SecureChange, lease beware of the fact that a change of this selection is not possible (!)

 

 

 

 

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