Using Software-as-a-Service in closed networks, or “walled gardens”, is a challenge both to SaaS vendors and the IT organization that wants to use a new software solution while not opening their closed networks to the risks of the internet. In this blog post, we present how Hysolate, as a SaaS vendor, provides a solution to address such network security restrictions while still enjoying the benefits of using a cloud-based SaaS, as well as providing technical details for implementing such a solution for controlling access to other cloud services.

The problem

Hysolate’s Isolated-Workspace-as-a-Service solution requires connectivity of our software on endpoint devices to our cloud SaaS platform in order to provide policies, updates, analytics, etc. In some scenarios, such as closed or heavily-governed networks, this becomes impossible due to the lack of direct access to the SaaS platform from the internal network.

Hysolate Isolated-Workspace-as-a-Service provides its management service in the cloud, and we have good reasons to do so. To keep our management services always up-to-date we do not offer our service on private on-premise data centers. However, we would still like to provide value for customers that cannot connect to our service directly, due to regulation or security concerns.

To understand the solution, let’s take a look at reverse proxies.

Reverse Proxies

A common practice to separate web servers from their users is to use a reverse proxy. In most scenarios, the real web server is inside an internal network, the reverse proxy is in a DMZ, and the end users are in an external network, such as the Internet. This separation allows the reverse proxy to off-load and decouple some of the web server work, including:

• Integrate a web-application firewall to detect malicious requests;
• TLS termination and server certificate management;
• Caching to reduce load on the web server; and –
• External hostname of the service, so the web server does not need to be aware of it.

When an HTTP request arrives at a reverse proxy, it will forward the request to the web server while changing the Host header to the internal hostname of the web server.

For example, a typical nginx http block for a reverse proxy will include:

ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1.2 TLSv1.3;

upstream webserver {
   server webserver:8080;
}
server {
  listen 443 ssl;
  server_name www.example.com;
  ssl_certificate /etc/nginx/ssl/www.example.com.crt;
  ssl_certificate_key /etc/nginx/ssl/www.example.com.key;
  location / {
    proxy_pass http://webserver;
  }
}

This configuration assumes that the sole web server is internally reachable at the webserver hostname over HTTP, TCP port 8080, and its IP address is static.

How can we use the same principles for accessing SaaS in a private network?

Reversing a Reverse Proxy

In our case, the Hysolate service is hosted in the public cloud, and the users are inside the closed network. To connect between the two, it is possible to deploy a reverse proxy in the DMZ of the closed network. But there are some differences to consider:

1. The communication between the reverse proxy and the SaaS must be encrypted, as it goes through the public internet networks;
2. The SaaS is usually served on multiple external hostnames, e.g. *.hysolate.com in our case (multiple domains for the various services, such as: API service, authentication service, etc);
3. The SaaS IP address(es) are not static, and usually shared with other CDN customers;
4. The SaaS is not aware of the internal network and its “internal” hostnames.

By deploying such a reverse proxy configuration in the DMZ of the closed network, the local IT organization gains the following benefits to meet regulatory requirements:

• The users are not exposed to the Internet;
• It is possible to monitor and inspect the traffic.

It is possible to implement such a reverse proxy with nginx, using the following http block configuration:

ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /etc/nginx/ssl/example.local.crt;
ssl_certificate_key /etc/nginx/ssl/example.local.key;

proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_server_name on;

resolver <IPs-of-DNS-servers-in-the-DMZ>;

proxy_redirect https://www.example.com/ https://www.example.local/;
proxy_redirect https://api.example.com/ https://api.example.local/;

sub_filter_once off;
sub_filter www.example.com www.example.local;
sub_filter api.example.com api.example.local;
sub_filter_types application/json;

server {
  listen 443 ssl;
  server_name www.example.local;
  set $saas www.example.com;
  location / {
    proxy_pass https://$saas:443;
  }
}
server {
  listen 443 ssl;
  server_name api.example.local;
  set $saas api.example.com;
  location / {
    proxy_pass https://$saas:443;
  }
}

Let’s break this configuration down:

ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /etc/nginx/ssl/example.local.crt;
ssl_certificate_key /etc/nginx/ssl/example.local.key;

The reverse proxy will be served over TLS, and only one server certificate needs to be used: a wild-card certificate for the internal domain mimicking the SaaS. It is also possible to use multiple certificates, but one certificate is easier to manage.

proxy_ssl_protocols TLSv1.2 TLSv1.3;

proxy_ssl_ciphers HIGH:!aNULL:!MD5;

proxy_ssl_server_name on;

This is the reverse proxy HTTPS client configuration: TLSv1.2 at minimum and use Server Name Indication.

resolver <IPs-of-DNS-servers-in-the-DMZ>;

Nginx needs to be explicitly configured with a list of DNS servers to dynamically resolve the SaaS hostnames.

proxy_redirect https://www.example.com/ https://www.example.local/;
proxy_redirect https://api.example.com/ https://api.example.local/;

When the SaaS includes Location and Referer HTTP headers, the SaaS will include URLs with the external hostnames, and they need to be fixed.

sub_filter_once off;
sub_filter www.example.com www.example.local;
sub_filter api.example.com api.example.local;
sub_filter_types application/json;

When the SaaS includes URL references to itself in the response bodies, they need to be fixed as well using the nginx module ngx_http_sub_module.

server {
  listen 443 ssl;
  server_name www.example.local;
  set $saas www.example.com;
  location / {
    proxy_pass https://$saas:443;
  }
}
server {
  listen 443 ssl;
  server_name api.example.local;
  set $saas api.example.com;
  location / {
    proxy_pass https://$saas:443;
  }
}

The server blocks are similar to the simple case, except 2 major differences:

• Set the proxy_pass argument via a set variable, to force nginx to resolve the SaaS hostname dynamically.
• Explicitly state HTTPS protocol and TCP port 443.

Conclusion

Now with a specially deployed reverse proxy, it is possible to access Hysolate’s Workspace solution without opening closed networks to the internet, and provide our customers with our services without compromising regulations and security of the closed networks.

Ready for your team to work more securely and more productively? Would you like a demo to understand how Hysolate can isolate your workspaces, even in a private network? Sign up here.

The post Hysolate in a Closed Network with Nginx appeared first on Hysolate.

*** This is a Security Bloggers Network syndicated blog from Blog – Hysolate authored by Boris Figovsky. Read the original post at: https://www.hysolate.com/blog/hysolate-in-a-closed-network-with-nginx/