How to circumvent Firewall blocks
This a quick guide on how to use ssh tunneling
Local Tunneling
In the below example, we can assume that you are allowed to ssh to 192.168.0.135 BUT you are not allowed to RDP to that machine.
ssh -L 8181:192.168.0.135:3389 [email protected]
Traffic sent to localhost:8181 on your machine is forwarded to 192.158.0.135, port 3389 via 192.168.0.135, bypassing the firewall blocking.
Forward Tunneling
In the below example, we can assume the following
- You are allowed to ssh to 192.168.0.2 (next hop)
- You are NOT allowed to ssh to 192.168.0.3 (end host)
- 192.168.0.2 IS allowed to ssh to 192.168.0.3
Stage It
ssh [email protected] -fNL 8081:192.168.0.3:22
Explaining the flags
-f
: This option tells SSH to run in the background after asking for the password (useful for persistent tunnels).-N
: Instructs SSH not to execute a remote command. It's used for forwarding ports only.-L
: Sets up local port forwarding, (to 192.168.0.3) on the intermediary PC. (from 192.168.0.2)
SSH to localhost
ssh end-host-username@localhost -p 8081
You can also now copy files etc
scp -r -P 8081 end-host-username@localhost:/path/to/files .
Dynamic port forwarding
The below example assume
- You are allowed to SSH to 192.168.0.135
- You are NOT allowed to do anything else (ie browse web etc)
ssh -D 8181 [email protected]
This creates a dynamic "Socks proxy"
Essentially all connections to localhost 8081 will be forwarded through the tunnel, to 192.168.0.135.
You can then enable "Socks" proxy on any browser, and once this is set up, all web requests will be forwarded to 192.168.0.135.
Dont forget to kill the process after you are done, with sudo ps -aux | grep 8081
and then kill pid
Reverse tunneling
Example: Remoting into work computer from home, or setting up a backdoor on a victim
on work computer/victim
ssh -R 8181:localhost:3389 [email protected]
on the other PC (when you get home)
open up RDP and connect to port localhost:8181
If this fails, then check /etc/ssh/sshd_config
for the following:
GatewayPorts yes
AllowTcpForwading yes
The Elephant in the room
When using SSH tunneling, you're essentially encapsulating one TCP connection inside another, which can lead to inefficiencies and issues:
- Interference between congestion control mechanisms
- Increased latency and jitter
- Head-of-line blocking
- Inefficient use of bandwidth
- Buffer bloat
This is where sshshuttle comes in.
In summary:
sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.
sudo sshuttle -r user@server 0/0
This will tunnel everything 0.0.0.0/0
to a remote host