Difference between revisions of "Security"

From Tranzman Documentation
Jump to: navigation, search
(→‎Web Application Security)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
== Security Features in Tranzman ==
+
__TOC__
 +
<br>
 +
<br>
 +
<div style="background-color:#fde9e9; padding: 1.5rem; text-align:center; border-radius:8px; max-width:80%; margin: 0 auto; margin-bottom:2rem; ">
 +
  <h1 style="border-bottom:none; font-size:2.5em; font-weight:bold;">Tranzman Security Features</h1>
 +
  <p style="font-size:1.2em; text-align:left;">
 +
    Tranzman is equipped with multiple security features to ensure data integrity and system protection across all migration scenarios.<br>
 +
    Security is enforced at the operating system, network, authentication, and application levels.
 +
  </p>
 +
</div>
  
−
Tranzman is equipped with multiple security features to ensure data integrity and system protection.
+
<div style="max-width:80%; margin: 0 auto;">
  
−
=== Operating System ===
+
  <div style="background-color:#edf7ff; padding:1.5rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); margin-bottom:2rem;">
 +
    <h2 style="border-bottom:2px solid #bbdefb; padding-bottom:0.5rem; font-size:1.5em;">Operating System Security</h2>
 +
    <ul>
 +
      <li>Tranzman Appliance (OVA/ISO deployment) is built on <b>RHEL 8.6</b> sources.</li>
 +
      <li>CLISH access is restricted to:
 +
        <ul>
 +
          <li><span style="color:blue;"><b>admin</b></span> / <span style="color:blue;"><b>P@ssw0rd</b></span> (initial network setup)</li>
 +
          <li><span style="color:blue;"><b>srladmin</b></span> / <span style="color:blue;"><b>SRLP@ssw0rd</b></span> (support & troubleshooting)</li>
 +
        </ul>
 +
      </li>
 +
      <li>SHELL access is exclusive to Stone Ram support.</li>
 +
      <li>System disk encryption prevents unauthorized access and modification.</li>
 +
      <li>Enhanced security enforcement blocks root disk access outside normal booting; tampering with the boot process causes startup failure.</li>
 +
    </ul>
 +
  </div>
  
−
* Tranzman Appliance (OVA/ISO deployment) is built on RHEL 8.6 sources.
+
  <div style="background-color:#fef3f7; padding:1.5rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); margin-bottom:2rem;">
−
* CLISH access is restricted to the following user accounts:
+
    <h2 style="border-bottom:2px solid #f8bbd0; padding-bottom:0.5rem; font-size:1.5em;">Networking Security</h2>
−
** <font style="color: blue">'''admin'''</font> / <font style="color: blue">'''P@ssw0rd'''</font> - for initial network setup.
+
    <ul>
−
** <font style="color: blue">'''srladmin'''</font> / <font style="color: blue">'''SRLP@ssw0rd'''</font> - for support and troubleshooting.
+
      <li>Single NIC connects to both ORIGIN and DESTINATION servers.</li>
−
* Access to SHELL is restricted exclusively to Stone Ram support.
+
      <li>Secure communication via SSL on port <b>55560</b>; legacy (obfuscated FTP) uses ports <b>55501-55555</b>.</li>
−
* System disk encryption prevents unauthorized access and modification.
+
      <li>Administration:
−
* 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.
+
        <ul>
 +
          <li>WebUI over HTTPS (<b>443</b>)</li>
 +
          <li>CLISH via SSH (<b>22</b>)</li>
 +
          <li>NTP sync (UDP <b>123</b>, bidirectional)</li>
 +
          <li>DNS (UDP/TCP <b>53</b>)</li>
 +
          <li>NFS/CIFS shares for cross-vendor/recovery (<b>139, 445, 137, 138</b>)</li>
 +
        </ul>
 +
      </li>
 +
    </ul>
 +
  </div>
  
−
=== Networking ===
+
  <div style="background-color:#eff8f0; padding:1.5rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); margin-bottom:2rem;">
 +
    <h2 style="border-bottom:2px solid #c8e6c9; padding-bottom:0.5rem; font-size:1.5em;">Authentication Security</h2>
 +
    <ul>
 +
      <li><b>Tranzman Agent (TZMTD):</b> Uses client certificates for authentication, packaged within the agent installer. Operates under the <b>Agent</b> user role.</li>
 +
      <li><b>WebUI (HTTPS):</b> Uses <b>Admin</b> user role with username/password authentication, secured by mangled MD5 password hashing.</li>
 +
    </ul>
 +
  </div>
  
−
* Tranzman uses a single NIC to connect to both ORIGIN and DESTINATION servers.
+
  <div style="background-color:#fffbf4; padding:1.5rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); margin-bottom:2rem;">
−
* Secure communication is established via SSL on port '''55560''', while legacy communication (obfuscated FTP) operates within the port range '''55501-55555'''.
+
    <h2 style="border-bottom:2px solid #ffe0b2; padding-bottom:0.5rem; font-size:1.5em;">Web Application Security</h2>
−
* Administration of the Tranzman server is handled via:
+
    <ul style="padding-left:0; list-style:none;">
−
** WebUI over HTTPS (port '''443''').
+
      <li style="margin-bottom:1rem;"><b>Broken Authentication:</b> Agent/client authentication integrated into TLS; CA never leaves appliance. Trusted Agents only; GUI restricted to port 443.</li>
−
** CLISH access via SSH (port '''22''').
+
      <li style="margin-bottom:1rem;"><b>Sensitive Data Exposure:</b> Metadata (hostnames, policies, backup size, storage configs, encrypted credentials) stored securely. Encryption keys/credentials not accessible via web interface.</li>
−
** NTP synchronization using UDP port '''123''' (bidirectional).
+
      <li style="margin-bottom:1rem;"><b>XML External Entities:</b> Only REST API is used; XML content type rejected.</li>
−
** DNS service utilizing UDP and TCP port '''53'''.
+
      <li style="margin-bottom:1rem;"><b>Broken Access Control:</b> Agents validated via certificate CN; each agent accesses only its designated data.</li>
−
** Cross Vendor or Recovery Without Vendor communication via NFS/CIFS shares uses ports '''139, 445, 137, and 138'''.
+
      <li style="margin-bottom:1rem;"><b>Security Misconfiguration:</b> Security measures are built-in, minimizing user misconfiguration risks.</li>
 +
      <li style="margin-bottom:1rem;"><b>Known Vulnerabilities:</b> Periodic vulnerability scans using Qualys.</li>
 +
      <li style="margin-bottom:1rem;"><b>Cross-Site Request Forgery (CSRF):</b> Not required for agent (uses CURL); GUI not publicly accessible and decommissioned after migration.</li>
 +
    </ul>
 +
  </div>
  
−
=== Authentication Security ===
+
  <div style="background-color:#edf7ff; padding:1.5rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); margin-bottom:2rem;">
 +
    <h2 style="border-bottom:2px solid #bbdefb; padding-bottom:0.5rem; font-size:1.5em;">Authentication Flow</h2>
 +
    <ul>
 +
      <li><b>Agent / TZMTD – Tranzman Transfer Daemon:</b><br>
 +
        TZMCURL Agent → TLS connection (client certificate authorization) → CN authentication → access granted.
 +
      </li>
 +
      <li><b>Web Browser User Interface / HTTPS:</b><br>
 +
        Browser → TLS connection → user/password authentication → Auth tokens issued (30 min) → requests sent with <code>Auth</code> header → access granted.<br>
 +
        Token expired → reissue token provided → new token issued (30 min) → requests sent with <code>Auth</code> header → access granted.
 +
      </li>
 +
    </ul>
 +
  </div>
  
−
====Tranzman Agent (TZMTD)====
+
  <div style="background-color:#fef3f7; padding:1.5rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); margin-bottom:2rem;">
−
: Utilizes client certificates for authentication, ensuring security by packaging certificates within the agent installer binary. The agent operates under the ''Agent'' user role.
+
    <h2 style="border-bottom:2px solid #f8bbd0; padding-bottom:0.5rem; font-size:1.5em;">WebUI Certificate</h2>
 +
    <ul>
 +
      By default, Tranzman will use a self‑signed certificate for HTTPS traffic. 
 +
If you need to have a trusted certificate authority, please follow the steps below to create and deploy your own certificate.
  
−
====WebUI (HTTPS)====
+
== Steps ==
−
: Uses the ''Admin'' user role with a username/password authentication secured by mangled MD5 password hashing.
 
  
 +
# Select '''System > Certificates''' from the navigation menu. 
 +
# Fill in the Certificate Request information. (All fields are optional.) 
 +
# Press '''Generate''' to create a new Certificate Request. 
 +
# Copy the Certificate Request and send it to the Certificate Authority for signing. 
 +
# Copy and paste the signed Certificate into the right text field. 
 +
# Press '''Submit''' and wait for Tranzman to update the certificate and restart web services. 
  
−
=== Web Application Security ===
+
  <div style="background-color:#f8e2b3; padding:0.2rem; border-radius:8px; box-shadow:0 2px 4px rgba(0,0,0,0.06); font-size:1em; margin: 0 auto;">
 +
    <p>🛈 <i>This process can take few minutes.<br>
 +
      The certificate request and signed certificate must be handled securely.<br>
 +
      Restarting web services may temporarily interrupt access to the WebUI.
 +
    </i>
 +
    </p>
 +
  </div>
  
−
Web security remains a high priority with Tranzman, addressing common vulnerabilities through proactive risk mitigation.
+
    </ul>
 +
  </div>
  
−
====Risk: Broken Authentication====
+
</div>
−
: '''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====
+
<div style="display:flex; justify-content:space-between; margin-top:2rem; padding:1rem; background-color:#ffffff; max-width:90%; margin: 2rem auto 0;">
−
: '''Mitigation:'''
+
  <div style="text-align:left;">
−
:: Tranzman securely stores metadata such as NBU catalog details (hostnames, policies, backup size, storage configurations, encrypted credentials) in an internal database.
+
    [[File:prev_icon.jpg|30px|link=Architecture]] [[Architecture|Previous]]
−
:: Encryption keys and credentials remain inaccessible through the web interface and are only retrievable via the agent during migration.
+
  </div>
−
 
+
  <div style="text-align:right;">
−
====Risk: XML External Entities====
+
    [[Planning|Next]] [[File:next_icon.jpg|30px|link=Planning]]
−
: '''Mitigation:'''
+
  </div>
−
:: 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.
 
−
 
 
−
 
 
−
{| class="wikitable" style="margin:auto;width:100%;color:blue;text-align:center;border-style:ridge;"
 
−
|-
 
−
| [[Image:prev_icon.jpg|30px|link=Architecture]]
 
−
|| [[Image:next_icon.jpg|30px|link=Planning]]
 
−
|}
 

Latest revision as of 08:34, 26 June 2026



Tranzman Security Features

Tranzman is equipped with multiple security features to ensure data integrity and system protection across all migration scenarios.
Security is enforced at the operating system, network, authentication, and application levels.

Operating System Security

  • Tranzman Appliance (OVA/ISO deployment) is built on RHEL 8.6 sources.
  • CLISH access is restricted to:
    • admin / P@ssw0rd (initial network setup)
    • srladmin / SRLP@ssw0rd (support & troubleshooting)
  • SHELL access is exclusive to Stone Ram support.
  • System disk encryption prevents unauthorized access and modification.
  • Enhanced security enforcement blocks root disk access outside normal booting; tampering with the boot process causes startup failure.

Networking Security

  • Single NIC connects to both ORIGIN and DESTINATION servers.
  • Secure communication via SSL on port 55560; legacy (obfuscated FTP) uses ports 55501-55555.
  • Administration:
    • WebUI over HTTPS (443)
    • CLISH via SSH (22)
    • NTP sync (UDP 123, bidirectional)
    • DNS (UDP/TCP 53)
    • NFS/CIFS shares for cross-vendor/recovery (139, 445, 137, 138)

Authentication Security

  • Tranzman Agent (TZMTD): Uses client certificates for authentication, packaged within the agent installer. Operates under the Agent user role.
  • WebUI (HTTPS): Uses Admin user role with username/password authentication, secured by mangled MD5 password hashing.

Web Application Security

  • Broken Authentication: Agent/client authentication integrated into TLS; CA never leaves appliance. Trusted Agents only; GUI restricted to port 443.
  • Sensitive Data Exposure: Metadata (hostnames, policies, backup size, storage configs, encrypted credentials) stored securely. Encryption keys/credentials not accessible via web interface.
  • XML External Entities: Only REST API is used; XML content type rejected.
  • Broken Access Control: Agents validated via certificate CN; each agent accesses only its designated data.
  • Security Misconfiguration: Security measures are built-in, minimizing user misconfiguration risks.
  • Known Vulnerabilities: Periodic vulnerability scans using Qualys.
  • Cross-Site Request Forgery (CSRF): Not required for agent (uses CURL); GUI not publicly accessible and decommissioned after migration.

Authentication Flow

  • Agent / TZMTD – Tranzman Transfer Daemon:
    TZMCURL Agent → TLS connection (client certificate authorization) → CN authentication → access granted.
  • Web Browser User Interface / HTTPS:
    Browser → TLS connection → user/password authentication → Auth tokens issued (30 min) → requests sent with Auth header → access granted.
    Token expired → reissue token provided → new token issued (30 min) → requests sent with Auth header → access granted.

WebUI Certificate

    By default, Tranzman will use a self‑signed certificate for HTTPS traffic. If you need to have a trusted certificate authority, please follow the steps below to create and deploy your own certificate.

    Steps

    1. Select System > Certificates from the navigation menu.
    2. Fill in the Certificate Request information. (All fields are optional.)
    3. Press Generate to create a new Certificate Request.
    4. Copy the Certificate Request and send it to the Certificate Authority for signing.
    5. Copy and paste the signed Certificate into the right text field.
    6. Press Submit and wait for Tranzman to update the certificate and restart web services.

    🛈 This process can take few minutes.
    The certificate request and signed certificate must be handled securely.
    Restarting web services may temporarily interrupt access to the WebUI. 

   Prev icon.jpg Previous

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