www.tufin.club

In some situations, it might be necessary to add Interfaces to devices. Reasons might be a not by Tufin recognized Interface or the support of VRRP or GLBP. You need some steps to add a generic Interface to a device monitored by SecureTrack.

  1. Find the Device ID of the device that gets one or more generic Interfaces
  2. Configure a CSV file providing information about generic Interfaces
  3. Import the CSV file to Tufin SecureTrack
  4. Synchronize the Topology and check the result

 

1. Find the Device ID in Tufin SecureTrack

There are several methods to find the Device ID in SecureTrack.

In Menu > Compare all monitored devices are listed on the left side. If you click into the left window and press "t" the Device ID is shown right from the device.

It is also possible to gather this information at the CLI using the command "st stat".

You need to pay attention if you are using a Firewall Management like e.g. Check Point SmartCenter. In this case, you will need the Device ID of the firewall and NOT the Device ID of the Management (!)

To find the Device ID of the Firewall you need to go to Menu > Settings > Administration > Licenses. Here you scroll down until the window "Devices" is shown. Clicking into it and pressing "t" will show the Device ID not only of the Management but also of the Firewalls connected to it.

In this example, the Device ID of the Firewall "r81" is 344. If Device ID 343 is taken, the Management is altered resulting in an error in the Topology.

 

2. Configure a CSV file providing information about generic Interfaces

The file providing the information needs to be a plain ASCII file with a ".csv" extension. If another file type is chosen, the import will not be successful.
Each line needs to have six comma-separated entries. Even if there is no entry, the comma needs to be written.

  • Name of the generic Interface
  • IP address of the generic Interface
  • Mask corresponding with the IP address, dotted-decimal
  • VRF where the generic Interface resides
  • MPLS i.e. boolean expression if the generic Interface has configured MPLS
  • Unnumbered, blank means that the Interface is numbered, unnumbered requires a "true"

Each generic Interface requires an own line. Example for a very simple generic Interface:
   MyNewInterface, 10.2.2.1, 255.255.255.0,,,

Hint:
The information provided in this file always replaces all generic Interfaces that are configured on the device. So if you want to add a generic Interface, you will provide information about the new, but also the already configured generic Interface.

 

3. Import the CSV file to Tufin SecureTrack

The file now can be imported. This is done by the command
  /usr/local/st/topology_generic_interfaces -m <Device ID> -i <file name>

[root]# /usr/local/st/topology_generic_interfaces -m 344 -i MyGenericInterface.csv
Successfully deleted all generic interfaces for device 344
1 generic interfaces has been loaded to device 344 from input file MyGenericInterface.csv.
[root]#

If necessary, generic Interfaces can also be deleted. To delete all generic Interfaces from Device ID 344 this command should be used for this task:
[root]# /usr/local/st/topology_generic_interfaces -m 344 -d
Successfully deleted all generic interfaces for device 344
[root]#

 

4. Synchronize the Topology and check the result

If you have time, you can wait until the next morning since at 3:00 a Topology Synchronization is done automatically. If not, the synchronization needs to be started manually. This is done using the WebUI via Menu > Network > Interactive Map and the "sync button".

After a refresh, the new generic Interface is established and used by SecureTrack for Topology calculation and representation.

 

 

 

 

 

When having SecureTrack and SecureChange, revisions can be compared. Additionally, the SecureChange Ticket ID is available as a link in SecureTrack. Following this link from SecureTrack, the referring ticket is automatically opened and shown in SecureChange (if the current user is allowed to access it).

Additional information can be gathered using SecureTrack > Home > Change

In this table, all revisions are listed. Information provided is the device, the revision number as well as who did the change. The right row shows states like e.g. "Authorized". Let's have a closer look at the conditions about the shown status.

  • N/A
    SecureTrack runs without SecureChange or the option for linking SecureChange tickets with a revision is not active. It can be activated by a SecureTrack administrator via the menu:
    Menu > Settings > Configuration > Ticketing

    This option allows to restrict the search in tickets for a specific time, e.g. 3 months. If it's not restricted, the whole ticket database will be searched for possibly matching tickets. So iit's possible to have (much) more than one ticket matching the change.

  • Authorized
    The change is authorized under several conditions
    • The change has no influence on the traffic passing the device. This happens e.g. if a comment has been added to a rule or an object has got a new color.
    • The change doesn't allow any new (additional) traffic.
    • The change allows exactly the traffic that has been requested and approved by a ticket. In this case, the ticket ID is shown in the line. It might be possible that there is more than one ticket referenced. This is due to more than one ticket matching the change. Considered are all tickets in the time frame configured as shown above.

  • Unauthorized
    Then change is unauthorized under several conditions
    • There is a change regarding traffic through a device with no matching ticket for it. This is the situation if a change is done without requesting it by a ticket. The change is directly configured in e.g. Check Point SmartConsole.
    • The change done is not completely covered by a ticket. This happens if e.g. the service SSH is requested, but SSH and HTTPS are implemented. In this case, only a part of the change has been requested and approved by a ticket. The ticket ID is shown in this line.
    • The change requested a "rule modification" and not all changes are covered by a ticket. This includes also removal of e.g. services. If the service HTTP should be removed from a rule, but HTTP and FTP are removed, the change is unauthorized also (even if less traffic is allowed afterwards).

 

Manual changes on the status

Besides this, a manual change of the status is possible. This might be useful when e.g. an emergency change needed to be configured. Changing the status requires administrative access to SecureTrack. This option is not available for a "user", even for the device he or she is allowed to see.

If a change needs to be "authorized" manually, just go to the pen shown near the status.

   

In this example, an "unauthorized" change will be changed to "authorized". After confirmation, the status is changed, but a sign allows to see that the change was done manually. Besides this, the date and administrator are shown.
The same procedure can be done to "unauthorize" changes manually.

 

Hint regarding compliance

Current versions of SecureTrack don't allow to add a comment if the status is changed. That's the reason why the column "Comment" is empty in Menu > Home > Change. This column is not shown in the overview (Menu > Home > Dashboard).

The missing opportunity to provide a comment (i.e. reason for the manual change) might be problematic if the configuration is audited. So the reason for changing the status needs to be documented somewhere else.

 

 

 

 

 

 

 

 

Sometimes it is necessary to have logs who tried to logon to TufinOS or TOS. Also, not successful tries need to be recognized and logged. This often is a requirement, esp. if compliance regulations need to be fulfilled. Logging can be done by extracting information from Tufin in a tool like e.g. Splunk. The information is stored in some files described below.

 

TufinOS

Logon to the CLI of TufinOS is recorded automatically since it's based on CentOS. The file in which this information can be found is
     /var/log/secure

Please find an example for an unsuccessful (user123) and successful login (root).

Mar 16 19:38:57 localhost sshd[24880]: Invalid user user123 from 10.0.0.23
Mar 16 19:38:57 localhost sshd[24881]: input_userauth_request: invalid user user123
Mar 16 19:39:01 localhost sshd[24880]: pam_unix(sshd:auth): check pass; user unknown
Mar 16 19:39:01 localhost sshd[24880]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.23
Mar 16 19:39:01 localhost sshd[24880]: pam_succeed_if(sshd:auth): error retrieving information about user user123
Mar 16 19:39:03 localhost sshd[24880]: Failed password for invalid user user123 from 10.0.0.23 port 50025 ssh2
Mar 16 19:39:11 localhost sshd[24881]: Connection closed by 10.0.0.23

Mar 16 19:39:38 localhost sshd[24888]: Accepted password for root from 10.0.0.23 port 50026 ssh2
Mar 16 19:39:38 localhost sshd[24888]: pam_unix(sshd:session): session opened for user root by (uid=0)

 

Tufin SecureTrack

A successful login to the WebUI of SecureTrack is recorded in the database. This information can be checked in the WebUI also. To do so, go to Menu > Settings > Administration > Audit Trail. As shown below, a successful login and logout can be monitored here.

 

 Sometimes this information isn't sufficient since also not successful login attempts need to be documented. This can be done by checking the file
      /var/log/keycloak/server.log

When using local authentication, a non-successful login of a user (user2) looks like this in the file

WARN 2021-03-16 20:41:28,511 [default task-2::o.k.events.onEvent] [user:] type=LOGIN_ERROR, realmId=f93f5360-fa5c-4777-aa14-c91c4730e49a, clientId=st_httpd_10.0.0.20, userId=null, ipAddress=10.0.0.23, error=identity_provider_error, auth_method=openid-connect, auth_type=code, redirect_uri=https://10.0.0.20/protected/redirect_uri, code_id=dcca1e78-7a0f-43f3-a017-772ac8c291fe, username=user2#ovzwk43sge======, authSessionParentId=dcca1e78-7a0f-43f3-a017-772ac8c291fe, authSessionTabId=BXN4R0pwtHU

When LDAP is used for authentication at SecureTrack, some more basic information is delivered (user1).

ERROR 2021-03-16 21:14:53,338 [default task-1::c.t.c.k.a.c.h.d.LoginHandlersDispatcher.handleLogin] [user:] LDAP authentication failed for user:{user1}: java.lang.RuntimeException: LDAP authentication failed for user:{user1}
...
WARN 2021-03-16 21:14:53,340 [default task-1::o.k.events.onEvent] [user:] type=LOGIN_ERROR, realmId=f93f5360-fa5c-4777-aa14-c91c4730e49a, clientId=st_httpd_10.0.0.20, userId=d733890d-f5be-449d-8e8e-efab9972fef1, ipAddress=10.0.0.24, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=https://10.0.0.20/protected/redirect_uri, code_id=1d8576e7-69d5-4549-85a6-e014f2a7c14d, username=user1#ovzwk4rr, authSessionParentId=1d8576e7-69d5-4549-85a6-e014f2a7c14d, authSessionTabId=bFfur4XdKlI

As shown above, a successful authentication can be monitored in "Audit Trail". If necessary, information can also be gathered directly by asking the database.

 

Tufin SecureChange

When trying to log authentication at SecureChange, only a log file at the CLI can be evaluated:
     /var/log/tomcat/securechange.log

A successful login is recorded here, e.g. for a local user (hcarr)

INFO 2021-03-16 21:21:22,066 [catalina-exec-19::c.t.s.s.AdminAuthenticatorHelper.performAuthentication] [user:system] authenticating hcarr
INFO 2021-03-16 21:21:22,072 [catalina-exec-19::c.t.s.s.UsernamePasswordAuthenticator.authenticate] [user:system] User ID: 4, User name: Henry Carr logged in.
...

A successful login is recorded here, e.g. for a user authenticated using an LDAP server (user1)

INFO 2021-03-16 21:24:36,345 [catalina-exec-15::c.t.s.s.AdminAuthenticatorHelper.performAuthentication] [user:system] authenticating user1
INFO 2021-03-16 21:24:36,351 [catalina-exec-15::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] Start authentication of user [user1].
INFO 2021-03-16 21:24:36,362 [catalina-exec-15::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] Successful authentication of user [user1]. The authenticated userName is [user1].
INFO 2021-03-16 21:24:36,369 [catalina-exec-15::c.t.s.s.LdapUserResolver.getLoggedInUserFromDb] [user:system] User user1 found in DB by LDAP ID kBxZxiVaE0uwfM5vdPy5pw==. DB id is 43
INFO 2021-03-16 21:24:36,372 [catalina-exec-15::c.t.s.s.UsernamePasswordAuthenticator.authenticate] [user:system] User ID: 43, User name: user1 logged in.
...

Trying wrong credentials (mleu) delivers

INFO 2021-03-16 21:23:52,088 [catalina-exec-18::c.t.s.s.AdminAuthenticatorHelper.performAuthentication] [user:system] authenticating mleu
INFO 2021-03-16 21:23:52,093 [catalina-exec-18::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] Start authentication of user [mleu].
WARN 2021-03-16 21:23:52,099 [catalina-exec-18::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] The authentication of the user [mleu] is failed. User [mleu] does not exist when using filter [(&(sAMAccountType=805306368)(|(sAMAccountName=mleu)(userPrincipalName=mleu)))] and baseDN [cn=users,dc=aerasec,dc=labor].
INFO 2021-03-16 21:23:52,105 [catalina-exec-18::c.t.s.c.l.SCLdapServiceImpl.getLdapUser] [user:system] Searching for LDAP user mleu
INFO 2021-03-16 21:23:52,106 [catalina-exec-18::c.t.s.c.l.SCLdapServiceImpl.getLdapUser] [user:system] Searching for LDAP user mleu in LdapConfiguration Lab_AD
INFO 2021-03-16 21:23:52,114 [catalina-exec-18::c.t.s.c.l.SCLdapServiceImpl.findUserInLdap] [user:system] User not found in LDAP by name [mleu].

In any case, these data need to be forwarded to a central reporting tool.
Forwarding the content of these files can be done e.g., by syslog, using a Splunk Forwarder, or any other method.

 

 

 

Tufin has released TOS R21-1, the first version of the Tufin Orchestration Suite of 2021.

Please be aware that TOS 21-1 requires TufinOS 3.x, CentOS 7, or RHEL 7.

TOS 21-1 is available as GA and can be downloaded from the Tufin Portal (login required). It delivers improvements, e.g.

Change Automation and Orchestration

  • SecureChange can be integrated with SecureCloud now. Automated workflows that include Azure devices can be configured. Importing Azure ASG (Application Security Groups) is possible and therefore using automation tools of SecureChange (e.g. Auto-suggest target, Provisioning) is possible. Designer and Verifier can be used for on-prem devices.
  • When provisioning changes, the Designer of SecureChange used in an Access Request workflow can consider related tickets that might have an impact on the update. Related tickets can be considered when a redesign is done. 
  • The Interactive Map of SecureTrack now allows to add/modify generic devices such as L2 firewalls, generic interfaces, and generic VPN by right-clicking on the mouse.
  • The Interactive Map also supports IPv6 path analysis for generic devices now.
  • SecureTrack Interactive Map supports using LDAP groups in Source and Destination.
  • The Interactive Map allows viewing device data and calculation of paths having Amazon AWS devices included.

Devices and Platforms

  • Amazon AWS
    For Amazon AWS devices the Interactive Map can be used to view device data and paths included in these devices.
  • Check Point
    When using Inline Layers rules configured here, can now be viewed in Policy Browser. From here, SecureChange tickets for rule modification, rule recertification, and rule decommission can be opened.
    Check Point Cloud devices in NSX-T, ACI and AWS can be included in SecureTrack.
  • Cisco
    Support for Cisco IOS-XE routers and L3 devices
  • Juniper
    Juniper SRX is now supported to have IPv6 configuration in SecureTrack Topology.
  • Fortinet
    For Fortinet FortiManager SecureTrack now offers visibility for user IDs and rules on the devices' security rules, the global level, and Adom level.
  • Palo Alto
    Using Panorama allows the use of Shared Objects now in SecureChange. The Designer can be configured to use or create shared objects as part of the automation process.

REST API

  • Error handling
    • Code for unauthorized users has been set to 403 for SecureTrack and SecureChange
    • SecureTrack returns 503 if during synchronization another graph builder is running
  • Improvements for SecureTrack
    • Check Point R80 rule numbering has been improved
    • Getting IPv6 bindings is possible now
    • Mapping zones to device interfaces can be retrieved
    • Rule recertification can now be done via API
  • Improvements for SecureChange
    • Get Security Zone for Access Requests
    • Modify Expiration Date and Reference Ticket ID
    • API returns an error if a device contains multiple objects or services with the same name
    • Import validations added for Rule Modification
    • Support of Panorama tags for Designer

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

 

 

 

 

 

When having SecureChange upgraded to TOS 20-2 and TufinOS 3.x, scripts need a unique path. If the location of a script is "somewhere" on the machine (as before), an error might be shown.

ERROR 2021-02-27 15:00:56,073
[asyncTaskExecuter-19::c.t.s.s.i.ScriptServiceImpl.runScriptAndGetResult] [user:system] Failed to run script java.lang.Exception: Path location is not valid.

To have scripts working in SecureChange, be sure that they are located only here:

/opt/tufin/data/securechange/scripts/
 
 
 
 
 

If you don't have upgraded now, you should consider not to wait too long. Reasons for upgrade are - new version with new features (ok, that's as always if a new version is released), but above all - upgrade of TufinOS to version 3.x based on CentOS 7. This is necessary because TufinOS 2.x is based on CentOS 6 which isn't supported any more since end of November 2020. Additionally, some security issues have been found in CentOS that are fixed inTufinOS 3.x, but will not be fixed for TufinOS 2.x due to EOL. So also this is a reason for upgrading soon.

All information about the upgrade can be found in the Tufin Portal.

 

Requirements for upgrading to TOS 20-2 and TufinOS 3.x are

  • TufinOS 2.21 or higher, or RHEL/CentOS 6
  • TOS R20-1 or R19-3 (any specific HF)
  • Postgres 11 (and not PostgreSQL 9.0 or 9.4)
    This upgrade is mostly done when upgrading to TufinOS 2.21

Be sure that the new server you will install the latest version of TufinOS has at least 500 GB Hard Disk and 16 GB RAM (even for lab installations). Both parameters are checked during the installation of TufinOS. Installation will stop when these requirements are not fulfilled. Anyway, you shold consider the hardware requirements published by Tufin when setting up a new server.

Before beginning the upgrade you need a new machine besides the existing machine. TufinOS as well as TOS will be installed on this new machine. Your configuration as well as data need to be copied to this machine also. Later on you can turn off the old server and change the IP addresses of the new server to the addresses of the old one.
If you don't have a new machine, you need a new hard disk that is going to be mounted to the existing server. All data are saved to this mount point, so they are available afterwards.

 

It's recommended that you follow the "Upgrade Assistance" published by Tufin. It's recommended to download an Upgrade Planner Application that needs to be exectured on each server any component of TOS is running on. Resullt of the execution is a JSON file with all relevant information about this specific installation. Throwing this file into the field of the page mentioned before will guide you to the correct and recommended upgrade procedure.

It's also possible to get upgrade information directly without running the Planner Application or other scripts. It's important to distinguish between the different installation types, e.g. "standalone", "with Distributed Archtecture" or "with High Availability Cluster". The recommended way is to use the Upgrade Assistant since in this case all information is transferred. It's the most safe way to upgrade. If you don't like it, you can also upgrade manually.