Browser Isolation¶
One of the biggest security risks to organizations is direct internet access to the endpoint. Employees typically need access to the internet to do their jobs, but the proliferation of viruses, malware and phishing attacks pose a significant risk. A single mis-click and the organizations infrastructure can be exposed to viruses and ransomware.
Browser Isolation categorically removes this risk, by shifting the paradigm of how this internet is accessed. Users can still access the internet from their endpoint systems, but instead use a remote, containerized browser that is accessed directly from their native browser.
The Kasm Chrome container being accessed from Internet Explorer¶
Kasm Server provides browser isolation by running a remote, containerized browser that is rendered inside the user’s local browser. This allows organizations to cut off direct internet access to the endpoint and tightly control what goes in and out of the network. This is the ultimate protection from viruses, ransomware, and other types of malware. It also enhances data loss prevention programs by allowing administrative control items uploaded , downloaded and copied to the Kasm.
Seamless Browsing¶
To make browser isolation feel more seamless to the end users, Kasm Server provides additional interfaces that make regular tasks feel the same. For example, when the user attempts to navigate to a website using their local browser, the request is in intercepted, the Kasm remote browser is shown, and navigates to website original website requested.
In similar fashion if a user clicks a link in local document or email, the local browser is launched, loads the Kasm remote browser, and navigates to the link that was in the document.
/go URL¶
Kasm server exposes a /go url that is used to launch or resume as Default Kasm for a user. kasm_url can also be passed as a query argument to this URL and exposed as a variable when defining Docker Exec Config to launch a new browser tab.
https://<kasm-server>/#/go?kasm_url=<destination-url>
https://kasm.company.local/#/go?kasm_url=wikipedia.com
Note
The Default Kasm can be configured as a Group Setting or as a User Setting
Workflow¶
Seamless browsing works by intercepting the user’s original request and sending the client a redirect to Kasm Server with the original request URL encoded in the kasm_url parameter. The client’s browser then navigates to Kasm Server and the isolated browser running inside the Kasm sandbox then navigates to the originally requested URL.
Proxy Redirection Workflow¶
In order to do this redirection an explicit or implicit forward proxy is needed. Most large organizations will have a forward poxy. In order to do redirection with URL encoding of the original request, the proxy must be capable of configuring custom rules. We have included configuration examples for F5 and BlueCoat vendors.
Forward Proxy¶
An explicit forward proxy is one that is explicitly configured in the browser or operating system. Most enterprise forward proxies will allow you to create a policy that will properly redirect users request to Kasm. The system needs to redirect, using HTTPS status code 302, to https://kasm.company.local/#/go?kasm_url=ORIGINAL_URL where kasm.company.local is the hostname of your Kasm installation and ORIGINAL_URL is the user’s originally requested URL. This URL needs to be URL encoded. The following sections cover different forward proxy implementations. If your organization already has a compatible proxy in place, then creating a new policy to redirect is all that is needed. If a proxy is not already in place, clients will need the organizations root CA cert trusted by their browser and/or Operating system. If the proxy is an explicit proxy, the browser and/or operating system will need proxy settings configured.
BlueCoat¶
The BlueCoat proxy can be configured to redirect users to Kasm and encode the orginal request so that Kasm can navigate the isolated browser to the original request. The following link provides a similar example, except this policy redirects users based on URLs that are not categorized. So the rule needs to be modifed to trigger for all URLs, whith the exception of ‘https://kasm.company.local’ (replace with your Kasm installation domain name). The return code needs to be 302 instead of 307, and the destination URL needs to be modified to ‘https://kasm.company.local/#/go?kasm_url=$(1)’.
F5¶
An F5 acting as a forward proxy for an enterprise network can redirect users to Kasm and block direct access to the interent. This is done using an iRule. In he following example, kasm.company.local is the domain name of the Kasm installation.
when HTTP_REQUEST {
if { ([HTTP::host] != "kasm.company.local") and ([TCP::local_port] == 80) } {
HTTP:redirect https://kasm.company.local/#/go?kasm_url=http://[HTTP::host][HTTP::uri]
}
if { ([HTTP::host] != "kasm.company.local") and ([TCP::local_port] == 443) } {
HTTP:redirect https://kasm.company.local/#/go?kasm_url=https://[HTTP::host][HTTP::uri]
}
}