www.tufin.club
TufinOS: Update necessary
- Details
- Category: TufinOS
TufinOS 2.x is based on CentOS 6.x. For this version support has reached its EOL (End of Life), so no more support for CentOS 6.10 and below is provided, not even security patches. Therefore Tufin has published TufinOS 3.x, based on CentOS 7 that will be supported until June 30th, 2024.
Besides this, if you want to upgrade to TOS 20-2 you need to upgrade TufinOS also.
So please prepare this upgrade carefully. Some information about it can be found on Tufin's web site, later on we will also provide some information.
Policy Browser: Legacy Rule and Stealth Rule
- Details
- Category: Basics
In SecureTrack it's possible to mark rules as "legacy" or "stealth" in the Rule Metadata shown in the Policy Browser. Marking a rule is also relevant for decisions and/or results of the Designer and Verifier in SecureChange.
To mark a rule, SecureTrack needs to be opened. Then go to Menu > Home > Policy Browser and select a device. After this, mark the rule that shall become a "legacy rule" or a "stealth rule".
The selected rule is shown with a yellow background afterwards. At the top right, a pen is shown. A click on this pen opens a window that allows to edit the metadata of this rule.
In this window, under "advanced options" the rule can be marked as "legacy" (rule action: accept) or "stealth" rule (rule action: drop/deny). To put this information into the rule metadata, "save" needs to be clicked at the bottom of the window.
These are the consequences:
Legacy Rule
In most cases, a rule accepting traffic is marked as "legacy" when it's too open, e.g. allowing every service. In a SecureChange Access Request, the Designer finds usually out that the traffic using even an exotic protocol is allowed due to this rule. If it's marked as "legacy" rule, it's treated as shadowed rule and the Designer puts a new rule above the marked rule. The Verifier of SecureChange also ignores the rule marked as "legacy" rule, i.e. even if every service is allowed it will state that it's not because this rule is ignored from the Verifier.
Stealth Rule
A rule denying traffic marked as stealth rule is usually protecting a firewall gateway because every access from anywhere to this gateway is forbidden by this rule. Each allowed traffic destined to the gateway itself needs to be placed above the stealth rule. The stealth rule usually is located in the top part of a rule base.
Consequences for SecureChange Designer
The Designer considers this kind of rating a rule. If a rule marked as "legacy" would match the traffic, the Designer must not consider this rule for traffic, so above the "legacy" rule a new rule is suggested. This behavior is correct, even if the requested traffic is allowed by the other rule.
If a rule is marked as "stealth" rule, all suggested new rules for accepting traffic are located below it.
Possible problem
If rules marked as "legacy" and "stealth" in a rule base, a problem might occur if a rule marked as "stealth" is below a rule marked as "legacy". An example would be rule 6 as a "legacy" rule and rule 25 as a "stealth" rule. In this case the Designer of SecureChange states
"No suggestion available: Cannot determine correct location for a new rule when the requested traffic intersects a legacy rule which is included in the stealth section"
If you get this error message, keep an extra eye on "legacy" and "stealth" rules...
AERAsec is Tufin SDP+
- Details
- Category: Admin Management
AERAsec is proud to announce that we are the first Tufin Service Delivery Partner + (SDP+) in Germany
Tufin has announced that its Service Delivery Partner Plus (SDP+) training program has introduced a new developer course to its 2020 portfolio. Designed to fill industry gaps, the course delivers training and development opportunities in key areas such as Tufin APIs, integrations, customizations, and development techniques.
AERAsec is proud to be the first SDP+ partner in Germany (press release in German language) after being one of the first SDP partners worldwide. So we can deliver now even more value to our customers due to the ability to officially deliver customizations of the Tufin Orchestration Suite. So customers will have additional value not only from AERAsec's experience but also from very intense cooperation between AERAsec and Tufin.
Customers purchasing Tufin products from AERAsec will have an additional advantage because of special conditions regarding these services. Please This email address is being protected from spambots. You need JavaScript enabled to view it. if you want to know more about AERAsec delivering Tufin Products and Services.
How to ignore Interfaces in Topology
- Details
- Category: SecureTrack
In many situations, Firewalls not have their "productive" interfaces only, but also others like e.g. Management Interfaces. If this is the case and many Firewalls are connected not only via "productive" interfaces but also via Management Interfaces, some problems might arise. One could occur when SecureTrack Topology is used to check the path a packet takes. Even if it's not the case in real life, Topology could consider the shortest way using the Management Network... As a consequence, the Designer of SecureChange could also assume this path - and the result isn't as expected.
So in many cases, it seems to be useful to ignore single interfaces in SecureTrack Topology. This can be done quite easily, but it needs to be done very carefully and well documented (!).
Please don't continue before you have made a backup of your data!
To find out the relevant device, you first need its Management ID in Tufin SecureTrack. If it's a directly monitored Firewall (e.g. Cisco ASA, FortiGate without FortiManager or directly monitored Check Point Firewall Module) the Management ID can be found in Menu > Compare. Go to the left pane called "Monitored Devices" and press "t". The Management ID shows up beside the name of the device. In the screenshot shown below, Firewall modules have the Management ID 290 and 294, respectively.
If only the Management is listed here, another step is necessary because here only the ID of the Management is shown.
In this case, you need to go to Menu > Settings > Administration > Licenses. Here you scroll down to the section called "Devices", click into it, and press "t". The Management IDs of all Devices will be shown here.
Next is to find which interface shal be ignored by Tufin Topology. You can obtain this information from SecureTrack or directly from the device.
To have an example, we will ignore the Interface "Mgmt" of the device with ID 290 and IP address 192.168.1.1 from Topology.
This information needs to be stored in the database. You can do this using the REST API or directly via CLI. In this example, we use CLI for modification of the table "ignored_interfaces".
To get a list of all currently "ignored_interfaces" this command should be used:
[root@TufinOS ~]# psql -Upostgres securetrack -xc "select * from topology_ignored_interfaces"
-[ RECORD 1 ]--+-----------------
interface_name | ethernet1/1
mgmt_id | 2
ip | 0.0.0.0
[root@TufinOS ~]#
To add an interface to this list, be sure to have the Management ID of the device as well as the name of the interface and its IP address. Then it can be added to this table using
[root@TufinOS ~]# psql -Upostgres securetrack -xc "insert into topology_ignored_interfaces (interface_name, mgmt_id, ip) values ('Mgmt','290','192.168.1.1')"
After having done so, this interface is listed in the table and therefore ignored by SecureTrack Topology - after a Sync of the Topology (!).
(The IP address can also be left out, then it later shows "0.0.0.0")
[root@TufinOS ~]# psql -Upostgres securetrack -xc "select * from topology_ignored_interfaces"
-[ RECORD 1 ]--+-----------------
interface_name | ethernet1/1
mgmt_id | 2
ip | 0.0.0.0
-[ RECORD 2 ]--+-----------------
interface_name | Mgmt
mgmt_id | 290
ip | 192.168.1.1
[root@TufinOS ~]#
If you look at the device in the Topology, this interface isn't listed here any more.
To remove an interface from this list and to get it back into Topology, just take the command
[root@TufinOS ~]# psql -Upostgres securetrack -xc "delete from topology_ignored_interfaces where interface_name='Mgmt' and mgmt_id='290'"
To make this change effective, don't forget to Synchronize the Topology again.
AERAsec is 2019 EMEA SDP of the Year
- Details
- Category: Basics
At Tufinovate 2020, AERAsec has been nominated as
EMEA SDP / Service Partner of the Year
Thanks to Tufin for this award!
See also Tufin Press Release about this topic.
USP Violations, Interfaces and Network Zones
- Details
- Category: SecureTrack
Having a Unified Security Policy (USP) requires to have network zones defined, filled with all relevant networks.
This is done in SecureTrack via Menu > Network > Zones. Only zones defined here can be used in an USP configuration.
There are some pre-defined zones:
- Internet
This zone includes all official IP-Adresses that are not defined to be in any other zone - Unassociated Networks
This zone includes all private IP-Adresses (RFC 1918) that are not defined to be in any other zone - Users Networks
This zone includes all networks that users connect to (e.g. used in Check Point Identity Awareness)
Based on interface information of devices, zones are allocated with interfaces automatically - except the zone Internet.
Tufin SecureChange calculates "Risk" in Access Requests in the classic way while SecureTrack uses for the calculation of "Violations" a specific configuration that can be adapted.
To modify interfaces and zones, it's necessary to go to the USP list, i.e. Menu > Audit > Compliance > Unified Security Policy. Here you select an USP to modify the relationship of Interface - Zone. This is done by pressing the button "Preferences". A window opens, so you can modify the allocations manually.
In this example, the Interface "pppoe2" has no associated zone even if (in real live) the "Internet" is connected to this Interface. To configure this, select the interface and then the button "Edit" at the top right. Here, you select the zone that shall be connected to this Interface.
After having done so, the configration is changed by pressing the button "save".
So from now on, calculations regarding "violations" consider this configuration and zone association.
Please regard: Be sure to document well all changes done this way!
In SecureTrack Audit Trail only this message is shown "Unified security policy configuration - Modify - Device - FWGW-Office - Modify was done by MeAdmin on interface/zone mapping for device FWGW-Office".
Changes done here have a direct impact on "violations", so every configuration change needs to be documented well.
The calculation of "violations" is done when a new revision arrives to SecureTrack, a USP is changed or the Topology (Interactive Map) is synchronized.
Page 8 of 22