This chapter describes the prerequisites of PrivX deployment.
This section describes the system requirements and specifications for PrivX-system components.
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.
A PrivX deployment must include at least one PrivX server for running PrivX services.
Table 2.1. PrivX-Server Requirements and Specifications
| Server | ||||||||||||
| System Configuration | 4 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 architecture | x86-64 | |||||||||||
| Supported operating systems | Red Hat Enterprise Linux 7.4 or later 7.x, 8.x (x86-64) CentOS 7.4 or later 7.x, 8.x (x86-64) | |||||||||||
| Supported databases | Local or external PostgreSQL and Redis | |||||||||||
| Network Connectivity | ||||||||||||
| Internet connectivity required |
| |||||||||||
| Default network ports in use |
| |||||||||||
| Target-host Authentication | ||||||||||||
| Supported OpenSSH versions | Certificate-based authentication - OpenSSH 6.9 or later, see the section called “Enabling Certificate-Based Authentication for SSH Connections” Other authentication methods - OpenSSH 5.6 or later | |||||||||||
| Supported platforms for Windows Domain Controller and Certificate Authority Server | Windows Server 2016 with the latest service pack and updates Windows Server 2012 R2 with the latest service pack and updates Windows Server 2008 R2 with the latest service pack and updates | |||||||||||
| Client Experience | ||||||||||||
| Supported browsers | Latest versions of:
| |||||||||||
| System Security | ||||||||||||
| HSM support | SafeNet Network HSM:
| |||||||||||
Note
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.
This section describes the system requirements and specifications for optional PrivX components:
PrivX Extender
PrivX Carrier
PrivX Web Proxy
PrivX Extenders proxy connections to target hosts. They are needed for connecting to hosts not directly accessible from PrivX servers.
Table 2.2. PrivX-Extender Requirements and Specifications
| Extender | ||||||
| System Configuration | 4 GB RAM, 2-core CPU, and 15 GB storage | |||||
| Supported operating systems | Red Hat Enterprise Linux 7.4 or later 7.x, 8.x (x86-64) CentOS 7.4 or later 7.x, 8.x (x86-64) | |||||
| Network Connectivity | ||||||
| Internet connectivity required | For installing dependant libraries during installation and upgrades | |||||
| Default network ports in use |
| |||||
PrivX Carriers provide web functionality. Needed if you want to connect to HTTP/HTTPS targets via PrivX.
Table 2.3. PrivX-Carrier Requirements and Specifications
| Carrier | |||
| System Configuration | 64 GB RAM, 16-core CPU, and 100 GB storage for < 50 concurrent web connections | ||
| Supported operating systems | Red Hat Enterprise Linux 7.4 or later 7.x, 8.x (x86-64) CentOS 7.4 or later 7.x, 8.x (x86-64) | ||
| Network Connectivity | |||
| Internet connectivity required | For installing dependant libraries during installation and upgrades | ||
| Default network ports in use |
| ||
Similar to carriers, PrivX Web Proxies also provide web functionality. Needed if you want to connect to HTTP/HTTPS targets via PrivX.
Table 2.4. PrivX-Web-Proxy Requirements and Specifications
| Web Proxy | |||||
| System Configuration | 4 GB RAM, 2-core CPU, and 15 GB storage for < 50 concurrent web connections | ||||
| Supported operating systems | Red Hat Enterprise Linux 7.4 or later 7.x, 8.x (x86-64) CentOS 7.4 or later 7.x, 8.x (x86-64) | ||||
| Network Connectivity | |||||
| Internet connectivity required | For installing dependant libraries during installation and upgrades | ||||
| Default network ports in use |
| ||||
| Supported login methods for autofill |
| ||||
A PrivX server that satisfies or exceeds the production requirements is expected to support:
100 000 PrivX users total, with 700 concurrent users.
25 000 target hosts total, with:
Up to 1000 hosts added/deployed concurrently.
20 000 target hosts scanned in 2 minutes.
Up to 200 concurrent RDP connections for performing typical user operations. Graphically intensive sessions (including video streaming) may reduce the number of supported concurrent connections.
Note
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.
The enabled features and limitations can be viewed on the Settings → 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.
The standard PrivX license gives you all the PrivX features except the ones listed below:
PrivX Extender: For more information, see the section called “Proxying Connections to Hosts”.
Application restrictions through RDP connections: For more information, see the section called “Restricting Users' Access to Applications in RDP Connections”.
RDP-native-client connections: For more information, see the section called “RDP Connections with Native Clients”.
For more information about managing your PrivX license, see the section called “PrivX License Management”.
We strongly recommend enabling NTP clock synchronization for the system. Otherwise, please verify the system time and date manually before continuing with PrivX installation. We also recommend enabling time-server authentication for NTP connections.
The short-term user certificates issued by PrivX may be valid at incorrect times if system times are not synchronized correctly. Due to the just-in-time nature of the certificates issued by PrivX, even deviations of just a few minutes may cause authorizations to fail.
If you plan to have multiple PrivX servers in your deployment (for high-availability and/or load balancing), you must set up an external PostgreSQL database and an external Redis server. You may also need to set up a load balancer to distribute connections to PrivX servers.
Set up a PostgreSQL-database instance and a Redis-server instance. We strongly recommend employing 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.
Access to the Redis server may be password-protected.
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
External-database connections 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. For more information about adding trust anchors to PrivX servers, see the section called “Secure-Connection Setup”.
The requests from a PrivX session must be handled by one PrivX server; for example the load balancer could be configured to use either IP hashing or sticky sessions.
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 Advanced Deployment articles from https://help.ssh.com/
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:
Table 2.5. Required key-generation mechanisms for HSM storage
| Key Type | Mechanisms | |||||
|---|---|---|---|---|---|---|
| CA keys |
| |||||
| Symmetric keys |
|
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.
curve25519-sha256@libssh.org |
ecdh-sha2-nistp256 |
ecdh-sha2-nistp384 |
ecdh-sha2-nistp521 |
diffie-hellman-group14-sha1 |
Sound does not work during an RDP connection or playback on Internet Explorer.
Key-combinations using keys unavailable to UK or US keyboards (such as CTRL+ ) do not work on Internet Explorer 11 or Edge browsers.
You cannot transfer folders through file transfer.
Ctrl+W key-combination closes the open tab on Firefox.