Clean Install of TOS Aurora on a Server with RHEL/CentOS

Overview

This procedure is for the clean installation of TOS Aurora on an RHEL (Red Hat Enterprise Linux) or CentOS server. For all other installation paths such as upgrade or other platforms, see the menu for the appropriate procedure.

Supported platforms are: Physical server, VMware ESXi and Microsoft Azure only.

TOS Aurora is deployed together with Kubernetes.

Read and understand Prerequisites before you start.

High Availability (HA)

High availability is not supported in this release

Distributed Deployment Using Remote Collectors

When deployed on-premise, TOS Aurora can be set up to run as a distributed architecture using remote collectors (RC's). In the current version, this is not available for cloud deployments such as Azure.

The current procedure is meant for installing on both central and remote collector clusters. Also see remote collectors.

Prerequisites

General Requirements

  • If you have previously uninstalled TOS Aurora, make sure all data is removed (see Uninstalling) and reboot the server before reinstalling.

  • Some commands must be preceded with screen, see Screen Command.
  • Your servers must have sufficient CPUs, disk storage and main memory for TOS Aurora to work effectively; the resources required can be categorized by system size.

    To evaluate the size of system you need, see Sizing Calculation for a Clean Install.

  • Once TOS Aurora has been installed, changing the host name or IP address will require reinstalling - see Changing IP Address/Host Names. If you want to change the host name of the node, do so before running the tos install command.

    If you need assistance, consult with your sales engineer or Tufin support.

  • Tufin Orchestration Suite should be treated as high-risk security resource, similar to how you would treat any LDAP product (for example, Active Directory). Therefore, you should only install Tufin Orchestration Suite in an appropriately secured network and physical location, and only authorized users should be granted access to TOS products and the operating system on the server.

Azure Requirements (skip for other platforms)

  1. An Azure virtual machine with the following attributes:

    • Image: Red Hat Enterprise Linux/CentOS 7.8 or 7.9

    • OS disk type: Azure Premium SSD

    • OS disk size:

      For medium-sized systems as per Sizing Calculation for a Clean Install

      For all other sized systems, contact Tufin Technical Support

    • CPU and memory as per Sizing Calculation for a Clean Install
    • Open destination ports: 31443, 31617, 31514, 31099, 31843, 30161, 30514, 31161 - see Ports and Services

    • One additional disk:

      • SSD with 7,500 IOPS and 250MB/s throughput or higher
      • Disk size as per Sizing Calculation for a Clean Install
      • An XFS partition mounted to directory /tmp

      • An XFS partition mounted to new directory /var

      • An XFS partition mounted to directory /opt

      • Allocated sizes no less than:

          /tmp/ /var/
        Central cluster, initial data node 25 GB 200GB
        Central cluster, worker node 25 GB 60GB
        Remote collector cluster, initial data node 25 GB 60GB
        Remote collector cluster, worker node 25 GB 60GB

        In addition, you need to set up the /opt partition. The /opt partition will contain your data, which will increase over time. We therefore recommend allocating all remaining disk space after you have partitioned the other directories. For assistance, consult with your sales engineer or Tufin support.

    If you are not familiar with setting up Azure VMs, the following procedures will assist you:

  2. Load balancer for the above VM, with the following attributes:

    • Health probe configured for port: 31443
    • Rules - see Ports and Services to see why:

      • Protocol TCP, Port 443, backend port 31443
      • Protocol TCP, Port 61617, backend port 31617
      • Protocol TCP, Port 6514, backend port 31514
      • Protocol TCP, Port 9099, backend port 31099
      • Protocol TCP, Port 8443, backend port 31843
      • Protocol UDP, Port 161, backend port 30161
      • Protocol UDP, Port 514, backend port 30514
      • Protocol UDP, Port 10161, backend port 31161

    If you are not familiar with setting up Azure load balancers, the following procedure will assist you:

  3. In the current release, TOS Aurora on Azure can support systems up to medium size only.

Linux OS Requirements

For a step-by-step guide to configuring most of the requirements below, see Configuring RHEL and CentOS.

  • The new TOS Aurora server must be running Red Hat Enterprise Linux/CentOS 7.8 or 7.9
  • Disk(s) SSD with 7,500 IOPS and 250MB/s throughput or higher.

  • Disk partitioned to at least these sizes:

      /tmp/ /var/
    Central cluster, initial data node 25 GB 200GB
    Central cluster, worker node 25 GB 60GB
    Remote collector cluster, initial data node 25 GB 60GB
    Remote collector cluster, worker node 25 GB 60GB

    In addition, you need to set up the /opt partition. The /opt partition will contain your data, which will increase over time. We therefore recommend allocating all remaining disk space after you have partitioned the other directories. For assistance, consult with your sales engineer or Tufin support.

    For assistance with disk partitioning, see Increasing the Partition Size on a Virtual Machine.

  • The kernel must be up-to-date
  • SELinux must be disabled
  • rsync, wireguard and screen must be installed for transferring data, in-cluster encryption and launching shell sessions respectively
  • Required modules must get loaded using a configuration file /etc/modules-load.d/tufin.conf containing entries:

    br_netfilter
    wireguard
    overlay
    ebtables
    ebtable_filter
    
  • Permanent kernel parameters must be set. Example: via a configuration file /etc/sysctl.d/tufin.conf containing entries:

    net.bridge.bridge-nf-call-iptables = 1
    fs.inotify.max_user_watches = 1048576
    fs.inotify.max_user_instances=10000
    net.ipv4.ip_forward = 1
  • Network configurations for your interface must be set to manual IPv4 with gateway and DNS Servers set to the IPs used by your organization.

  • You must have permissions to execute TOS CLI commands located in directory /user/local/bin/tos and to use sudo if necessary.

  • If you want to run TOS CLI commands without specifying the full path (/user/local/bin/tos), your environment path must be modified accordingly

  • The server timezone must be set.

  • Download file "Tufin Orchestration Suite Aurora R21-1 GA (clean install only)" from the download center.

Network Requirements

  • You must allow access to required Ports and Services.
  • A 24-bit CIDR subnet on your network must be dedicated to TOS Aurora for internal use. It must not overlap with CIDR 10.244.0.0/16 or with the physical and VIP network addresses of your TOS Aurora servers (see below) and if a proxy is configured on your system, make sure this subnet is excluded.
  • You must have available the following dedicated IP addresses:

    • For on-premise deployments, a primary VIP that will serve as the external  IP address used to access TOS Aurora from your browser. The primary VIP will not be needed in the installation, except in the final step - the installation command.
    • For cloud deployments, an external loadbalancer IP that will serve as the IP address used to access TOS Aurora from your browser. This IP will be needed when setting up the load balancer in your cloud vendor account. It is not needed in the TOS Aurora installation.
    • The physical network IP that will serve as the internal IP address used by the administrator for CLI commands and this is the one you will use in most steps of the procedure.
    • If additional nodes are subsequently added to the cluster, each node will require an additional dedicated physical network IP.

    • Additional syslog VIPs can be allocated as needed.
    • The VIP, all node physical network IPs and all syslog VIPs must be on the same subnet.

  • Make sure your physical interfaces are correctly configured on the network and if you have more than one active interface, ensure that each one is connected to a different VLAN. Otherwise, you may experience connection issues.

The Install Procedure

Before you proceed, read and understand Prerequisites - this may prevent unexpected failures.

Prepare the Installation File

  1. If not done already, transfer the run file downloaded previously, to the TOS Aurora server that will become the initial data node. If not unzipped, unzip now. This will give you a single run file in the format XX-Y-ZZZZ.run, where XX indicates release year, Y represents the release sequence and ZZZZ represents the release type, e.g. 21-1-PGA.

  2. Execute the run file:

    [TOS Aurora server]# sudo sh XX-Y-ZZZZ.run

Install TOS Aurora

  1. Run the screen command:

    [user@TOS 2.0 server]# screen -S install

  2. Run the install command, replacing the parameters:

    • <VIP> either with the external IP you will use to access TOS Aurora or with the text external if you are installing on Azure
    • <SERVICE-CIDR> with the CIDR you want TOS Aurora to use, as described in Prerequisites.
    • <MODULE-TYPE> with one of the following values:

      • ST for SecureTrack only
      • ST, SC for both SecureTrack and SecureChange
      • RC for a remote collector

    [user@TOS 2.0 server]# sudo tos install --modules=<MODULE-TYPE> --loadbalancer-ip=<VIP> --services-network=<SERVICE-CIDR>

    Examples:

    # sudo tos install --modules=ST,SC --loadbalancer-ip=192.168.1.2 --services-network=10.10.10.0/24

    # sudo tos install --modules=RC --loadbalancer-ip=external --services-network=10.10.10.0/24

  3. The EULA is displayed. After reading, enter 'q' to exit the document and then enter 'y' to accept the EULA and continue until the command completes.

  4. You can now safely exit the CLI screen session:

    [user@TOS 2.0 server]# exit

  5. If the installation was for a central (main) cluster, you can now log into TOS Aurora at https://<VIP>, using your browser. Log in with user=admin, password=admin. If a warning message is shown regarding the site security certificate, 'accept the risk' and continue to the site. You will be prompted to set a new password.

    If the installation was for a remote collector, continue with connecting the remote collector.

Post-Install Configuration

SSL Certificates

Secured connections to TOS Aurora require a valid SSL certificate. Such a certificate is generated during the installation. It is automatically renewed when it expires and also when upgrading to later versions of TOS Aurora. When connecting for the first time after certificate renewal, you will be prompted to accept the new certificate. You can also use your own CA signed certificate, but such certificates will not be renewed automatically.

License Activation

Relevant only for central clusters, skip for remote collectors.

Follow the instructions in Activate License.

Using Syslog for Accountability and More

You can use syslog to send accountability and other information from your devices to SecureTrack - see Sending Additional Information via Syslog. If you want to use this feature and you have installed TOS on-premise, you must also set up a Syslog VIP Address.

Adding Nodes to Your Cluster

TOS Aurora is now deployed as a single node Kubernetes cluster. See Multi-Node Processing for more information about adding additional nodes.

Setting up Scheduled Backups

We recommend creating a backup policy as soon as possible - see Backup Procedure.

SecureChange Settings

Relevant only for central clusters, skip for remote collectors.

If you have SecureChange:

  1. If you are not logged in to SecureTrack, log in at https://<IP>, where <IP> is the cluster VIP, with SecureTrack user=admin, password=admin. You will be prompted to change the password the first time you log in. If a warning message is shown regarding the site security certificate, 'accept the risk' and continue to the site.
  2. Create a new SecureTrack administrator user that SecureChange will use to get SecureTrack information. If you have already configured multi-domain management, make this user either a super administrator or multi-domain administrator, depending on whether you want to restrict the administrator to selected domains.
  3. Log in to SecureChange at https://<IP>/securechangeworkflow, where <IP> is the cluster VIP or external load-balancer IP, with user=admin, password=admin. You will be prompted to change the password. SecureChange users are separate from SecureTrack users; there is no connection between a SecureTrack user and SecureChange user having the same name.

    On the prompt window, you can also enter an email address for administrative email notifications. We recommend using the address of an email list so you can easily edit the list of recipients.

  4. Go to Settings>Miscellaneous.

  5. Enter a value for Server DNS name - the DNS server to use for links in email notifications. This can be an IP address in the format 11.22.33.44 or a FQDN in the format https://mydomain.com. The SecureChange DNS name is published by SecureChange so it can be accessed from external sources. For example, it is embedded in notification mails sent by SecureChange, which include a link to a ticket, such as an email notifying a handler assigned with a task, or informing a requester that the ticket has been successfully resolved.

  6. Go to Settings > SecureTrack:

  7. Enter the SecureTrack administrator username, created previously.
  8. If you want a link to SecureTrack to be available in the SecureChange applications icon, select Show link to SecureTrack .

  9. If you want to change how often SecureChange tests its connectivity to SecureTrack, change the value of Connection check interval.
  10. Click Test connection to verify that SecureChange has a connection to SecureTrack.
  11. Click Save.
  12. Additional setup can be done now or later:

  13. You can enter SecureChange also from SecureTrack:

    • In SecureTrack, click > SecureChange.

    • If not already logged in to SecureChange, log in at the prompt.