So you have a question but can't see the answer? Please submit your question via this form.
PrivX is available for purchase at the SSH Webshop and the price will depend on the desired plan. You can check your billing information by logging in to the SSH Webshop with your account.
All PrivX subscriptions start with a free 30-day trial period, please head over to the SSH Webshop to start your trial.
Absolutely, the SSH Webshop also has a PrivX test drive available.
You can download the datasheet by signing up here.
Yes, you can use your own client. PrivX will enable connecting to hosts via browser by default, but if you purchase the SSH agent add-on feature, users can connect using native clients on Linux & Mac. Support for Windows native clients such as PuTTY is on it’s way.
PrivX is a zero footprint solution, so there's no need to install any software on target hosts.
On RDP connections you can restrict which applications each user is able to access on the target Windows host, please see the documentation. On SSH connections access is provided to the target host itself, and limiting user rights on the respective target host (by e.g. restricted shells) is your decision and responsibility.
Sensitive data is split and stored in encrypted format. In transit, all database connections, intra micro-service connections and UI connections are encrypted via TLS.
Generally, SSH trails take a few megabytes per hour. For RDP trails, it depends greatly on the circumstances, i.e. your screen resolution and how much data is processed and moved. Fullscreen video will take several gigabytes per hour, while light administrative use with little animation on medium screen resolution takes approximately 100 megabytes per hour.
PrivX provides three-tiered security on session recordings:
- AES 128 and GCM based encryption
- Each trail file is secured with a unique key
- Each trail in turn within a trail file is also secured with a unique key
The master key is stored in the keyvault while the trail specific keys are stored in the filesystem. Additionally, the trail file names are confuscated on purpose, making it impossible to trace which file pertains to which session.
The recordings are native SSH/Guacamole (RDP) protocol streams.
No. We will most likely add the capability to download the recordings as video files later through the PrivX UI for the members of privx-admin role.
Only members of privx-admin role can access the recordings.
As a PrivX admin, you choose the directory/NFS mount where the trails should be stored by defining it in the PrivX configuration files. PrivX does not manage permissions nor monitor the changes in that directory. You must make sure that the directory is sufficiently protected against unauthorized access.
No. PrivX admin is responsible for configuring the directory/NFS mount where trails should be stored and ensuring that it is regularly backed up.
No. Each PrivX instance has its own master key that is required for processing the encrypted trail files.
Currently, the recordings can only be viewed in PrivX by being a member of the privx-admin role. We are considering to add the functionality to manage permissions for PrivX roles in the future.
Each session is stored as a separate trail file. We are considering implementing a feature where we can merge the activities by timeline into a single trail file and introduce anomaly detection.
Consequently, your session also expires, thus ending the recording. A new session will result in a new trail file.
There is a mechanism to check file tampering. The timing is user configurable, by default it is run once per day. When attempting to playback a tampered recording, UI will notify the PrivX admin about the fact. Such files can no longer be played back by PrivX. The recording sizes and checksums are stored in the database, file system and as audit events. Assuming audit events are propagated from the PrivX host to an external SIEM, the sizes & checksums can be compared against stored values at a later date. PrivX also sends out an audit event to syslog when an audit file has been opened.
This could be a sign that the designated NFS mount for storing trails is out of space or PrivX does not have sufficient permission to write to that location. Please check the syslogs to debug the situation.
This could happen if the file has been deleted or has been tampered with. In either case, there is nothing one can do about it. There is no backdoor by design.
PrivX uses syslog functionality LOG_DAEMON to write audit events. By default, the audit events end up into the file /var/log/messages.
When using certificate-based authentication, the user identity is logged in the sshd logs on the target host. For example, when PrivX user ’superuser' logs in to target host as 'ec2-user’, /var/log/secure on target host logs it as follows:
Sep 17 07:15:07 ip-172-31-49-149 sshd: Accepted publickey for ec2-user from 184.108.40.206 port 3403 ssh2: RSA-CERT ID email@example.com:43836 serial 1059239823051326577 (serial 1059239823051326577) CA RSA SHA256:OmlS4VhEqBoGpm9AzgSYrvOaGSJyfot3Zf2ANMoY9So
Here is an example log entry:
Jun 13 12:41:32 privx-bug-squash-host.novalocal SSH-PRIVX-AUDIT: [event="File-upload" eventID="320" connectionID="d12598fc-915a-49c8-55b8-d301d42d082a" connectionType="ssh" hostAddress="10.11.0.46:22" hostUuid="a04b10f4-c9e9-49bd-76b2-5cfdcc2f63e0" path="/root/ssh_targets.png" sessionID="5fd2447a-ff4e-4384-7ec3-79b908fc5bed" size="0" targetUsername="root" userID="1da90209-2072-44f6-a65d-0ba9880836c1"]”
Yes, the audit logs include file transfer events and has the info on the filename and who transferred the file. With auditing enabled, you may also download the transferred files.