www.tufin.club

As many administrators know, there is an option Suite Administration when configuring TOS using tos conf. Activating this option allows to monitor the system.

If (3) is selected and therefore the Suite Administration activated, it needs to be configured. This is done by the command

[root@TufinOS]# configure_os_monitoring

A menu opens and allows to configure the necessary options:

 

  • Recipient Settings

    Configure Recipients here who will get an E-Mail when Suite Administration is sending an alert.
    1. Show defined recipients
    2. Add recipient
    3. Delete recipient
    4. Modify recipient

 

  • SMTP Settings

    This section is to configure the Mail server for sending E-Mail to recipients in case of an alert. Besides this, authentication data for the Mail server needed to send E-Mail can be configured.
    1. Server Name
    2. Server Port
    3. User Name
    4. User Password
    5. Sender Email
    6. Mail Sending Interval

 

  • SNMP Settings

    TufinOS will send SNMP Traps when an alert condition is given. In this section the server, port etc. need to be configured if Traps are wanted. The support of addtional SNMP MIBs can be configured by adapting the file /etc/snmp/snmpd.conf and restarting the snmpd. 
    1. Manager IPv4 Address
    2. Manager Port
    3. Community Name
    4. Trap Sending Interval

 

  • Threshold Settings
       
    Configure Thresholds here. Please be aware that the default for CPU usage is 10%, i.e. if there is a little load on the machine, an alert will be sent.
    The options for JMS Tunnel and Stunnel are needed only, if the server is used in an HA deployment or the Central Server is in an environment using Distriubted Architecture (DA).
    1. CPU Usage (default: 10%!)
    2. Memory Usage (default 70%)
    3. Disk Usage (default 70%)
    4. Service Settings
      1. Application Server   
      2. Cron
      3. Database
      4. JMS Tunnel
      5. Stunnel
      6. Syslog
      7. Web Server

 

So these options might allow a tighter control and monitoring TufinOS as well as the services running on this machine.

 

 

 

 

 

The Tufin Orchestration Suite (TOS) sometimes needs to be customized. Tufin delivers some options to use an own logo, but not everywhere. Let's have a look the default options and more.

 

SecureChange

in SecureChange a user with administrative rights has access to the Settings tab in the menu. Selecting Menu > Settings > Customzation offers the use of an own logo.

At the bottom of the page is a button labeled Publish. Pressing it will change the logo used in SecureChange.

So changing the logo in SecureChange is quite easy.

 

SecureTrack

By default, an own logo can be integrated for SecureTrack Reports. This is done via Menu > Settings > Configuration > Reports. The fiels Custom Logo allows to place the own logo here.

As an option, the logo can also be shown on every PDF page. The result looks quite good.

 

Sometimes the WebUI of SecureTrack shall also be customized. Tufin doesn't have an option for this in the Menus of SecureTrack. But changing the logo is also possible.
Requirement: PNG file with a size of 120x50 called tufin-suite-logo.png.
The following procedure is for SecureTrack R17-3 (paths may vary in other versions).

If you have your logo, make a backup of the original files before you continue. Then rename your logo to tufin-suite-logo.png and place it on the server:

Logo in the WebUI top left:
/var/www/html/images/header/tufin-suite-logo.png

Logo for Login window:
/usr/keycloak-2.5.4.Final/themes/tufin-theme/login/resources/img/tufin-suite-logo.png

Logo for Logout window
/var/www/html/logout/tufin-suite-logo.png

After having changed these settings (and cleared the browser cache), the own logo is shown in SecureTrack also.

 

 

 

 

 

 

 

 

Tufin has released the latest version of the Tufin Orchestration Suite. So TOS 17-3 is available in its GA version, delivering some improvements, e.g.

Cloud

  • SecureChange with end-to-end Automation Support for VMware NSX
  • SecureTrack with Enhanced Cisco ACI Support
  • License visibility is given now

Security Policy Change Automation and Orchestration

  • Integration of Check Point Identity Awareness Blade Support for Policy Change Automation
  • Enhancements for "Modify Group" workflow, e.g. support of creating new groups and not modify existing only
  • Rule Decommission Automation for Juniper SRX

Security, Risk, and Compliance

  • Policy Browser Search Enhancements
  • Interactive Map Enhancements

Devices and Platforms

  • FortiManager Support Enhancements
  • Cisco Firepower Enhancements
  • Support of new devices / versions:
    • BlueCoat - SGOS 6.7.1.1
    • Cisco - ASA 9.7
    • Cisco - CSM 4.12
    • Forcepoint - SMC 6.3
    • Fortinet - FortiGate 5.6
    • Fortinet - FortiManager 5.6
    • Juniper - M/MX 13.3 R10.2, 16.1 R4
    • VMware - NSX 6.3.3
    • VMware - vCenter 6.5

REST API

  • API Support for Check Point R80 Identity Awareness
  • New Network Topology APIs
  • New Cloud Topology APIs
  • Enhanced Rule Search
  • Authentication using TACACS via REST API

 

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

 

 

 

 

 

 

Since some time many news have been published about Meltdown and Spectre. Exploiting these vulnerabilities might allow an unprivileged attacker to bypass conventional memory security restrictions in order to gain read access to privileged memory that would otherwise be inaccessible. Further information about these vulnerabilities can be found e.g. here:

https://research.checkpoint.com/detection-meltdown-spectre-vulnerabilities-using-checkpoint-cpu-level-technology/
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
https://meltdownattack.com/

Tufin has published a Security Advisory regarding this topic.

These versions TufinOS is affected by these vulnerabilities: TufinOS 1.8 - 1.23 as well as TufinOS 2.0 - 2.14.
Tufin has released TufinOS 2.15 which includes the corresponding patch. It's strongly recommended to update to this version.
Information about possible performance impacts can be found here.

Since TufinOS 1.x is based on CentOS 5 it's no more supported. So no patch will be provided. Upgrading from TufinOS 1.x to TufinOS 2.15 is possible and strongly recommended.


PS: Please check Release Notes which versions of TOS are compatible with TufinOS 2.15!

 

 

 

 

 

When using Check Point Management R80.x besides the "normal" OPSEC connections a connect to the Check Point Management API is necessary.

How to connect Tufin SecureTrack with Check Point Management R80 is described here.

Even if the connection to the Check Point Management is ok, an error might be displayed: 
Checkpoint API client error

Testing the connection from SecureTrack using
Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity

seems successful, but the status icon of the device is yellow in SecureTrack. In Menu > Settings > Administration > Status > Check Point Management R80 > Status the error is shown and no new revisions are imported to SecureTrack.

Background information: "Test Connectivity" checks currently the OPSEC channel (used in R77.x) only. The second channel is the Management API which is necessary when monitoring R80.x.

Some troubleshooting might solve this issue. You can try one or more of the following things before restart monitoring the device:

  • Check that the Check Point Management monitored is really Version R80.x and not still Check Point R77.30. If that's the case, the device needs to be deleted and new defined as Check Point Management R77.30. There is no way to change the Check Point Version from R80.x back to the old one.
  • Check that Tufin SecureTrack is able to connect to Check Point management Server using port 443/tcp. Maybe a Firewall is blocking this traffic.
  • Check the credentials configured for the Tufin user at the Check Point Management Server.


  • Check the permissions of the Tufin user at the Check Point Management Server. This user needs rw even if there is no provisioning configured or planned.


  • Check the Expiration Date of the account, sometimes it's not the default value ending in 2030.
  • If all these measures don't help, try to restart the Management API at the Check Point Management Server. This can be done as "expert" using the command api restart.

 

If you have further ideas or if these items didn't help, please don't hesitate to contact us.

 

 

 

Sometimes it seems as if not all needed options are available when defining a Workflow in Tufin SecureChange.
Since many versions of SecureChange, some templates are available that might help administrators to create Workflows:

  • Access Request Template
  • Group Change Template
  • Generic Template
  • Remove Access Template

If the requirement allows to use such a Template as basis for a new, own Workflow it's ok to use them.

If there are further requirements like e.g. Removal of a rule, a "new" Workflow should be defined.
This is done by clicking on the corresponding button (required: Correct right from Role in SecureChange, otherwise this option might not be available).

After clicking on New Workflow some basic things like Name of the Workflow needs to be configured. Besides this, the Type of Workflow is required. Please be aware that this type can’t be changed later on.

Available options are:

  • Access Request
    Users need this type of Workflow to request access to some hosts or networks using “Source-Destination-Service”
  • Access Request & Modify Group
    Besides requesting access this type allows to request a change of a group of firewall objects, e.g. a group of Hosts or Networks
  • Generic
    A very flexible Workflow allowing e.g. the management of holidays (which isn’t the real purpose of SecureChange…)
  • Modify Group
    This Workflow allows to change Groups of e.g. hosts or networks defined in Firewall configuration. It’s mostly used by people having access to Firewall configuration files. Please be aware that since R17-3 also new Groups can be defined here.
  • Rule Decommission
    If a rule needs to be removed, this type of Workflow should be used. It’s triggered from SecureTrack > Menu > Policy Browser. Please find further information about this topic here.
  • Server Decommission
    For removing Servers this is the Type of Workflow that should be selected.

Be sure that you select the correct type for the Workflow you need. Please consider the fact that changing the type isn’t possible when copying a Workflow as a base for a new Workflow.