Advanced Configuration : PrivX Help

This chapter provides instructions for customizing PrivX components to suit the needs of your environment.

SSL/TLS Security

This section describes the configuration topics related to SSL/TLS security.

Setting Up a Trusted Server Certificate

Freshly set-up PrivX servers are equipped with self-signed server certificates. For production deployments we recommend replacing the self-signed server certificate with a server certificate issued by a trusted Certificate Authority (CA).

Note

The self-signed server certificate should only be trusted in evaluation deployments. In production environments, we strongly recommend that you acquire and use a trusted server certificate. You can obtain a trusted server certificate by enrolling the certificate-signing request with your corporate CA.

The initial setup has generated a certificate-signing request (CSR), which can be enrolled with a trusted CA for a trusted server certificate. The CSR is located at the following path on the PrivX server:
/etc/nginx/ssl/nginx.csr
Enroll this CSR with your CA. In response, the CA should provide you with the following:
- The server certificate.
- The CA-certificate chain of the CA itself.
Note
Note to certificate-signing authorities: The PrivX CSR contains subjectAltName definitions for DNS and IP addresses. These are critical to PrivX operation and must be preserved in the signed server certificate.
Copy the PEM (Base64) encoded server-certificate file to the ssl_certificate location on the PrivX instance. By default, the location is:
/etc/nginx/ssl/nginx.crt
Ensure that the server-certificate file has correct ownership, permissions, and SELinux context:
```
# chown root:nginx /etc/nginx/ssl/nginx.crt
# chmod 0640 /etc/nginx/ssl/nginx.crt
# restorecon /etc/nginx/ssl/nginx.crt
```
Update the trust anchor for PrivX microservices. To do this, run the following command (replace /path/to/ca_chain.crt with the path to the CA-certificate-chain file):
```
# /opt/privx/scripts/init_nginx.sh update-trust /path/to/ca_chain.crt
```
Note
In single-server deployments, provide the CA chain of the PrivX-server certificate. In HA deployments, provide the CA chain of the load-balancer certificate.
init_nginx.sh requires PEM-encoded certificate files to have Unix line endings. If the command fails, ensure correct line endings in the CA-certificate-chain file, then rerun the command.
Finally, restart the Nginx and PrivX services to start using the new server certificate:
```
# systemctl restart nginx
# systemctl restart privx
```

Setting Up a Trusted CA Certificate

PrivX Authorizer issues access certificates using its own CA, which is self-signed by default. For production deployments we recommend replacing the Authorizer CA with one signed by a trusted certificate authority.

Note

The following procedures use <key_id> and <cert_id> to substitute for PrivX-CA-key ID and the Authorizer-certificate ID respectively. Be careful not to mix them up.

To set up PrivX Authorizer with a trusted CA certificate:

Gain root-terminal access to a PrivX server, and display the PrivX-CA-key ID by running:
```
# /opt/privx/bin/keyvault-tool -name "PrivX CA Key" list-asymmetric
```
Generate a Certificate-Signing Request (CSR) for the CA private key (replace <key_id> with the PrivX-CA-key ID):
```
# /opt/privx/bin/cert-tool -command create -type authorizer-ca \
-subject "OU=PrivX Authorizer CA/CN=PrivX CA" \
-key <key_id> -csr -csrout privx-im-ca.csr
```
This creates the CSR to the file privx-im-ca.csr in your current working directory.
Request a trusted CA to sign the CSR with the following constraints:
- keyUsage must include: Digital Signature, Key Agreement, Certificate Sign, CRL Sign
- basicConstraints must be: CA:TRUE, pathlen:0
After the trusted CA provides you with the signed certificate, you may verify its constraints with (replace privx-im-ca.crt with the path to the signed certificate):
```
$ openssl x509 -text -noout -in privx-im-ca.crt 
```
Replace the Authorizer certificate. First, obtain the ID of the current Authorizer certificate:
```
# /opt/privx/bin/cert-tool -command list -type authorizer-ca
```
Then delete the current Authorizer certificate (replace <cert_id> with the Authorizer-certificate ID):
```
# /opt/privx/bin/cert-tool -command delete -id <cert_id>
```
Finally, import the signed certificate (replace <key_id> with the PrivX-CA-key ID, replace privx-im-ca.crt with the path to the signed certificate):
```
# /opt/privx/bin/cert-tool -command import -type authorizer-ca \
-key <key_id> -in privx-im-ca.crt
```
On all PrivX servers, restart the PrivX services to apply the changes:
```
# systemctl restart privx
```
Subsequent certificates issued by PrivX are signed using the new trusted Authorizer CA certificate.

Allowed SSL Protocols and Ciphers for GUI Connections

Connections to the PrivX GUI are secured using TLS. The allowed SSL protocols and SSL ciphers may be adjusted if some browsers cannot establish connections to the PrivX GUI, or if you want to harden the PrivX instance.

The allowed SSL protocols and SSL ciphers are defined in the Nginx configuration file /etc/nginx/conf.d/privx.conf, by the parameters ssl_protocols and ssl_ciphers respectively, similarly to the following:

...
http {
    sendfile on;
    server_tokens off;

    ssl_protocols  TLSv1.2;
    ssl_ciphers 'AESGCM+EECDH:AESGCM+EDH:AES+EECDH: ... ';

    tcp_nodelay on;
...

After any adjustments to Nginx settings, restart the Nginx web server to apply the changes:

# systemctl restart nginx

Rotating Encryption Keys

This section provides instructions for rotating PrivX cryptographic keys, which should be done regularly for improved security. You can rotate the following keys:

PrivX CA keys, which issue certificates for certificate-based access.
Authentication keys, which issue PrivX-user access and session tokens.

To rotate PrivX CA keys:

Run the rotation script from a PrivX server in the deployment:
```
# /opt/privx/scripts/rotate_privx_ca.sh
```
The old PrivX CA certificates are deleted and new ones are generated. The script will then restart PrivX.
On hosts with certificate authentication enabled, configure trust for the new PrivX CA. To do this:
- On target hosts with certificate-based SSH authentication: run the host-deployment script with the --rotate-ca option:
```
# deploy.py --rotate-ca
```
  Alternatively, manually configure the host to trust the new PrivX CA as described in PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup > Trusting PrivX Certificates.
- If you use certificate-based RDP authentication: Set up trust for the new PrivX CA as described in PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate Authentication for RDP Connections > Steps for RDP Certificate-Authentication-Setup.

To rotate PrivX authentication keys:

Run the rotation command on a PrivX server in the deployment:
```
# /opt/privx/bin/keyvault-tool rotate-auth-keys
```
This generates new authentication keys.
On all PrivX servers, restart the PrivX services:
```
# systemctl restart privx
```

Note

PrivX-user logins may fail during the time between authentication-key generation and restarting PrivX services.

PrivX Log Settings

By default, regular and audit events are logged to syslog. Audit events use the namespace SSH-PRIVX-AUDIT, and other (info/debug/error) messages use the namespace SSH_PRIVX.

You can adjust the locations to which PrivX writes logs, and the log level of each microservice.

The log locations are configured by settings defined in /opt/privx/etc/shared-config.toml

# Should we send PrivX system events to logs under /var/log/privx
# send_regular_events_to_stdout = false
send_regular_events_to_stdout = false

# Should we send PrivX audit events to syslog
# send_regular_events_to_syslog = true
send_audit_events_to_syslog = true

# Should we send PrivX system events to syslog
# send_regular_events_to_syslog = true
send_regular_events_to_syslog = true

To enable debug output for a microservice:

Edit /opt/privx/scripts/<microservice_name>.sh (replace <microservice_name> with the name of the microservice) and set the SSH_TRACE parameter:
```
dir="/opt/privx/bin"
cmd="SSH_LOG_LEVEL=DEBUG SSH_TRACE=6 /opt/privx/bin/auth"
user="privx"
```
By default, the system-logging service rsyslog is configured to show INFO-level messages only, which blocks DEBUG messages. To configure rsyslog to show DEBUG-level messages, find the following line in the rsyslog configuration file, /etc/rsyslog.conf:
```
*.info;mail.none;authpriv.none;cron.none    /var/log/messages
```
And change it to, for example:
```
*.debug;mail.none;authpriv.none;cron.none    /var/log/messages
```
Restart rsyslog to apply the changes:
```
systemctl restart rsyslog
```
Restart the privx service to apply any changes to configuration files:
```
# systemctl restart privx
```

PrivX-Extender Configuration

This section describes configuration topics for PrivX Extenders.

Configuring Extender Log Location

By default PrivX Extender logs info and errors to /var/log/privx/privx-extender.log

If you want to enable logging to syslog, specify the rsyslog address and protocol in /opt/privx/etc/extender-config.toml, similar to the following:

syslog_protocol="tcp"
syslog_address="localhost:514"

Restart PrivX Extender to apply the changes. In addition make sure rsyslog is enabled on the extender host:

systemctl restart privx-extender
systemctl restart rsyslog

Proxying Native-Client Connections

To allow proxying native-client connections via PrivX Extenders:

On all your PrivX servers, enable the forwarder_enabled setting in /opt/privx/etc/ssh-proxy.toml
And restart PrivX services to apply the changes:
```
systemctl restart privx
```
Caution
The forwarder relays all the data it receives (not just the native-client connections), and should not be enabled in high-security networks.
Session recording must be disabled on hosts that are to be accessed using proxied native-client connections. For more detailed instructions about toggling session recording, see PrivX Administrator Manual > Auditing > Session Recording Setup.
(Optional) To simplify native-client commands, specify the required connection parameters in the users' client configuration (typically at /etc/ssh/ssh_config or ~/.ssh/config). You can do this using Host blocks that at least specify:
- The target HostName in extender-name/target-host-address format.
- The ProxyCommand: privx-nc -x $PRIVX_AGENT_PROXY %h %p
For example:
```
Host bilberry
    HostName example-extender/bilberry.example.com
    ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY %h %p
```

After setup, you can connect to target hosts as follows:

As the native-client user, start the PrivX agent (if not already started) and use it to log into PrivX.

If you have specified the required parameters in your SSH-client configuration, you can connect simply using the appropriate Host block. For example:

$ ssh target-user@bilberry

$ sftp target-user@bilberry

$ scp source/file/path target-user@bilberry:/target/file/path

Otherwise, you must additionally provide the ProxyCommand and the name of the PrivX Extender, similar to the following:

$ ssh -o "ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY %h %p" \
target-user@example-extender/bilberry.example.com

$ sftp -o "ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY %h %p" \
target-user@example-extender/bilberry.example.com

$ scp -o "ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY example-extender/%h %p"\
source/file/pathtarget-user@bilberry.example.com:/target/file/path

Setting Custom Instance Names

You can set a custom instance name to better distinguish between multiple PrivX servers. Custom instance names are displayed in the PrivX GUI, and added to the audit events generated from the server.

Figure 2. Custom instance name in the GUI header and audit events

To set a custom instance name for a PrivX server:

Gain root-terminal access to the PrivX server.
Edit the shared configuration at:
/opt/privx/etc/shared-config.toml
In this file, set the custom instance name with privx_instance_name. For example:
```
# A custom PrivX instance name to be shown in the header
privx_instance_name = "PrivX Example Deployment 01"
```
Save your changes to the file.
Restart the PrivX services to apply the changes:
```
# systemctl restart privx
```