SSH.COM PrivX

SSH.COM PrivX Documentation Hub

Welcome to the SSH.COM PrivX documentation! Here you'll find the PrivX administration manual, use case specific guides as well as API specifications.

Documentation    API Reference

Best practices

Disabling PrivX repository

If you installed PrivX using SSH PrivX repository, consider disabling the repository after installation to avoid accidental PrivX updates when running "yum update", especially in production environments.
You can also consider using "yum versionlock" -command:

yum -y install yum-versionlock
yum versionlock PrivX

and then to unlock before update:

yum versionlock delete PrivX

Setting ulimits

If your PrivX installation is handling a lot of concurrent users, it is recommended to modify the max file descriptors limit on PrivX instances. PrivX does not touch the system limits during installation.
Each connection via PrivX uses several sockets (and file descriptors, if auditing is enabled).
For RDP and web connections, you're likely to reach memory limits first before hitting file descriptor limitations. SSH connections via PrivX are using very little memory, so for this use case you might need to tune file descriptor limits.
By default, CentOS and RHEL set the max file descriptors limits to 1024 (soft limit), which is adequate for few hundred concurrent users (less if auditing enabled). To see the current value, type:

su privx -c "ulimit -Sn"

To bump up the file descriptor count, add the following lines to /etc/security/limits.conf:

privx           soft    nofile           8192   
privx           hard    nofile           8192

Database connections

PrivX is a microservices based solution. As most PrivX microservices need their own database connections, PrivX will use up to 100 database connections per instance.
Default PostgreSQL connection limit is usually 100 connections (PrivX will set it to 1000 by default when installing PrivX locally).
If you're installing an HA production setup with multiple instances, with external database, make sure your connection limit is set accordingly.
Some cloud based DB solutions, like AWS RDS will set the connection limit based on DB instance size. RDS uses the formula LEAST({DBInstanceClassMemory/9531392},5000) to determine the max number of connections.
For example, AWS db.m3.medium instance will allow up to 320 db connections, which is good for up to 3-4 PrivX instances.

Securing Carrier and Web Proxy

Carrier is a PrivX component, which offers auditable HTTP and HTTPS connections for the user in sandboxed environment.
PrivX Web Proxy is another component, whose job is to provide access control for those connections and act as a password manager for different sites.

Carrier and Web Proxy are always installed in pairs. For development environments, they can be installed on the same server, but for production it is recommended to have two separate servers for security reasons.

Carrier is running a separate Firefox web browser on a Docker container for each user session.
By default, PrivX Carrier is creating a separate network for Docker containers. All web traffic is routed via PrivX Web Proxy, but other outgoing traffic from container host OS is not restricted.
To further harden the installation a firewall rule can be created to block outgoing traffic from Docker network to all but PrivX endpoint and PrivX Web Proxy host address. Alternatively, you can make a similar egress rule for the Carrier instance itself.

If you wish to limit the domains where the web containers can connect via HTTP/HTTPS, you can set the restrictions either via Squid configuration file or via PrivX UI. See Customizing the PrivX Carrier browser

Server locations

When configuring servers and deciding which regions to use, keep in mind that for RDP connections, it is important that PrivX instances (and RDP target host, if possible) are located close to user for best possible user experience. As the mouse movements for RDP connections are rendered on the target host, every extra latency between user and target host will have an effect to the responsiveness.
For Web connections, also Carrier host needs to be located close to PrivX instance. Web Proxy location is not that relevant, as it handles only web traffic.

If your users are located to multiple regions and mostly accessing RDP hosts (or web carriers) in the local region, consider configuring separate PrivX instances to respective regions and routing the regional user traffic to the local PrivX instance using geo-IP routing or different DNS names.
These PrivX instances can all be part of the same HA setup, sharing the database, reducing the need to maintain multiple PrivX installations.
For further configuration instructions and more help with architectural decisions, please contact PrivX Enterprise support.

For SSH traffic, latency is not that important. Separate regional instances in this case are not necessary.

Multi-Factor Authentication

For security reasons, enabling MFA for user directories is recommended.
See Multi-Factor Authentication

Client certificate authentication

Using client-certificate authentication, such as browser certificates or smart cards for logging in to PrivX, see Client-Certificate Authentication

Hardening the OS

By default, PrivX does not enable any additional OS hardening features. It is recommended for administrators to follow the OS hardening guidelines to increase the security of the system. For further assistance, please contact PrivX Enterprise Support and SSH Professional Services.

Updated 5 months ago


Best practices


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.