Skip to main content

SSH

Use Case: Eliminating SSH Attack Surface in a Distributed Environment

A large distributed enterprise needed to eliminate the attack surface of its Internet-facing SSH servers - without adding latency, changing its network architecture, or compromising on security. 

The goal: tie network-level SSH exposure and access to their identity provider, while keeping the experience seamless.

Knocknoc was deployed using its on-host Linux firewall orchestration. Within days, all SSH services were rendered invisible until users authenticated, effectively removing the pre-auth attack surface.

The result: zero added hops, zero routing changes, and a drastically reduced risk profile.

 

Technical how:

SSH can be protected by Knocknoc in a number of ways:

  • Local Linux firewall orchestration on the host (eg: using IPSets)
  • In-line firewall/control device orchestration (Fortigate, JunOS, Palo, AWS, etc), via an adjacent Knocknoc Agent deployment
  • HAproxy can sit in front of the SSH service using the TCP feature

This allows Knocknoc to effectively add SSO (and MFA) atop SSH, working together to add heightened security for bastion hosts fast.

An on-host firewall orchestration approach is great for bastion hosts - or remove all SSH exposure from your external or internal environments.

This also allows Knocknoc to effectively add SSO (and MFA) atop SSH, working together to add heightened security for bastion hosts, fast.

Shown below, the user first logs in to Knocknoc (auth tied to their IdP), the Knocknoc orchestration-agent then receives instruction to open the firewall to port 22/tcp from the users IP address and the user then connects. No proxy/broker, no additional routing nor client installation is required, simple but very effective firewall orchestration.

This essentially removes attack surface of your SSH hosts until users centrally log in. 

data-flow-diagrams-20241210 copy-Detailed.drawio (3).png

When using the HAProxy approach, you may want to rebind your SSH server to different port in sshd_config, and then configure HAproxy to listen on port 22, and only proxy connections to the new port once the ACL condition from Knocknoc is met. This avoids any client-configuration changes and allows a fast, drop-in security uplift.

Or you may want to have an external HAproxy server with knocknoc-agent, proxy to internal SSH bastions in another DMZ or Internet-accessible host.

Back to top