Difference between revisions of "Security"
From Tranzman Documentation
(→Authentication Security) |
(→Web Application Security) |
||
| Line 36: | Line 36: | ||
Web security remains a high priority with Tranzman, addressing common vulnerabilities through proactive risk mitigation. | Web security remains a high priority with Tranzman, addressing common vulnerabilities through proactive risk mitigation. | ||
| − | + | ====Risk: Broken Authentication==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: AGENT or client authentication is integrated into the TLS protocol, ensuring CA never leaves the Tranzman appliance. | :: AGENT or client authentication is integrated into the TLS protocol, ensuring CA never leaves the Tranzman appliance. | ||
:: Connections are restricted to Trusted Agents (authorized IP addresses), while GUI interactions are strictly controlled via port 443. | :: Connections are restricted to Trusted Agents (authorized IP addresses), while GUI interactions are strictly controlled via port 443. | ||
| − | + | ====Risk: Sensitive Data Exposure==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: Tranzman securely stores metadata such as NBU catalog details (hostnames, policies, backup size, storage configurations, encrypted credentials) in an internal database. | :: Tranzman securely stores metadata such as NBU catalog details (hostnames, policies, backup size, storage configurations, encrypted credentials) in an internal database. | ||
:: Encryption keys and credentials remain inaccessible through the web interface and are only retrievable via the agent during migration. | :: Encryption keys and credentials remain inaccessible through the web interface and are only retrievable via the agent during migration. | ||
| − | + | ====Risk: XML External Entities==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: Tranzman exclusively uses REST API, rejecting any XML content type. | :: Tranzman exclusively uses REST API, rejecting any XML content type. | ||
| − | + | ====Risk: Broken Access Control==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: Agents are validated via certificate CN before performing any tasks. | :: Agents are validated via certificate CN before performing any tasks. | ||
:: Each agent can only access its designated data; cross-agent data access is restricted. | :: Each agent can only access its designated data; cross-agent data access is restricted. | ||
| − | + | ====Risk: Security Misconfiguration==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: Security measures are built-in out-of-the-box, minimizing risks associated with user misconfiguration. | :: Security measures are built-in out-of-the-box, minimizing risks associated with user misconfiguration. | ||
| − | + | ====Risk: Using Components with Known Vulnerabilities==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: Tranzman undergoes periodic vulnerability scans using Qualys. | :: Tranzman undergoes periodic vulnerability scans using Qualys. | ||
| − | + | ====Risk: Cross-Site Request Forgery (CSRF)==== | |
: '''Mitigation:''' | : '''Mitigation:''' | ||
:: CSRF protection is not necessary for the agent, as the client operates via CURL. | :: CSRF protection is not necessary for the agent, as the client operates via CURL. | ||
Revision as of 13:07, 29 June 2025
Contents
Security Features in Tranzman
Tranzman is equipped with multiple security features to ensure data integrity and system protection.
Operating System
- Tranzman Appliance (OVA/ISO deployment) is built on RHEL 8.6 sources.
- CLISH access is restricted to the following user accounts:
- admin / P@ssw0rd - for initial network setup.
- srladmin / SRLP@ssw0rd - for support and troubleshooting.
- Access to SHELL is restricted exclusively to Stone Ram support.
- System disk encryption prevents unauthorized access and modification.
- Enhanced security enforcement blocks root disk access outside of the normal booting process, ensuring tampering or modifying the boot process results in system startup failure.
Networking
- Tranzman uses a single NIC to connect to both ORIGIN and DESTINATION servers.
- Secure communication is established via SSL on port 55560, while legacy communication (obfuscated FTP) operates within the port range 55501-55555.
- Administration of the Tranzman server is handled via:
- WebUI over HTTPS (port 443).
- CLISH access via SSH (port 22).
- NTP synchronization using UDP port 123 (bidirectional).
- DNS service utilizing UDP and TCP port 53.
- Cross Vendor or Recovery Without Vendor communication via NFS/CIFS shares uses ports 139, 445, 137, and 138.
Authentication Security
Tranzman Agent (TZMTD)
- Utilizes client certificates for authentication, ensuring security by packaging certificates within the agent installer binary. The agent operates under the Agent user role.
WebUI (HTTPS)
- Uses the Admin user role with a username/password authentication secured by mangled MD5 password hashing.
Web Application Security
Web security remains a high priority with Tranzman, addressing common vulnerabilities through proactive risk mitigation.
Risk: Broken Authentication
- Mitigation:
- AGENT or client authentication is integrated into the TLS protocol, ensuring CA never leaves the Tranzman appliance.
- Connections are restricted to Trusted Agents (authorized IP addresses), while GUI interactions are strictly controlled via port 443.
Risk: Sensitive Data Exposure
- Mitigation:
- Tranzman securely stores metadata such as NBU catalog details (hostnames, policies, backup size, storage configurations, encrypted credentials) in an internal database.
- Encryption keys and credentials remain inaccessible through the web interface and are only retrievable via the agent during migration.
Risk: XML External Entities
- Mitigation:
- Tranzman exclusively uses REST API, rejecting any XML content type.
Risk: Broken Access Control
- Mitigation:
- Agents are validated via certificate CN before performing any tasks.
- Each agent can only access its designated data; cross-agent data access is restricted.
Risk: Security Misconfiguration
- Mitigation:
- Security measures are built-in out-of-the-box, minimizing risks associated with user misconfiguration.
Risk: Using Components with Known Vulnerabilities
- Mitigation:
- Tranzman undergoes periodic vulnerability scans using Qualys.
Risk: Cross-Site Request Forgery (CSRF)
- Mitigation:
- CSRF protection is not necessary for the agent, as the client operates via CURL.
- The GUI does not require dedicated CSRF protection since the Tranzman appliance is not publicly accessible and is decommissioned after migration.
Authentication Flow
Agent / TZMTD – Tranzman Transfer Daemon
- TZMCURL Agent → TLS connection established (client certificate authorization) → CN authentication → access granted.
Web Browser User Interface / HTTPS
- Browser → TLS connection established → user/password authentication → Auth tokens issued (valid for 30 minutes) → request sent with `Auth` header → access granted.
- Browser → Active token TTL expired → Reissue token provided → new auth token issued (valid for 30 minutes) → request sent with `Auth` header → access granted.
WebUI Certificate
Tranzman employs a self-signed certificate for authentication.
| |
|