www.tufin.club

Details
Category: TufinOS

Problem

On May 3rd, the OpenSSL project team has announced the release of OpenSSL v1.0.2h and 1.0.1t, respectively. This version addresses some vulnerabilities.
One of the most severe is the OpenSSL Memory Corruption Vulnerability (CVE-2016-2108) which  also affects TufinOS (as many other Linux).

Solution

If you run Tufin TOS under Red Hat Enterprise Linux or CentOS, please download updated packages and install them on your system.
Tufin is working on a patch for the OpenSSL Memory Corruption Vulnerability. patches for TufinOS 2.11 and TufinOS 1.22 are scheduled for the week of May 16th. So next week an update will be possible. If you don't run the latest version, an upgrade might be necessary before installing the patch.
Further information will be provided by This email address is being protected from spambots. You need JavaScript enabled to view it.upon request.

 

19.05.2016 - Update:
The patch for TufinOS 2.11 is available now: https://portal.tufin.com/Doc/Default.aspx?id=1208 (Authentication necessary)
For TufinOS 1.22 the patch will be published after Red Hat has published a patch for RHEL 5. 

 

 

Details
Category: Version update

Parallel to the Check Point CPX in Nice, Tufin has released version 16-1 GA. Until now, the first HF is available, too.
Please find some information about changes in this version below.

This version includes some improvements, e.g.:

  • New Cloud Features for AWS, e.g. automated Connectivity Modeling for AWS Applications, policy based analysis of connections, connection discovery of applications and much more
  • New Cloud Features for NSX, e.g. NSX Application Map

Changes regarding SecureTrack:

  • PaloAlto:
    Support of Palo Alto rule tags, security profiles and log profiles
  • Fortinet NAT:
    Support vo VIP, IP Pool and Destination Interface NAT as far as the Gateway is managed by FortiManager
  • Check Point:
    Full Support of Check Point R77.30 Management
  • Cisco:
    Support of ASA 9.5
  • Upgrade of HTTPD and JMS Server from TLSv1 to TLSv1.2
  • Improvements regarding the Unified Security Policy (USP). Further requirements can be added now, e.g. Logging required, no ANY as Source, Destination, Service, etc.
  • In Rule Base Optimization now a rule can be marked as "legacy". If SecureChange would recommend a change to this rule, it's ignored and a new rule will be defined. This is for optmization of "old and complex" rule bases.
  • Improvements of the REST API, esp. regarding Authorization and Compare of rule bases.

Changes regarding SecureChange:

  • The Designer has been improved, esp. when there are more than one Access Request in a ticket.
  • Visual presentation of rules in the Designer
  • The REST API now offers options for "Modify Group", exclusion of Devices and more. Please find an extended online documetation of the REST API in SecureChange now.
  • Import of Access Requests is now possible for "Comment" and "Action" also

Changes regarding SecureApp:

  • Introduction of a Connectivity Map for a graphical view of all connections affecting an application, regardless of involved devices.
  • Improved support of AWS applications
  • Improvements of the REST API, esp. for AWS

Further improvements and corrections are included.

 

The latest version of the Tufin Orchestration Suite can be found at the Tufin Portal: https://portal.tufin.com

 

Details
Category: SecureChange

If there is a distributed installation with a SecureTrack Server and a SecureChange Server, communication is needed between these two servers.

Necessary communication: HTTPS (443/tcp) in both directions.

SecureChange Server needs information from SecureTrack, e.g. about Topology and Rule Bases of the firewalls. The SecureChange Designer needs also the opposite direction connecting from the SecureTrack Server to the SecureChange Server. If this doesn't work, the designer will result in an error.

To configure the SecureTrack Server in SecureChange, go to Menu > Settings > SecureTrack

 

To configure the name of the SecureChange Server used e.g. in E-Mails, select Menu > Settings > Miscellaneous

The name or IP address listed here represents the SecureChange Server and will also be used for the communication between SecureTrack and SecureChange. If a wrong name or IP address is configured here, SecureTrack won't be able to communicate with SecureChange since only this name/address will be contacted from SecureTrack.

For sure, the name needs to be resolvable for users too, since they will find this name in their E-Mail regarding e.g. a new task.

 

 

Details
Category: SecureTrack

When connecting a Check Point Security Management Server to SecureTrack, there are two possibilities to gather the topology:

Check Point Security Management Server only

In this case, Secure Internal Communication is set up to have a secure connection between the SecureTrack Server and the Check Point Management.
The Topology for SecureTrack is read from the Interface information defined in the Check Point Firewall and Cluster, respectively. Anti-Spoofing information is also read to get as much information as possible about the Topology.

Check Point OS Monitoring

In this case, the Topology is read from the monitored devices directly using SNMP. Other information isn't gathered - information from the object defined in the Security Mangagement Server is ignored.

 

Lesson learned:

If Check Point OS monitoring is activated and the SecureTrack Server has no possibility to read information using SNMP (161/udp), no information about the Topology is imported and therefore this device isn't shown in the SecureTrack Topology. Allowing SNMPv3 between the SecureTrack Server and the firewall device helps to avoit this potential problem.

 

Details
Category: TufinOS

Please update your TufinOS

Google Security has found a vulnerability in glibc, a commonly used library:
https://googleonlinesecurity.blogspot.co.il/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

A remote attacker could create a specially crafted DNS response which could cause libresolv to crash or, potentially, execute code with the permissions of the user running the library.

Tufin points out, that a patch is needed for TufinOS 2.10:

  •     TufinOS 1.x isn't vulnerable
  •     TufinOS 2.x is vulnerablle

Tufin has published a patch for TufinOS 2.10:
https://portal.tufin.com/Doc/Default.aspx?id=1169

Please install this patch. If necessary, carry out an update before so the patch can be installed.

 

 

Details
Category: SecureTrack

Tufin SecureTrack offers some possibilities if a device can't be monitored directly. One of them is to define a Generic Device. Just a short explanation of this kind device and how to configure it.

Generic Device

This kind of device is defined for SecureTrack Topology only. No Monitoring, no security configuration and no logs are imported into SecureTrack. Such a device is necessary if a non monitored device is needed to correct / enhance the Network Topolgy SecureTrack is working with. As you know, that's the base for enhanced features of SecureChange and SecureApp. So it's important to let the Topology of SecureTrack show the reality regarding Networks and Routing.

Since no data is used for reports, analysis of rule bases etc. no license for such a device is necessary.

Why and how to define it? Let's assume you have a topology which isn't according with the reality. Mostly the reason is a missing device, connecting two or more networks. The topology shows like e.g.

So defining a Generic Device might help to improve the topology to show the reality.

Just create a plain ASCII file with all relevant data. Referring to the User Guide might be useful...  ;)
If you want to define a Generic Device to connect the device "firstvs" managed by "SMC-Rio" with the net 198.18.50.0/24 the plain ASCII file might look like this example:

Name, Ip, Mask, Vrf
interface1, 192.168.50.254, 255.255.255.0
interface2, 172.16.41.254, 255.255.255.0

Destination, Mask, Interface, Next-Hop, Vrf
0.0.0.0, 0.0.0.0, interface1, 198.18.50.1

Now it's time to import the file to SecureTrack. This is done in the menu option "Network > Topology > Add Generic Device".

The next step is to save the file and to wait for a moment. SecureTrack is calculating the new Topology. After finishing it, the Generic Device is shown in the SecureTrack Topology. For sure, this change will also be known in SecureChange.

So from now on, this device is known in Tufin SecureTrack Topology and also considered by the other components of the Tufin Orchestration Suite.
If there is a "big Core Device" by Cisco, no definition of all Interfaces and routes is necessary. Just an import of exported configuration data does the job. Redirect the output of

# show ip route
# show ip interface

to a file and import it as shown above. We have proved this also for very big configuration files - and it works if it's a Cisco device...  

 

  • You are here:  
  • Home