www.tufin.club

Details
Category: SecureTrack

When upgrading Check Point Management, MDS or CMA from R77.x to R80.x it seems quite easy to upgrade it in SecureTrack, too. Just go to Menu > Settings > Monitoring and select the device that has been upgraded. The Menu on the right side shows the option "Upgrade to R80", you select it and provide the credentials for the API user at the Check Point Management. After that, the device monitoring has been changed to R80 and everything runs fine.

 

Problem

What happens if "st stat" or Menu > Admininstration > Status shows an error:

myDevice        10.1.1.1  14   CMA  1001   valid        Error: Upgrade device to R80 in Settings > Manage Devices > Monitored Devices

The situation seems a little bit confusing - the upgrade has been done in Check Point as well as Tufin SecureTrack, but the status shows an error as if the Management Server has not been upgraded in SecureTrack.

 

Reason for this error

The reason for this error is a change of the management type in the data base - and the change has not taken place in the data base. This is not the "normal way", but it might happen that the change is not recognized in SecureTrack. The differences are:

SmartCenter R77.x is referred as cp_smrt_cntr
SmartCenter R80.x is referred as cp_smc_r80plus

CMA R77.x is referred as cp_cma
CMA R80.x is referred as cp_domain_r80plus

 

Solution

First - as every time you work on the data base: Perform a backup (!)
For a Check Point CMA the necessary next procedure looks like this:

  • Check the ID of the device using "st stat". This example uses the Management ID 14
  • Check the current status of the device:
    [root@TufinOS]# psql -Upostgres securetrack -xc "select cp_type from managements where management_id=14"
    -[ RECORD 1 ]---
    cp_type | cp_cma
    [root@TufinOS ~]
  • Update the variable in the data base and re-check the status
    [root@TufinOS ~]# psql -Upostgres securetrack -xc "update managements set cp_type='cp_domain_r80plus' where management_id=14"
    UPDATE 1
    [root@TufinOS ~]# psql -Upostgres securetrack -xc "select cp_type from managements where management_id=14"
    -[ RECORD 1 ]--------------
    cp_type | cp_domain_r80plus
    [root@TufinOS ~]
  • Restart the monitored device
    [root@TufinOS~]# st restart 14
    Stopping SecureTrack process for server myDevice - 10.1.1.1 (Id: 14)
    SecureTrack process stopped for server 10.1.1.1 (Id: 14)
    SecureTrack for myDevice - 10.1.1.1 (Id: 14) was started successfully
    [root@TufinOS ~]

 

After some seconds the status should have been changed - this can be checked either "st stat" or the WebUI.
The error shown above should not be shown any more. If other errors are shown, you need to continue troubleshooting. Maybe these links help:
https://www.tufin.club/index.php/24-securetrack/52-check-point-api-client-error
https://www.tufin.club/index.php/24-securetrack/73-check-point-api-client-error-part-2

 

 

 

 

Details
Category: TOS classic

If TOS is configured to run as a cluster, a Virtual Cluster IP (VIP) is used for communication with SecureTrack and/or SecureChange server. Besides this, further interfaces are needed to configure a cluster, e.g. for Heartbeat. If the network interface of the Heartbeat is down, the cluster will do a failover. At first glance, this isn't a problem because users can still work using the VIP. But, for bringing TOS back to cluster mode with data replication, a maintenance window is recommended. The database sync takes some time and during this time the VIP is unreachable.

So if a cluster member is e.g. moved from one switch to another, a failover occurs. If this isn't wanted, the failure detection can be (temporarily) disabled by typing the command on the active member:

# hactl --pause-auto-failover

Run the command hactl status on both nodes after a few minutes and make sure the status shown is "unmanaged"
Then, replace the switch. If done so and having connected all cables on the active cluster member run the command:

# hactl --resume-auto-failover

After some (short) time, the status should be checked again using hactl status. It should be normal again, showing correct distribution of active / standby member as before.

 

 

 

Details
Category: TufinOS

In September 2019 Tufin has released TufinOS 2.19. This version is available for download now in the Tufin Portal (authentication required). TufinOS 2.19 is available as upgrade package only. So if you need to set up a new system, installing TufinOS 2.18 from ISO or USB is necessary befor upgrading to 2.19.

New features and updates of TufinOS 2.19 are:

  • Update of 29 RPMs based on the latest version of CentOS 6.10
  • Update of PostgreSQL to version 9.4.23

Please be aware that only TufinOS 2.19 is supported by Tufin now, i.e. older versions will also get no security related updates.

An updated description how to upgrade TufinOS in HA environments is available in the Tufin Portal.

 

 

 

Details
Category: Basics

Many thanks to Tufin for nominating us at Tufinnovate EMEA 2019 in Lisbon. We are proud to be awarded to be

  2018 EMEA Service Provider of the Year

So about one year after becoming the first Tufin Service Delivery Partner in Central Europe, it's an honor for us to be awarded with this price.

Award Ceremony Tufinnovate 2019, Lisbon - Portugal, 11.09.2019
From left to right:
- Ruvi Kitov, CEO and Co-Founder Tufin Technologies
- Kevin Raff, IT Security Consultant AERAsec
- Dr. Matthias Leu, CEO and Founder AERAsec
- Mike Menegay, VP of Global Channels Tufin Technologies
- Remko Postma, Director of Channels EMEA Tufin Technologies

 

 

 

Details
Category: Version update

Tufin has released R19-2, the second version of the Tufin Orchestration Suite in 2019. TOS 19-2 is available as GA now, delivering some improvements, e.g.

Change Automation and Orchestration

  • SecureChange
    Enhancements for the "Clone Server Policy" Workflow. They include zero-touch automation for Designer, Policy Update and Commit Policy Changes for all supported devices. Addtionally, support for NSX-V has been added.
  • SecureChange
    The Desgner now can be configured to implement changes in Access Requests as before (optimized policy), but also to implement each Access Request in separate rules. On demnad, this can also be requested by users.
  • SecureChange
    The Workflow "Modify Group" supports now Check Point objects with dual stack (IPv4 / IPv6)
  • SecureTrack, SecureChange
    Support of Fortinet Web Filter allows more visibility on rules that have configured it. So auditing is improved. End-to-End change automation is possible for current and Next Generation Fortinet configurations.
  • SecureChange
    Support of Dual Stack Objects (IPv4/IPv6) in Modify Group Workflow for Check Point R80
  • SecureChange
    Requester Notifications can be sent to AD groups, not only to individuals

Security, Risk and Compliance

  • SecureTrack, SecureChange
    Updated NextGen Applications Library for Palo Alto.
  • SecureTrack
    Improved Troubleshooting using advanced path analysis queries that contain multiple IP addresses
  • SecureTrack, SecureChange
    Protection against CSRF (Cross-Site Request Forgery) attacks (not currently supported for Microsoft Internet Explorer 11)

 Devices and Platforms

  • SecureTrack
    Support of Cisco ACI regarding "Enhanced Visibility", "Enhanced Topology Modeling", and "Risk Assessment".
  • SecureTrack
    Support of Palo Alto Panorama High Availability
  • SecureTrack
    Suppport of Palo Alto Panoramy External Dynamic List (EDL) Support
  • SecureTrack
    Support of Palo Alto Fully Qualified Domain Names
  • SecureTrack, SecureApp
    Policy Browser allows mapping of SecureApp Connections to rules for Cisco FMC, Fortinet FortiManager, and Palo Alto Panorama in Advanced Mode
  • SecureTrack
    Support of Check Point CloudGuard for Azure
  • Support of new devices:
    • Cisco Firepower Management Center (FMC) 6.3
    • Cosco ASA 9.13 beta

REST API

  • Improvements for SecureTrack
    • Automatic onbording of Management Devices via API has been added for Palo Alto Panorama and Fortinet FortiManager (both in advanced management mode) as well as Cisco ASA including import/update of virtual contexts
    • Adding / Updating of single or multiple devices is possible now for Palo Alto Panorama and Fortinet FortiManager (both in advanced management mode) as well as Cisco ASA including import/update of virtual contexts
  • Improvements for SecureTrack/SecureChange
    • Support for Palo Alto Panorama External Dynamic List (EDL) data has been added
  • Improvements for SecureChange
    • The results for the Clone Server Policy can be retrieved via API
  • Improvements for SecureTrack/SecureChange/SecureApp
    • The serialization implementation for JSON is now complete for all SecureTrack, SecureChange and SecureApp REST APIs.

 

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

 

 

 

Details
Category: SecureTrack

In some cases, it's necessary to change the IP address of the SecureTrack Server. Some facts need to be considered before. The change itself consists of two parts - changing the IP address of the system as well as changing the IP in the SecureTrack Server.

  • Please consider that the solution described is working for TOS CLASSIC only!
    If the IP address needs to be changed for TOS AURORA, a new installation is necessary - see also the Knowledge Center of Tufin.

 

Things to be considered before

Esp. in complex scenarios, some facts need to be considered before changing the IP address of SecureTrack, e.g.

  • Check and configuration of IP addresses/netmasks for all NIC (see below), incl. update of file /etc/hosts
  • Check and configuration of routes

  • Check if switch configuration is affected (e.g. VLAN,  Port Security...)
  • Check if there are changes necessary for using DNS, NTP, syslog, etc.
  • Check if changes are needed at other servers, e.g. SecureChange, Authentication, E-Mail, LDAP
  • Check if firewall rules need to be changed for communication between SecureTrack and SecureChange (and vice versa), SecureTrack and monitored devices...
  • If Check Point is monitored: Check if API access is still possible after changing the IP address, modification of OPSEC Application is needed
  • Other devices need to be configured to send syslog data to the new IP address
  • If Access Control is configured, access from the new IP address needs to be allowed, e.g. for downloading a new revision
  • ...

Don't forget to update the documentation/operation manual

Changing the IP address of TufinOS

Since TufinOS is based on CentOS, changing the IP address of an interface (eth0) is done by editing the file

/etc/sysconfig/network-scripts/ifcfg-eth0

In this file the parameters IPADDR and NETMASK need to be adapted. If necessary, changing the GATEWAY might necessary also. To make the changes effective, a restart of the network component (service network restart) or a reboot of the system is necessary. After this successful change SecureTrack Server has the other IP address.

Changing the IP address in SecureTrack

Before making any change using the command psql, create a backup of your configuration!

If only the IP address of the system is changed, SecureTrack shows the "old" IP address in the WebUI. Everything works fine, but this address should also be changed.
Btw., the same issue happens if a backup is restored to a machine with a different IP address.
In Menu > Settings > Administration > Status, the "old" IP address is 10.100.200.206 is shown. It should be the "new" IP address 10.0.0.20.

To change the IP address it's necessary to connect to the CLI with administrative rights.
First thing to do is to find the ID of the SecureTrack Server.

[root] psql -Upostgres securetrack -c "select * from st_servers"
id |       ip       | display_name | services_stat |   services_last_update    | disk_usage | server_type | software_version | cgi_stat |      cgi_last_success
----+----------------+--------------+---------------+---------------------------+------------+-------------+------------------+----------+----------------------------
  1 | 10.100.200.206 | TufinOS      | ok            | 2019-09-05 15:25:13.32552 |         15 | standalone  |                  | up       | 2019-07-15 10:57:36.657694
(1 row)
[root]

The next step is to change the IP address of this server.

[root] psql -Upostgres securetrack -c "update st_servers set ip='10.0.0.20' where id='1'"
UPDATE 1
[root]

Now it can be checked that also in the data base the IP address is changed:

[root] psql -Upostgres securetrack -c "select * from st_servers"
id |       ip       | display_name | services_stat |   services_last_update    | disk_usage | server_type | software_version | cgi_stat |      cgi_last_success
----+----------------+--------------+---------------+---------------------------+------------+-------------+------------------+----------+----------------------------
  1 | 10.0.0.20 | TufinOS      | ok            | 2019-09-05 15:25:13.32552 |         15 | standalone  |                  | up       | 2019-07-15 10:57:36.657694
(1 row)
[root]

After a new login at the WebUI also here the correct IP address is shown.

 

 

 

 

 

 

 

 

  • You are here:  
  • Home