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 microservice-based solution. Most PrivX microservices need their own database connections. By default, PrivX uses up to 269 database connections per PrivX Server. For HA setups with multiple PrivX Servers, make sure your connection limit is set accordingly.

Default PostgreSQL connection limit is usually 100 connections. PrivX will by default set it to 1000 in single-server deployments.

Some cloud-based database solutions, like AWS RDS, will set the connection limit based on database-instance size. RDS uses the following formula to determine the max number of connections:

LEAST({DBInstanceClassMemory/9531392},5000)

For example, an AWS db.m3.medium instance allows up to 320 database connections, which isn't enough for HA deployments. So a large or xlarge database instance is recommended.

For large production deployments, we recommend a database instance with at least 32 GB of memory.

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 PrivX Web Proxy 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.

Rotating Logs

Logs under /var/log/privx/ are not rotated by default. We recommend setting up automatic log rotation to prevent PrivX servers from running out of storage space.

You may set up automatic log rotation with logrotate for example:

  • Create config file to /etc/logrotate.d/ directory

    /var/log/privx/*.log {
  su root privx
  daily
  copytruncate
  size 20M
  rotate 5
  dateext
  compress
  notifempty
}

    After this, a daily cron job will rotate logs sizes of which exceed 20M bytes

Was this page helpful?

On this page