Preparing for Deployment

This article describes the prerequisites of PrivX deployment.

System Requirements

This section describes the system requirements and specifications for PrivX-system components.

Mandatory Components

A PrivX deployment must include at least one PrivX Server for running PrivX services.

PrivX server
System Configuration4 GB RAM, 2-core CPU, and 15 GB storage for < 10k users
8 GB RAM, 8-core CPU, and 100 GB storage for < 100k users
Supported architecturex86-64
Supported operating systemsRed Hat Enterprise Linux 7.4 or later 7.x, 8.x, 9.2 or later 9.x
Rocky Linux 8.4 or later 8.x, 9.2 or later 9.x
CentOS 7.4 or later 7.x
Amazon Linux 2, 2023
Supported databasesLocal or external PostgreSQL version 12 - 16
Default Network Requirements80, 443 in: Web UI in (80 for HTTP redirect)
8443 in: Client certificate authentication
22 out: Outgoing SSH sessions
2222 in: SSH bastion
1080 in: SSH bastion proxy connections
3389 out: Outgoing RDP sessions
3389 in: RDP bastion
25, 465, 578 out: SMTP notifications
80 in: RDP certificate CRL checks
53 out: DNS
5432 out: External PostgreSQL
6379 out: External Redis (optional)
123 out: NTP
Internet connectivityFor installing dependant libraries during installation and upgrades
License-server connectivity for PrivX-license activation and verification. The license-server address differs depending on which PrivX version you start(ed) with:

Deployments started with v16 and later:
- https://privx.license.privx.io
- 52.49.87.37
- 54.74.201.253
Client experience
Supported browsersLatest versions of:

Firefox
Chrome
Safari
Edge

- You must allow cookies from PrivX.
- On Edge, disallow sleeping tabs for the PrivX GUI. This prevents unintentional disconnects.
System Security
HSM support (optional)SafeNet Network HSM Luna SA 5
Amazon Cloud HSM
SoftHSM2
nShield Connect
Thales Vormetric
Generic pkcs11 provider
Target hosts
SSHCertificate-based authentication - OpenSSH 6.9 or later, see the section called “Enabling Certificate-Based Authentication for SSH Connections”

Tectia Server X.509 certificate user authentication
RFC 6187 X.509 certificate user authentication

Other authentication methods - OpenSSH 5.6 or later
Tectia Server
RDP, certificate authenticationWindows Server 2012 R2, 2016, 2019, 2022 (with the latest service packs and updates)
HTTPS (via Carrier component)Stored credentials authentication. PrivX provides the credentials for target website on behalf of the user. OIDC authentication for supporting websites.
VNCCertificate authentication (using SSH tunnel)
Stored credentials authentication
Network targets with custom protocolsVia PrivX OT

Other applications and users with access to PrivX hosts can gain potentially sensitive information from unprotected system memory. For best security we strongly recommend running PrivX on dedicated hosts.

Expected System Performance

A PrivX Server that satisfies or exceeds the production requirements (8 GB of memory) is expected to support:

  • 100 000 PrivX users total, with 700 concurrent users.

  • Up to 1000 hosts added/deployed concurrently.

  • 20 000 cloud hosts discovered in 2 minutes.

  • Up to 50 concurrent RDP connections for performing typical user operations. Graphically intensive sessions (including video streaming) may reduce the number of supported concurrent connections.
    Expected memory usage for RDP sessions is 90 megabytes per connection. Adding multiple PrivX instances to HA setup will scale the number of concurrent users.

The PrivX microservice architecture supports multiprocessing and benefits from using multiple CPUs or multiple CPU cores.

Reserve enough space for the log data generated by PrivX. Also monitor the log-data growth periodically. In large deployments, PrivX may generate a considerable amount of log data over time. You may configure the PrivX machine to write its log data to an external logging server.

Optional Components

This section describes the system requirements and specifications for optional PrivX components

  • PrivX Extender

  • PrivX Carrier and PrivX Web Proxy

  • PrivX Router

  • UEBA Server

  • PrivX Agent

  • PrivX Authorizer app

Unless otherwise stated, for security purposes we recommend setting up all PrivX components on separate, dedicated hosts.

PrivX Extender

PrivX Extenders proxy connections to target hosts. They are needed for connecting to hosts not directly accessible from PrivX servers.

A PrivX Extender relays host connections, allowing connections to target hosts that are not directly accessible by PrivX, e.g. target hosts without public IP addresses in Virtual Private Cloud or behind other NAT gateways. PrivX Extender acts as reverse proxy, connecting back to PrivX instance via HTTPS endpoint, using secure web sockets.

You need only one extender per VPN or subnet, connections to target hosts can be relayed through the extender.

PrivX-Extender Configuration

Extender
System requirements4 GB RAM, 2-core CPU, and 15 GB storage
Supported operating systemsRed Hat Enterprise Linux 7.4 or later 7.x, 8.x, 9.x
Rocky Linux 8.4 or later 8.x, 9.x
CentOS 7.4 or later 7.x
Default network requirements443 out: PrivX connection
53 out: DNS
8443 in: Host deployment listener

Extender must be able to access target hosts and services.

In HA setups, Extender requires using web load balancer with sticky-session support and Round-Robin routing mode.
Internet connectivity requiredFor installing dependant libraries during installation and upgrades

PrivX Carrier and Web Proxy

PrivX Carriers and PrivX Web Proxies together provide web functionality, required for connecting to HTTP/HTTPS targets via PrivX.

  • Carrier offers auditable HTTP/HTTPS connections for the user in sandboxed environment. Access to shared accounts are provided in a role-based fashion.
  • PrivX Web Proxy provides access control for HTTP/HTTPS connections and acts as a password manager for different sites.

Carrier and Web Proxy are always installed in pairs. For production we strongly recommend installing the two on separate servers; Installing both Carrier and Web Proxy on the same server is only recommended in evaluation environments.

Carriers run a separate Firefox web browser on a Docker container for each user session.
By default, PrivX Carrier creates separate networks for Docker containers, but outgoing traffic from containers is unrestricted.
To further harden the installation a firewall rule can be created to block outgoing traffic from Docker network to all but Web-Proxy host address.

Using PrivX Carrier and Web Proxy requires using web load balancer with sticky session support and Round robin routing mode.
PrivX-Carrier and Web Proxy Configuration

Carrier
System requirements64 GB RAM, 16-core CPU, and 100 GB storage for < 50 concurrent web connections
Supported operating systemsRed Hat Enterprise Linux 7.4 or later 7.x, 8.x, 9.x
Rocky Linux 8.4 or later 8.x, 9.x
CentOS 7.4 or later 7.x
Default network requirements443 out: PrivX connection
18080, 18443, 18444 out: PrivX Web Proxy connections
Internet connectivity requiredFor installing dependant libraries during installation and upgrades

PrivX Web Proxies and PrivX Carriers are both required to provide web functionality.

Web Proxy
System requirements4 GB RAM, 2-core CPU, and 15 GB storage for < 50 concurrent web connections
Supported operating systemsRed Hat Enterprise Linux 7.4 or later 7.x, 8.x, 9.x
Rocky Linux 8.4 or later 8.x, 9.x
CentOS 7.4 or later 7.x
Default network requirements18080, 18443, 18444 in: Carrier connection
80, 443 out: Target host connections
443 out: PrivX connection
Internet connectivity requiredFor installing dependant libraries during installation and upgrades

Web Carriers and Web Proxies cannot be installed on PrivX servers. Furthermore in production, Carrier and Proxy should be installed on separate machines (to ensure secure segregation between connection hosting and password/secret injection functions).

PrivX Router

Network targets are services, systems, or subnets that are accessible remotely using arbitrary TCP/IP protocols. Examples include operational technology such as PLCs, CNC systems, and scientific equipment.

The high-level steps for enabling network-target access include:

The following figure describes the required network configuration for network-target access:

  • Users' connections to network targets must be routed via a PrivX Router.
  • PrivX users may connect to PrivX for authentication.
  • Access to other types of targets is still provided via PrivX as normal.

User connections from untrusted networks must be secured using external means. To achieve this, users may for example use VPN to connect to a secure network, and then you can restrict PrivX Router to only accept clients connecting from your VPN-IP pool.

To ensure that all connections to network targets are audited by PrivX, you may disable direct access:

  • Ensure that all traffic from users' networks to targets must go through the PrivX Router.
  • You may also set up NAT on PrivX Router to hide the devices in the target network. Note that nodes other than PrivX Router must not perform NAT.

For additional information related to Network-target access, see:

User and Entity Behavioural Analytics (UEBA)

PrivX UEBA automatically discovers anomalous SSH and RDP connections that deviate from regular connections. UEBA uses machine learning and probability distributions to calculate the probability of an anomaly based on connection data from PrivX.

PrivX issues audit events when it encounters a connection that seem anomalous. You can also configure PrivX to automatically block such connections.

High-level steps for UEBA setup involve:

  1. UEBA-server setup.
  2. Training UEBA to distinguish normal/anomalous connections.
  3. Configuring anomaly thresholds and behavior.
UEBA Server
System requirements8 GB RAM, 4-core CPU, and 32 GB storage
Supported operating systemsRed Hat Enterprise Linux 7.4 or later 7.x, 8.x, 9.x
Rocky Linux 8.4 or later 8.x, 9.x
CentOS 7.4 or later 7.x
Default network requirements443 in: PrivX connection
Internet connectivity requiredFor installing dependant containers and libraries, during installation and upgrades
Software requirementsDocker Engine version 1.20 or newer installed and running.
systemd and rsyslog services installed and running.
Server-certificate requirementsTLS certificate trusted by PrivX servers.
TLS certificate must include UEBA server's IP and FQDN addresses in SubjectAlternativeName.

For additional information related to user and entity behaviour analytics, see:

PrivX Agent

You may install PrivX Agents on users' workstations, to enable native-SSH-client connections for them.

Users can connect to target hosts/accounts using the SSH/SFTP/SCP clients installed on their workstations, without needing to use the PrivX GUI. Connections are authenticated against PrivX. Connections are established directly to target hosts. This configuration requires a PrivX agent to be installed on the user's workstation.
Using PrivX agent also enables using AWS command line client with temporary federated AWS roles via PrivX.

PrivX Agent Setup

Alternatively to installing PrivX Agents, you may enable native-client connections via PrivX Bastion. For more information about connecting via PrivX SSH/RDP Bastion, see Native SSH and RDP clients.

The enabled features and limitations can be viewed on the Administration→License page.

The maximum amount of concurrent SSH, RDP, and HTTPS connections depends on the type of PrivX license. Connections exceeding the maximum allowed connections are disconnected.

PrivX Authorizer App

The PrivX Authorizer app enables multi-factor authentication (MFA) for PrivX logins.

High-level steps for enabling MFA with PrivX Authorizer include:

  • Configure PrivX to require MFA with PrivX Authorizer.
  • Install and pair PrivX Authorizer app on users' phones.

For more detailed instructions about setting up MFA with PrivX Authorizer, see Multi-Factor Authentication with PrivX Authorizer.

PrivX Authorizer
Supported operating systemsAndroid 10 and later
iOS 13 and later

MFA login is only supported for PrivX local users and LDAP/AD users.

PrivX also supports Multi-Factor Authentication with 3rd-party Authenticators.

Database Requirements

For production environments we strongly recommend using an external database in your PrivX deployment.

  • Set up a PostgreSQL-database instance. We recommend you employ dedicated instances for PrivX.
    The PostgreSQL superuser (typically postgres) must have a valid password: During initial setup PrivX requires superuser permissions, for creating a PrivX database and a PrivX database user.
  • PrivX servers require access to the PostgreSQL database and the Redis server.
    For example with PostgreSQL on Unix, you will need to edit the pg_hba.conf, and insert entries similar to the following:
hostssl all all <privx_server_ip> md5
(for older 9.x PostgreSQL versions)
or

hostssl all all <privx_server_ip> scram-sha-256
  • Connections to the external PostgreSQL database must be SSL-protected:
    • Enable SSL mode in your PostgreSQL configuration (ssl = true).
    • The PostgreSQL server must be configured with a server certificate where the SubjectAltName specifies the DNS and IP address(es) of the server.
  • PrivX servers should also be configured to trust the PostgreSQL-server certificate: On each PrivX server, add the PostgreSQL-server CA chain to the system trust anchors.
  • You can use either the previously-configured PostgreSQL database or an external Redis database to handle notifications between PrivX microservices. For improved security and ease of setup, we recommend using the PostgreSQL database.
    • If you opt for Redis, you must set up an external Redis database that is accessible by all the PrivX servers. Access to the Redis server may be password-protected.
  • The PostgreSQL database may optionally be set up with the pg_trigram extension, to enable Audit-Event Indexing for Faster Searches.

NTP Clock Synchronization

Machines for PrivX servers must have access to a NTP service for synchronizing system clocks. We recommend using the same NTP service in your whole network.

Due to the just-in-time nature of the certificates issued by PrivX, clock skews greater than a few minutes may cause authorizations to fail.

HA-Installation Requirements

For High-Availability (HA) deployments, set up a load balancer to distribute connections to PrivX servers. Your load balancer must satisfy the following requirements

  • Each PrivX session must be handled by one PrivX server; for example the load balancer could be configured to use sticky sessions. Round-robin algorithm is required if using additional PrivX components (PrivX Extender or PrivX Carrier)
  • If you need client-certificate authentication, or SSH/RDP-Bastion connectivity, the load balancer must support TCP-level load balancing.

Load balancer routing requirements

Traffic typeDefault port on PrivXLoad balancing levelLoad balancing method
HTTP user sessions80HTTPsticky
HTTPS user sessions443HTTPSsticky
HTTPS client-certificate authentication8443TCPany
SSH Bastion2222TCPhash
RDP Bastion3389TCPhash

For an example load-balancer configurations on Nginx that satisfies the requirements, see the section called “Example nginx load balancer configuration".

❗️ Important

If the PrivX instance is deployed to a public internet, be sure to limit the traffic to port 3389 (if used) to known sources only. As 3389 is the default port for Windows RDP traffic, it attracts a lot of unwanted attention from bot networks and may cause extra traffic & load for the PrivX deployment.

HSM Integration

For added security, the PrivX can be integrated with a Hardware Security Module (HSM). This allows storing cryptographic keys on HSM, and encrypting database/filesystem keys using a secret from HSM.

PrivX integrates to HSM providers using PKCS #11. For more information about setting up PrivX with HSM, see the Integration articles under HSM Providers.

Decide whether to use HSM before setting up PrivX. HSM support cannot be changed in existing PrivX deployments.

Keys Stored in HSM

The following types of keys may be stored in HSM.

Asymmetric keys

  • CA for issuing just-in-time certificates when users connect using certificate authentication.
  • CA for signing server certificates.

Symmetric keys

  • Master key for encoding/decoding session recordings.
  • Session-authentication keys.
  • Keys for encrypting user and role data.

To store the default CA keys in HSM, your HSM must support the following key-pair-generation mechanisms:

Key typeMechanism
Certificate Authority (CA) keysCKM_RSA_PKCS_KEY_PAIR_GEN
CKM_RSA_PKCS
Symmetric keysCKM_GENERIC_SECRET_KEY_GEN
CKM_SHA_1_HMAC
CKM_SHA*_HMAC (256/384/512)
CKM_AES_KEY_GEN
CKM_AES_GCM

Keys not supported by the HSM are stored in the PrivX database/filesystem, but encrypted using the PKCS #11 instance secret located on the HSM.

Database/Filesystem Keys Encrypted by HSM Integration

Authentication-signing secrets and passphrases are stored in the PrivX database/filesystem. However when HSM integration is enabled, such keys are encrypted using the PKCS #11 instance secret located on the HSM.

ICAP Integration

You may integrate PrivX with ICAP servers to provide virus and content scanning for users' connections. ICAP integration may be performed after initial PrivX deployment.

For more information about ICAP setup, see ICAP Servers.

GDPR Compliance

Please note that as a PrivX handles user data, that data will be classified as personal information, or Personally Identifiable Information. You must ensure your GDPR compliance and inform your users of handling of their data.

Product Limitations

  • You cannot transfer folders through file transfer.
  • Ctrl+W key-combination closes the open tab on Firefox.
  • With RDP and Web connections, the clipboard size is limited to 256 KB.
  • PrivX Agent does not work on RHEL 8 with OpenSSH 7.8p1 due to errors on the OpenSSH side.
  • When RDP certificate authentication fails but the RDP server allows the user to login using other accounts and credentials, then the subsequent authentication information will be lost because PrivX cannot detect what happens at the Windows login screen.
  • For security reasons, PrivX-Agent login to principals configured as delegated roles (the principals configured with --delegated-principal with deployment script in host configuration) is not supported with certificate authentication.
  • Accounts with type configured as Directory are not available for connection via RDP native client.
  • Certificate-based authentication is not supported via RDP native client.

Was this page helpful?