Security

Tranzman is loaded with multiple security features.

Operating system

• Tranzman Appliance (OVA/ISO deployment) is based on RHEL 8.6 source.
• CLISH can only be accessed through either of these accounts: admin / P@ssw0rd or srladmin / SRLP@ssw0rd

admin user is for initial network setup.

srladmin user is for support and troubleshoot.

• Access to SHELL is restricted to Stone Ram support.
• System disk is encrypted for unauthorized access and modification.
• Additional Enhanced security enforcement prevents access to root disk other than normal booting process and so tampering or modifying the boot process will result in system start up failure.

Networking

• Tranzman use a single NIC to connect to both the ORIGIN and DESTINATION servers.
• By default, it uses the Secure communication (SSL) on port 55560 and uses port range from 55501 to 55555 for Legacy communication (obfuscated FTP)
• For administration of the Tranzman server:

• WebUI uses HTTPS (port 443) for all communications.

• CLISH is accessible over SSH (port 22).

• For NTP, port 123 (UDP) should be bidirectional.

• Port 53 (UDP and TCP) needs to be opened for DNS service.

• For Cross Vendor or Recovery Without Vendor with NFS or CIFS shares for sharing backup image data, ports 139, 445, 137 and 138 is used between the server with the storage and the Tranzman sever, or between the Tranzman server and the destination server or a recovery client.

Authentication security

Tranzman Agent (TZMTD)

It uses client certificate for authentication. Certificate is protected by packaging it within the agent installer binary. It uses Agent as user role.

WebUI (HTTPS)

This uses Admin as user role with a simple User/Password combination for Authentication. However, the credential is secured by mangled MD5 password hash.

Web application security

Web security is always a concern with increasing vulnerabilities. Tranzman has addressed majority of those issues and the below list has the Risk and the mitigations.

Risk 

Broken Authentication

Mitigation 

AGENT or client authentication is a part of TLS protocol. CA never leaves TZM appliance.

Request from Trusted Agent (IP addresses) alone are allowed to connect to the appliance. GUI/User interface uses connections on port 443.

Risk 

Sensitive Data Exposure

Mitigation 

TZM keeps the metadata of the NBU catalog (hostnames, policies, backup size, storage configuration, tape encryption keys, encrypted storage passwords) and some client (hostname, IP, NBU version) data in its internal database.

Access to Encryption keys and encrypted passwords is not accessible from the web interface.  It is accessible through agent only during migration for the destination agent.

Risk 

XML External Entities

Mitigation 

Uses REST and any XML content type is rejected.

Risk 

Broken Access Control

Mitigation 

Agent name is referred in CN of the certificate and without that, client is not allowed to perform any task. Agents can only access data exposed for them but not the other agents.

Risk 

Security Misconfiguration

Mitigation 

Security comes out of the box with no additional user configuration and so avoids the risk of misconfiguration.

Risk 

Using components with known Vulnerabilities

Mitigation 

Undergoes periodic scans on appliance with the Qualys.

Risk 

Cross Site Request Forgery (CSRF)

Mitigation 

This is not applicable for Agent. Client is CURL.

GUI has no dedicated CSRF protection. Tranzman appliance is not a public internet page. It only exists for the duration of migration and decommissioned post migration.

Authentication flow

Agent / TZMTD – Tranzman Transfer Daemon

• TZMCURL Agent -> TLS connection established (client certificate authorizes) -> client certificate CN authenticated by the TZMTD server-> access allowed

WEB Browser User Interface / HTTPS

• Browser -> TLS connection established -> user/password provided -> Auth tokens (reissue and active with 30 minutes TTL) issued -> New request send with `Auth` header -> access allowed
• Browser -> TLS connection established -> Active token TTL expired -> Reissue token provided -> Active auth token with 30 minutes TTL issued -> New request send with `Auth` header -> access allowed

WebUI certificate

Tranzman uses self-signed certificate for authentication.