Customizing the PrivX Carrier browser

To toggle browser features such as navigation and developer tools, modify the Carrier configuration, located on your PrivX-Carrier machines at /opt/privx/etc/carrier-config.toml

After modifying the settings, restart your PrivX Carrier.

📘

Note

Disabling navigation elements does not restrict users from following links to other parts of the Internet. For more information about properly restricting access to sites, see section Access Restrictions for Web Connections below.

Access Restrictions for Web Connections using host settings

Since PrivX 16, it is possible to restrict which web addresses the containerized browser can navigate to using Allowed Domain setting for web service on each host.
Please note, that many web sites load content from multiple domains. Please make sure you allow all required domains. If Allowed Domains is left empty, no domain restrictions are used.
This setting is host specific. For role based restrictions, see the next section.

Access Restrictions for Web Connections using Squid ACL

By default, Squid proxy has been configured to allow web connections to all sites. To limit which sites the containerized browser can
access, you can modify the Squid Access Control Lists configuration on /opt/privx/etc/squid.conf on PrivX Web Proxy host.

You can control access to specific websites for specific PrivX roles. With this you can prevent users
from accessing arbitrary websites by entering URLs, and via links on web targets.

Role-based access control is configured via Squid on PrivX Web Proxy host. These instructions assume you have some familiarity with Squid configuration. This section provides some basic examples about access control. For more comprehensive descriptions about Squid's access-control settings, see their vendor documentation at https://wiki.squid-cache.org/SquidFaq/SquidAcl

To control access for a PrivX role, you will typically need to specify the following in the Squid configuration:

Define an acl matching the members of the PrivX role. You can determine PrivX users' roles from their User-Agent header.

Define acls for the restricted address(es).

Define rules allowing/denying matching members to access restricted address(es).

For example, to only allow privx-admin members to access while denying all other PrivX users access to www.example.com, perform the following on all your PrivX Web Proxies:

Add rules like the following to the Squid configuration at /opt/privx/etc/squid.conf

# Match all PrivX users belonging to the privx-admin role
acl is_privx_admin req_header User-Agent Role\=privx-admin

# Define restricted address(es) based on HTTPS certificate's server name
acl restricted_to_certain_privx_roles ssl::server_name www.example.com

# Allow privx-admins to access restricted address(es)
http_access allow is_privx_admin restricted_to_certain_privx_roles

# Deny others access to restricted address(es)
http_access deny restricted_to_certain_privx_roles
Restart the squid service to apply the changes:

# systemctl restart squid

If you have lots of rules and restrictions, consider using web host specific restrictions instead (see previous section).

Container re-use

By default, each user gets a separate container for each browsing session. If the user launches web connections to two separate sites or as a different user, she will get two separate containers to handle the connections.
If the user launches connection to the same web target on the same login session on two browser tabs, the connections will share the same container.
Also, if user reloads the page or network connection is momentarily interrupted, the browsing session continues using the same container.
If Firefox browser is closed or all connections to the container are disconnected for more than 30 seconds, the container and it's data will self-terminate.

Memory consumption

As each browser session is running in a sandboxed, audited container, the memory requirements for HTTPS connections are quite heavy.
Generally, the memory requirements for Carrier host is about 250-400 MB of memory per active session.
A Carrier host with 32 GB of memory should be able to handle about 50-100 concurrent web users.
Doing heavy tasks, like watching videos on browser container will increase the memory requirements, up to 1 GB per session.
For further questions about Carrier container features and customization, please contact PrivX Enterprise support.

PrivX Web Proxy host acts as data pipe only. Its memory requirements are lightweight, so much smaller instance is sufficient. However, to properly provide credentials for web logins, each Carrier requires its own Web Proxy.
Installing both Carrier and Web Proxy on the same server is possible, however for security reasons, it's recommended to use separate servers on production environments.

Load balancing

For load balancing traffic between Carrier instances, you can configure the different Carrier/Web-proxy pairs in PrivX web UI to use the same routing prefix. Using the same routing prefixes for Carriers and using the routing prefix in your host address will cause the request to be load balanced between Carrier instances. To change the load balancing algorithm, see prefer_extender_or_carrier_with_least_connections -option in PrivX config file /opt/privx/etc/shared-config.toml on PrivX host.
At the moment, for security reasons, Carrier and Web Proxy credentials are locked to a single Carrier instance at the time and each Carrier requires separate config file.
Sharing credentials and having Carriers to run in auto-scaling group is not yet (easily) possible.