Listen to this Post
Introduction:
SSH port forwarding (tunneling) leverages the Secure Shell protocol to encrypt and redirect network traffic from one port to another, creating a secure channel across untrusted networks. This technique is essential for cybersecurity professionals—both red teams seeking to pivot through firewalls and blue teams needing to harden access to internal services.
Learning Objectives:
- Implement local, remote, and dynamic SSH port forwarding using Linux and Windows commands.
- Apply tunneling for penetration testing, secure API access, and cloud environment hardening.
- Detect and mitigate malicious SSH tunnels through logging, configuration restrictions, and monitoring.
You Should Know:
- Local Port Forwarding: Access Remote Internal Services Securely
Local forwarding sends traffic from a local port through the SSH server to a target destination. This bypasses firewalls that block direct access to internal services (e.g., a database behind a corporate firewall).
Step‑by‑step guide (Linux & Windows OpenSSH):
- On your attacking or client machine, run: `ssh -L [bash]:[bash]:[bash] [bash]@[bash]`
– Example: `ssh -L 8080:internal-db.local:3306 [email protected]` – now connect your local app to `localhost:8080` to reach the remote MySQL server. - Verify with `netstat -tulpn | grep 8080` (Linux) or `netstat -an | findstr 8080` (Windows PowerShell).
Use case in pentesting: Expose an internal web server on `10.0.0.5:80` through a compromised jump box to your local browser.
- Remote Port Forwarding: Expose Local Services to the Internet
Remote forwarding allows a service on your local machine to be accessible from a remote SSH server, enabling external teams to reach your internal dev environment.
Step‑by‑step guide:
- Command: `ssh -R [bash]:[bash]:[bash] [bash]@[bash]`
– Example: `ssh -R 2222:localhost:22 [email protected]` – anyone who can connect to `public-server.com:2222` will reach your local SSH daemon. - On Windows (OpenSSH installed), same syntax works in PowerShell or CMD.
- Security caution: Set `GatewayPorts yes` in `/etc/ssh/sshd_config` to allow binding to non‑localhost interfaces; otherwise, only the SSH server’s localhost can connect.
- Dynamic Port Forwarding (SOCKS Proxy): Route All Traffic
Dynamic forwarding creates a SOCKS proxy on your client, forwarding any TCP traffic through the SSH server. This is ideal for pivoting or privacy.
Step‑by‑step guide:
- Start proxy: `ssh -D [bash] -N -C [bash]@[bash]` (
-Nprevents shell, `-C` enables compression) - Example: `ssh -D 9050 -N [email protected]`
– Configure your tool to use SOCKS5 at127.0.0.1:9050: - Browser: FoxyProxy or manual settings.
- Command line: Use `proxychains` (Linux) – edit
/etc/proxychains.conf, addsocks5 127.0.0.1 9050, then runproxychains nmap -sT 192.168.1.0/24. - Windows alternative: Use `ssh -D 1080 [email protected]` and set Windows network proxy or use
Proxifier.
4. Pivoting for Red Team: Multi‑Hop Tunneling
Attackers often chain SSH tunnels to traverse network segments. This technique allows reaching subnets behind multiple firewalls.
Step‑by‑step guide (Linux example):
- Assume you compromise Host A (direct SSH), which has access to Host B (internal). Host B can reach Target C (restricted).
- From your machine: `ssh -L 2222:Host_B:22 user@Host_A` – tunnel to Host B.
- Then from a second terminal: `ssh -L 3333:Target_C:443 user@localhost -p 2222` – forward through Host B.
- Now access `https://localhost:3333` to reach Target C’s HTTPS service.
- For Windows, use `plink` (PuTTY command line) similarly:
plink -L 2222:Host_B:22 user@Host_A.
- Detection & Mitigation: Defending Against Malicious SSH Tunnels
Security teams must identify unauthorized tunneling. Here’s how to harden your environment.
Step‑by‑step hardening:
- On SSH servers, disable unnecessary forwarding: edit `/etc/ssh/sshd_config` – set `AllowTcpForwarding no` (global) or
PermitLocalCommand no. For per‑user restrictions, use `Match User` blocks. - Monitor logs: `grep “forwarding” /var/log/auth.log` (Linux) or Event Viewer on Windows (OpenSSH/Operational). Look for unexpected
-L,-R, or `-D` usage. - Network detection: SSH tunneled traffic shows high byte counts on port 22 but no typical shell activity. Use Zeek (Bro) scripts to alert on long‑duration, high‑volume SSH connections.
- Implement forced commands or restrict shell access: `command=”/bin/false”` in authorized_keys for jump hosts.
- Cloud & API Security Hardening with SSH Tunnels
In cloud environments (AWS, Azure, GCP), SSH tunnels protect API calls and database connections that would otherwise traverse the internet.
Step‑by‑step for securing a cloud database:
- Provision a bastion host (EC2 instance) with public IP and strict security groups (allow SSH only from your office IP).
- From your dev machine: `ssh -L 5432:rds-database.region.rds.amazonaws.com:5432 -i key.pem ec2-user@bastion-ip`
– Now connect your application to `localhost:5432` – all traffic is encrypted inside the SSH tunnel, avoiding plaintext database auth over the internet. - Automate with `autossh` (Linux) or `ssh -fNT` for background tunnels. On Windows, schedule a PowerShell script using `Start-Job` for persistent tunnels.
7. Windows Implementation: OpenSSH and Plink Commands
Windows 10/11 includes native OpenSSH Client. For older systems, PuTTY’s `plink` offers lightweight tunneling.
Native OpenSSH on Windows PowerShell:
- Same syntax as Linux: `ssh -L 8080:intranet.local:80 user@ssh-server`
– To create a dynamic SOCKS proxy: `ssh -D 1080 -N [email protected]`
– Persist with Windows Service: `New-Service -Name “SSHTunnel” -BinaryPathName “C:\Windows\System32\OpenSSH\ssh.exe -D 1080 -N [email protected]”`
Using Plink (download from PuTTY site):
- Local forward: `plink -L 8080:intranet.local:80 user@ssh-server -pw password`
– Remote forward: `plink -R 2222:localhost:22 user@public-server`
– Run hidden: `plink -batch -ssh user@gateway -L 3306:internal-db:3306` and use `start /B` or a VBS script.
What Undercode Say:
- Key Takeaway 1: SSH tunneling remains a double‑edged sword—indispensable for secure remote access and red‑team pivoting, yet easily abused if organizations fail to restrict `AllowTcpForwarding` and monitor for anomalous SSH behaviors.
- Key Takeaway 2: Modern cloud and API security heavily rely on bastion‑hosted SSH tunnels to encrypt traffic to managed databases, but misconfigured dynamic forwarding can turn a single compromised jump box into an open proxy for entire internal networks.
Analysis: The techniques shown—local, remote, dynamic forwarding—are foundational for any penetration tester and system administrator. Defenders must move beyond simple firewall rules and implement SSH configuration audits, session logging, and behavioral detection (e.g., using Zeek or EDR rules for unusual port‑forwarding patterns). Red teams, meanwhile, will continue combining SSH tunnels with tools like `chisel` or `FRP` to evade deep packet inspection. The rise of zero‑trust networking (ZTN) may reduce reliance on traditional SSH bastions, but for the next 3‑5 years, SSH tunneling will remain a core skill in every security engineer’s toolkit.
Prediction:
As organizations adopt zero‑trust architectures and micro‑segmentation, SSH tunneling will face increased scrutiny—expect AI‑driven detection engines that model normal SSH user behavior (typical command lengths, shell activity, forwarded port ranges) to flag covert tunnels in real time. However, attackers will respond by embedding tunnels inside legitimate encrypted sessions (e.g., SSH over WebSockets) or abusing cloud native proxies. The arms race will push SSH vendors to implement fine‑grained, policy‑based forwarding controls and integrate with identity‑aware proxies, making explicit allow‑listing of forwarded destinations the new standard for secure enterprises by 2028.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecurity Ethicalhacking – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
