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.

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

Since version 29, PrivX Web Proxy no longer utilizes Squid for proxying the traffic. Access control needs to be configured in the privx-web-proxy.toml configuration file instead, as described later in this article.

By default, PrivX Web Proxy has been set up to permit web connections to all websites. To restrict the sites that the containerized browser can access, you can make adjustments to the configuration in /opt/privx/etc/privx-web-proxy.toml on the 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.

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:

# Whitelisted urls. Traffic to these domains is always allowed. Wildcards are allowed, for example ['https://*.gmail.com','https://*.gstatic.com']
# Use [""] to disable.
# Default is to allow all traffic: ["*"]
whitelisted_global_urls = [
"",
]

# Role whitelisted urls. Traffic to these domains is always allowed for the defined roles. Wildcards are allowed. 
# Example:
# whitelisted_role_urls = [
# "privx-admin=https://*.gmail.com",
# "privx-admin,developers=https://*.gstatic.com"
# ]
# Use [""] to disable.
# Default: []
whitelisted_role_urls = [
"privx-admin=https://www.example.com"
]

To blacklist whole domains, except one of the subdomains:

# Whitelisted urls. Traffic to these domains is always allowed. Wildcards are allowed, for example ['https://*.gmail.com','https://*.gstatic.com']
# Use [""] to disable.
# Default is to allow all traffic: ["*"]
whitelisted_global_urls = [
"https://whitelisted.examplesite1.com",
"https://whitelisted.examplesite2.com"
]

# Role whitelisted urls. Traffic to these domains is always allowed for the defined roles. Wildcards are allowed. 
# Example:
# whitelisted_role_urls = [
# "privx-admin=https://*.gmail.com",
# "privx-admin,developers=https://*.gstatic.com"
# ]
# Use [""] to disable.
# Default: []
whitelisted_role_urls = [""]

# Blacklisted urls. Traffic to these domains is blocked, unless explicitly allowed by whitelist. Wildcards are allowed.
# Default is to block everything: ["*"]
blacklisted_urls = [
"https://*.examplesite1.com",
"https://*.examplesite2.com"
]

Remember to restart privx-web-proxy service to apply the changes.

# systemctl restart privx-web-proxy

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

Routing traffic via third party proxy

If your PrivX Web Proxy host is unable to directly access the target network, it is feasible to route the PrivX Web Proxy traffic through a third-party proxy using the HTTP Connect or SOCKS5 protocol. Adjust the proxy_url and no_proxy properties in the privx-web-proxy.toml file to align with your infrastructure configurations. Refer to the details provided below.

# Proxy URL specifies the http connect or socks proxy to use when connecting to target servers.
# Extender connections are never connected through the proxy.
# Supported proxy URL schemes:
#  "http": http connect protocol
#  "https": http connect protocol over a TLS connection
#  "socks5" / "socks5h": socks5 protocol
# If the value is empty then the proxy URL and no proxy list are read from the ALL_PROXY and NO_PROXY environment
# variables.
# Example:
# proxy_url = "http://proxyuser:secret@proxy-server.io:8080"
proxy_url = ""

# No proxy defines target servers which should be connected directly bypassing the proxy. The target servers are specified
# as a comma separated list of ip addesses, cidrs, domain patterns or hostnames.
# Example:
# no_proxy = "10.0.0.1,192.168.0.0/24,*.internal.privx.io,directly-connectable.privx.io"
no_proxy = ""

Remember to restart privx-web-proxy service to apply the changes.

# systemctl restart privx-web-proxy

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.