www.tufin.club

Details
Category: Admin Management

Since TOS Aurora 22-1, there is an option to use a Single Sign On (SSO) for SecureTrack and SecureChange / SecureApp. In new installations, this feature is enabled by default, but in upgraded installations, this feature needs to be enabled manually. This is quite easy, following Tufin Knowledge Base. If SSO is turned on, there is no additional authentication required if a user changes from e.g. SecureTrack to SecureChange.

Enable SSO

To activate SSO access to the command line is necessary. Additionally, administrative permissions are needed (e.g. root or the use of sudo). This command enables SSO:

[Tufin]$ sudo tos config set -p tos.sso.enabled=true

After this action, SSO is active and the login screen shows "Tufin Orchestration Suite".

Sometimes it's useful, to disable SSO (see below).

Disable SSO

Disabling the optional SSO is done using this command with administrative permissions at the CLI (e.g. root or the use of sudo):

[Tufin]$ sudo tos config set -p tos.sso.enabled=false

After this command, a separate login screen is shown for SecureTrack and/or SecureChange - as it has been before for many years.

 

Items to consider when using SSO for SecureTrack and SecureChange

  • The login using the portal shown above requires the user to be configured in SecureTrack.
    If a user is configured in SecureChange only (e.g. Approver, Auditor), a successful login is not possible.
    So these users need to be configured in SecureTrack also (but don't need any permission to view any device).

  • If a disclaimer is required, there is only one possibility to configure it (see also here).

  • If external Servers for authentication are used, please be aware of which server is needed and where users need to be configured. (Special AD branches for user/admin used in SecureTrack vs. separate LDAP authentication in SecureChange).

  • The "old" SSO option for SecureChange is no more supported if SSO for SecureTrack/SecureChange is configured.
    So if a portal is used for SecureChange authentication, this needs to be migrated to use SAML-based authentication.

 

 

 

 

 

Details
Category: TOS Aurora

Sometimes it's necessary to provide a disclaimer on the login page. So legal aspects are considered.

When using "Single Sign On" (SSO) in TOS Aurora, only one page for access to SecureTrack, as well as SecureChange, is shown. This page refers to SecureTrack. If a separate disclaimer needs to be shown for SecureChange, SSO needs to be turned off. The same is required if a user is configured for SecureChange only.

 

SecureTrack (or SSO enabled)

There are two options to configure a disclaimer on this page. If the disclaimer consists of a single sentence and it doesn't need to be formatted, it can be added with this command:

#  kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer --content "Access restricted"

This results in

If formatting is required, the disclaimer itself needs to be written into an HTML file. Please find an example below:

[root@TufinOS ~]# ll disclaimer.html
-rw-r----- 1 root root 110 Jan 12 18:03 disclaimer.html
[root@TufinOS ~]# cat disclaimer.html
<!DOCTYPE html>
<html><body>
<h1>Disclaimer</h1>
Please regard - <b>Access restricted</b>
</body></html>
[root@TufinOS ~]#

This file now needs to be imported into TOS Aurora. Before this can be done, the keycloak pod needs to be found.

# kubectl get pods | grep keycloak
keycloak-service-6cb5b94686-jjh9b                    1/1     Running     0          167m

The next action is to copy the file into this pod. Formally, the command looks like this:
  kubectl cp <disclaimer file> <keycloak pod>:<full path of the file in the pod> -c keycloak-service
Following the example above, the full command is

# kubectl cp disclaimer.html keycloak-service-6cb5b94686-jjh9b:/tmp/disclaimer.html -c keycloak-service
#

The next step is to apply this file as the disclaimer file for SecureTrack. Formally, the command looks like this:
  kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer -f <full path of the file in the pod>

# kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer -f /tmp/disclaimer.html
#

The result looks like this

 

If you want to delete any disclaimer in SecureTrack, use this command:

#  kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer --content ""

 

 

SecureChange

Customizing SecureChange is easier than it is for SecureTrack. The menu to customize SecureChange can be reached via Menu > Settings > Customization.
Having navigated to this page, the lower part called "Disclaimer" allows adding the text shown during the login. Basic formatting of the text is possible, too. When finished, press "Publish" - so the text will be shown during login.

Please be aware, that this disclaimer will be shown only if Single Sign On (SSO) is turned off (!)

 

 

 

 

Details
Category: Version update

Tufin has released TOS R22-2, the second version of the Tufin Orchestration Suite of 2022.
TOS R22-2 is available as GA and can be downloaded from the Tufin Portal (login required).
Since the support of TOS Classic provided by Tufin ends within the next weeks, this version is available for TOS Aurora only. Some improvements of TOS Aurora R22-2:

Change Automation and Orchestration

  • SecureChange
    The Designer results include now not only the recommendations for rules but also the Access Request.

  • SecureChange
    If an auto-step with provisioning fails due to ticket dependencies, a new run of the Designer is needed. Then, the auto-step could be tried again. Now, the Designer can be run in this auto-step for provisioning to consider the latest changes.

  • SecureChange
    IPv6 Addresses can now be used in automation, e.g. Target selection, Designer, and Verifier. This is possible when Check Point R8x or FortiManager is used.

  • SecureChange
    In Rule Decommission workflows, now Designer and Provisioning can be split into separate (manual/automatic) steps.

  • SecureChange
    The Rule Decommission workflow now allows the dynamic assignment of steps using a script if the criteria for the assignment are e.g. too complex.

  • SecureChange
    If SecureChange is configured in "Interconnected Domains" mode, now Risk Analysis is possible in Access Requests, even if there are overlapping IP addresses in different Domains. In this case, a flag needs to be set in SecureTrack.

  • SecureChange (Palo Alto Panorama)
    The Designer can be customized to automatically add access to either the pre- or post-sections on Panorama devices per device group or globally.

  • SecureChange (Palo Alto Panorama)
    The Designer can be customized to create new rules with a custom log forwarding profile automatically.

  • SecureChange (Palo Alto Panorama, FortiManager)
    The Designer can now be customized to automatically create new rules with custom security profile groups. Such a custom security profile group is available for different Panorama device groups or FortiManager Administrative Domains.

  • SecureChange (Cisco ASA)
    The Designer now can automatically create network and service objects instead of adding them inline into rules and groups. Possible for Access Request workflow and Clone Network Object workflow.

  • SecureChange
    Access Requests allow to use now User Identity (i.e. add LDAP group in Source) independently of the Topology Mode (on or off).

Devices and Platforms

  • Microsoft Azure
    The Azure Firewall Policy Network and Application Rules are now fully integrated into the Rule Viewer.

  • Microsoft Azure
    The Topology now shows matching rules when running a path analysis on the Map.
  • Microsoft Azure
    The Topology now supports Azure Load Balancers which are integrated here now.
  • Fortinet
    Support of Fortinet SD-WAN for Topology and Policy Visibility. 

  • Fortinet
    Support of IPsec VPN configured in FortiGate devices that are managed by a FortiManager - they are modeled in the Topology now.

  • Forcepoint
    The Stonesoft rules are now shown in Rule Viewer.

  • New version support: Tufin TOS now supports
    • Check Point R81.20
    • Cisco ISO-SE - 17.7.1, IOS-XR - 7.5.1, IOS - 15.9.3M4
    • F5 BIG-IP v16.1.2
    • Forcepoint Stonesoft SMC - 6.10.7
    • Fortinet FortiManager 7.2
    • Juniper SRX 22.1R1

Security, Risk, and Compliance

  • SecureTrack
    Shadowing Rules are integrated and displayed in Rule Viewer, making the review of rule bases easier.

Deployment and Monitoring

  • Backup of Tufin Orchestration Suite
    • Backup files now can be stored directly on external S3 storage services. These storage providers are supported: AWS S3 Storage, AWS Blog Storage, Google Storage, and Minio S3 compatible storage.
    • The expiration dates of backups now can be modified, so backup files can be kept for a longer time.

  • Clustering TOS Aurora is possible for the case of disaster, i.e. running TOS on two different sites is possible when using the same S3 compatible external cloud storage service for backup files. The standby cluster can be switched to active in case of failure of the first one. The TOS is restored from the latest backup file.

  • RADIUS Authentication and Authorization can be configured to run automatically on SecureTrack. So there is no more a need to manually define and manage each SecureTrack user accessing SecureTrack. To implement this, a Vendor Specific Attribute (VSA) is used.

Help and Training

  • The "Help function" is extended and includes now a direct link to Tufin Training videos on YouTube.

  • The TOS version is now also displayed in the SecureChange Help menu.

REST API

  • SecureTrack
    The Rule Information now includes the Palo Alto Panorama UUID
  • SecureChange
    The API call "GET Domains" returns now the Domain Description allowing consideration of different domains.
  • SecureChange
    Script Triggers for Workflow events (get, create, update) can also be used for Marketplace Apps now.
  • SecureChange
    The priority of a ticket can now be updated using a script.
  • SecureChange
    If steps are "self assigned" to groups, a list of users shows potential handlers (candidates). This information can now be used in scripts.
  • SecureChange
    When using GET to get information about users / IDs, now the user name is also returned by this call.

 

If you are using SecureTrack reports, please find a list of depreciated reports that are removed with R22-2 here.

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

 

 

 

 

Details
Category: TufinOS

In November 2022 Tufin has released TufinOS 3.100.
This version is available for download now in the Tufin Portal (authentication required). The download link offers an update package as well as a package for a clean install.

  • Hardening is improved with this version:
    • The user "root" is locked by default in new installations for TOS Aurora. An unlock is possible by setting a password after the installation is complete
    • A reset of the root password is possible now by pressing "e" during the system start. Details about resetting the root password can be found at Tufin Knowledge Center
    • Approved MAC algorithms are configured according to item 5.2.11 of CIS CentOS Linux 7 Benchmark
      If still TOS Classic is used, the ciphers need to be updated in /etc/ssh/sshd_config
  • RPMs are updated, now based on CentOS 7.9 (18.10.2022)
  • The kernel has been updated to version 3.10.0-1160.76.1.el7.x86_64
  • The RPM fio has been added for storage I/O performance check
  • For TOS Aurora, the Wireguard driver has been updated to version 1.0.20220627

Some updates included in this version affect TufinOS Classic only.

  • PHP has been updated to version 7.4.32-1.el7
  • PostgreSQL 11 has been updated to 11.17-1PGDG.rhel7

 

 

 

Details
Category: TOS Aurora

The Tufin Orchestration Suite (TOS) Aurora is no more a "simple installation based on Linux", but a Kubernetes Cluster. Therefore some network requirements regarding IP addresses need to be considered. Before upgrading to or installing TOS Aurora, some IP addresses need to be reserved. These are:

  • A dedicated IP address for each physical server (central server, worker node)
    This address is also used to access the CLI of each system
  • A VIP that is used for accessing the WebUI of SecureTrack/SecureChange/SecureApp
  • If Syslog messages are going to be received, an additional VIP is necessary also

All of these IP addresses need to be on the same network (or the system needs more than one active interface).

Besides this, additional networks need to be reserved for TOS Aurora.

  • A 16-bit CIDR network dedicated to the Kubernetes pods network. It's by default 10.244.0.0/16
    If another network is needed, please contact Tufin Support.
  • A 24-bit CIDR network dedicated to TOS Aurora for the Kubernetes service network. This must not overlap with the first network.

These networks need to be out of the range described in RFC 1918 (i.e. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
They must not overlap with the addresses of the networks listed above. Additionally, it's required that they don't overlap with any subnets communicating with TOS Aurora or its nodes. 

Further details can be found in the Knowledge Center run by Tufin.

 

 

 

Details
Category: Basics

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.