The Reverse Connectivity Paradox: Close all inbound ports on your firewall while still allowing clients to connect to your WebSocket server.
Until now, allowing access to an internal network while still maintaining security behind the firewall has been impossible because of the necessity to open ports to accept incoming connections. For most administrators, opening a port to the outside world is a necessary but undesirable solution because it instantly increases vulnerability to outside hacks and attacks. Companies are reluctant to open up ports in firewalls because each open port is another potential attack vector for malicious users. Using the Kaazing WebSocket Gateway reverse connectivity feature, you can close all of your inbound ports while still allowing clients to initiate connections.
Traditionally, web architectures require that you open inbound ports to allow connectivity to internal systems and services in your trusted network. As with any web architecture, a typical Kaazing WebSocket Gateway configuration (without reverse connectivity) must open ports to allow TCP, HTTP, or WebSocket connectivity through a firewall, as shown in the following figure:
For example, when you open port 80, web traffic flows via the HTTP protocol and HTTP clients are privy to private information. However, with HTTP, you can take precautions—such as opening ports 80 and 443 to HTTP and HTTPS (over TLS/SSL)—to restrict the attack surface area and hinder leakage of information via the HTTP protocol to other sources. Using the Gateway’s reverse connectivity feature, you can close all inbound ports in your firewall, thus closing the entry points available to untrusted users and eliminating your attack surface vulnerability.
To implement reverse connectivity, you configure an additional Gateway in the internal network to initiate reverse connectivity from within the trusted network. Each Gateway is configured to use a proxy service. With this architecture, a client can talk to a back-end server through a firewall. Another benefit of the reverse connectivity approach is that nothing else in your architecture is invalidated. For example, neither the client nor back-end server are aware of the reverse connectivity because it is completely transparent to the rest of the architecture. Clients that are outside the firewall connect as usual to the DMZ Gateway.
Adding reverse connectivity to your architecture requires only a few simple modifications. Instead of a single Gateway in the DMZ, you add another Gateway to your trusted network. Then, you only need to make a few modifications to configure the two Gateways for reverse connectivity. Other parts of the architecture, such as the client and server, observe no apparent differences between a configuration with reverse connectivity or one without, making reverse connectivity completely transparent to the endpoints of the configuration.
With this architecture in place, you can close all inbound ports of your firewall, thus providing maximum security and zero attack vectors for malicious users seeking to exploit ports in your firewall.
For more information on Reverse Connectivity:
To read more about WebSocket security: