Difference between revisions of "Security"

From Tranzman Documentation
Jump to: navigation, search
Line 1: Line 1:
−
Tranzman is loaded with multiple security features.
+
== Security Features in Tranzman ==
  
−
===Operating system===
+
Tranzman is equipped with multiple security features to ensure data integrity and system protection.
−
* Tranzman Appliance (OVA/ISO deployment) is based on RHEL 8.6 source.
 
−
* CLISH can only be accessed through either of these accounts: <font style="color: blue"> '''admin'''</font> / <font style="color: blue">'''P@ssw0rd''' </font>  or  <font style="color:blue"> '''srladmin'''</font> / <font style="color: blue">''' SRLP@ssw0rd''' </font>
 
  
−
::'''admin''' user is for initial network setup.
+
=== Operating System ===
  
−
::'''srladmin''' user is for support and troubleshoot.
+
* Tranzman Appliance (OVA/ISO deployment) is built on RHEL 8.6 sources.
 +
* CLISH access is restricted to the following user accounts:
 +
** <font style="color: blue">'''admin'''</font> / <font style="color: blue">'''P@ssw0rd'''</font> - for initial network setup.
 +
** <font style="color: blue">'''srladmin'''</font> / <font style="color: blue">'''SRLP@ssw0rd'''</font> - 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.
  
−
* Access to SHELL is restricted to Stone Ram support.
+
=== Networking ===
−
* 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.
 
  
 +
* 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'''.
  
−
===Networking===
+
=== Authentication Security ===
−
* 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.
+
; '''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.
  
−
::* CLISH is accessible over SSH (port '''22''').
+
; '''WebUI (HTTPS)'''
 +
: Uses the ''Admin'' user role with a username/password authentication secured by mangled MD5 password hashing.
  
−
::* For NTP, port '''123''' (UDP) should be bidirectional.
+
=== Web Application Security ===
  
−
::* Port '''53''' (UDP and TCP) needs to be opened for DNS service.
+
Web security remains a high priority with Tranzman, addressing common vulnerabilities through proactive risk mitigation.
  
−
::* 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.
+
; '''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.
  
−
===Authentication security===
+
; '''Risk: XML External Entities'''
 +
: '''Mitigation:'''
 +
:: Tranzman exclusively uses REST API, rejecting any XML content type.
  
−
; Tranzman Agent (TZMTD)
+
; '''Risk: Broken Access Control'''
−
: It uses client certificate for authentication. Certificate is protected by packaging it within the agent installer binary. It uses ''Agent'' as user role.
+
: '''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.
  
−
; WebUI (HTTPS)
+
; '''Risk: Security Misconfiguration'''
−
: This uses ''Admin'' as user role with a simple User/Password combination for Authentication. However, the credential is secured by mangled MD5 password hash.
+
: '''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.
  
−
===Web application security===
+
; '''Risk: Cross-Site Request Forgery (CSRF)'''
−
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.
+
: '''Mitigation:'''
−
;Risk : ''Broken Authentication''
+
:: CSRF protection is not necessary for the agent, as the client operates via CURL.
−
;Mitigation :
+
:: The GUI does not require dedicated CSRF protection since the Tranzman appliance is not publicly accessible and is decommissioned after migration.
−
: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''
+
=== Authentication Flow ===
−
;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''
+
'''Agent / TZMTD – Tranzman Transfer Daemon'''
−
;Mitigation :
+
* TZMCURL Agent → TLS connection established (client certificate authorization) → CN authentication → access granted.
−
:Uses REST and any XML content type is rejected.
 
  
−
;Risk : ''Broken Access Control''
+
'''Web Browser User Interface / HTTPS'''
−
;Mitigation :
+
* Browser → TLS connection established → user/password authentication → Auth tokens issued (valid for 30 minutes) → request sent with `Auth` header → access granted.
−
: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.
+
* Browser → Active token TTL expired → Reissue token provided → new auth token issued (valid for 30 minutes) → request sent with `Auth` header → access granted.
  
−
;Risk : ''Security Misconfiguration''
+
=== WebUI Certificate ===
−
;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''
+
Tranzman employs a self-signed certificate for authentication.
−
;Mitigation :
 
−
:Undergoes periodic scans on appliance with the Qualys.
 
  
−
;Risk : Cross Site Request Forgery (CSRF)
+
{| class="wikitable" style="margin:auto;width:100%;color:blue;text-align:center;border-style:ridge;"
−
;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.
 
−
 
 
−
 
 
−
 
 
−
 
 
−
{| class="wikitable" style="margin:auto;width:100%;color:blue;text-align:center;borderstyle=ridge;"
 
 
|-
 
|-
 
| [[Image:prev_icon.jpg|30px|link=Architecture]]
 
| [[Image:prev_icon.jpg|30px|link=Architecture]]
 
|| [[Image:next_icon.jpg|30px|link=Planning]]
 
|| [[Image:next_icon.jpg|30px|link=Planning]]
 
|}
 
|}

Revision as of 15:20, 27 May 2025

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.

Prev icon.jpg Next icon.jpg
Retrieved from "https://docs.stoneram.com/index.php?title=Security&oldid=3409"