HAProxy + KAT

Sometimes IP address restrictions or IP-based allowlisting is not enough, think: airport lounge, CGNat or other NAT environments. That's why Knocknoc extends HAProxy in an innovative way through the addition of Knocknoc Access Tokens.

Knocknoc Access Tokens (KATs) are single-use, ephemeral tokens that are distributed "out of band" through the Knocknoc Agents to client-traffic recipient/interception technologies, in this case HAProxy. HAProxy utilizes these tokens to verify the user - at layer-7 - within the HAProxy system, prior to onward delivery of network traffic to back end systems.

This results in an IP address + token validation being performed on user traffic prior to onward access, removing the risk of shared IP-address sources.

KATs can be used on their own or in addition to IP address allowlisting - resulting in a scalable yet high-trust verification process, removing pre-authentication attack surface of underlying applications.

Knocknoc Configuration for HAProxy + KAT

Log in to Knocknoc at /admin
Select Knocs, and Identity Aware Proxy

Set the Proxy Type to HAProxy + KAT.

Define an "ACL Name" which best represents the front-end/back-end combination you will configure within HAProxy. This should be alphanumeric.

The HAProxy admin socket path is pre-populated from the selected orchestration Agent, however if you have more than once instance of HAProxy on the Agent server this will need adjusting.

HAProxy version 3.0 or above is required (HAProxy 3.0, HAProxy ALOHA 16.5, HAProxy Enterprise 3.0r1 or newer)

HAProxy Configuration via the Admin Socket

Firstly, ensure you are running HAProxy 3.0 or above.

Knocknoc supports HAProxy's admin socket, this interaction is how the access control list (ACL) within HAProxy is updated to allow your users to access the protected application behind. For this guide we are going to make a few assumptions, the first is that you have a Linux based system and the second is the Knocknoc Agent and HAProxy is installed already.

Add the knocknoc-agent user to the HAProxy group. This allows the knocknoc-agent to read and modify the ACL.
```
adduser knocknoc-agent haproxy
```
Edit the HAProxy configuration file.
```
vi /etc/haproxy/haproxy.cfg
```
Check the socket configuration under the global section. This socket is what the agent connects to, in order to control HAProxy, hence the need for permissions. The line will list the location of the socket and access permissions. For example;
```
stats socket /run/haproxy/admin.sock mode 0666 level admin user haproxy group haproxy
```
Copy the path to the socket this will be required when setting up the backend in the Knocknoc admin interface below.
The frontend definition, in this example, is listening for HTTP/s traffic on all interfaces on port 443 and HAProxy is providing the SSL verification from the certificates within the provided directory.
```
frontend https_frontend 
 mode http
 bind *:443 ssl crt /etc/ssl/private/ alpn h2,http/1.1
```
Within the frontend definition, we have 3 ACL's;
1. acl is_confluence hdr(host) confluence.mycompany.com any traffic hitting the url defined is marked with the ACL "is_confluence"
2. acl is_http hdr(X-Forwarded-Proto) http any traffic that is HTTP and not HTTPS is marked with the ACL "is_http"
3. acl knoc_confluence src -u 500 is the ACL-ID that Knocknoc-agent is interacting with in this example. Users who have authenticated to Knocknoc and via their groups are granted access to Confluence will have their IP added to that ACL-ID. Traffic from the IP's in that ACL-ID are marked with the ACL "knoc_confluence".
```
acl is_confluence hdr(host) confluence.mycompany.com
acl is_http hdr(X-Forwarded-Proto) http
acl knoc_confluence src -u 500
```
The below rule within the frontend definition redirects traffic marked with the ACL "is_http" from HTTP to HTTPS. Forcing all traffic to be encrypted.
```
redirect scheme https if is_http 
```
Traffic that is marked with the ACL's "is_confluence" and "knoc_confluence" is directed to the backend "confluence_backend"
```
use_backend confluence_backend if is_confluence knoc_confluence
```
Any traffic not those ACL's receives a 503 error.
Next is the backend definition the example contains;
1. backend confluence_backend this has to match the use_backend confluence_backend from the frontend definition.
2. The mode, mode http, which should match the mode from the frontend definition.
3. The server line;
  1. This contains a recognizable name for the server, server confluence_server for easy identification and logging.
  2. The IP:Port of Confluence 192.168.0.200:443 behind HAProxy.
  3. The check statement, which tells HAProxy to check Confluence is up and responding on the IP:Port.
  4. ssl verify none this statement means HAProxy does not care if the Confluence SSL cert is valid as SSL termination is happening between the user and HAProxy.
```
backend confluence_backend 
 mode http
 server confluence_server 192.168.0.200:443 check ssl verify none
```

A lot, lot more that can be done with HAProxy the more familiar you become with it. Tied with Knocknoc's security integration it can become a fundamental cog in your security machine. Should you need further assistance feel free to reach out to one of our support partners.

Additional HAProxy Configuration Information

Error Responses

HAproxy can easily send custom 403 or 503 responses to users who aren't allowed to access the backend resource. For example:

This is configured as the default_backend error response in HAProxy config, so if the HTTP request doesn't match the right source IP or hostname, the above is shown in the browser. An admin can customize this to display anything, but keep in mind it's a HTTP response, not an HTML page, so there are limitations. You could of course link people to your Knocknoc instance in the error message, depending on your users and risk profile.

These are available within the HAProxy directory: /etc/haproxy/errors/

HAproxy TCP Socket

The HAProxy backend also supports a TCP socket, in which case it still expects to talk to the Unix socket, but it can do so via a TCP redirect. This is most easily accomplished with the spiped utility.

Knocknoc-agent ships with a script make-spiped-tunnel.sh which can walk you through making an encrypted tunnel via spiped between your Knocknoc-agent machine and a remote HAProxy. It is often easier to deploy Knocknoc-agent directly to a machine, but in case this isn't possible, you can use the spiped tunnel for this purpose.

Get in touch with our support team if you need assistance on such a configuration.

Verifying IP addresses are added after login:

echo "show acl #500" | socat stdio /var/run/haproxy/admin.sock (your socket location may vary!)

echo "show acl #701" | socat stdio /run/haproxy/admin.sock

General HAProxy configuration

If you require more information on a general HAProxy configuration - please view the docs here.

Example architecture

This effectively creates an identity aware proxy by leveraging HAProxy as a reverse proxy, along with KAT verification.

An example use case is protecting web applications from external third-parties or business partners, without requiring a VPN nor desktop/client installation on their unmanaged/non-SoE devices.