Difference between revisions of "Security"

Revision as of 04:43, 15 March 2023

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.