SSH Tunneling or SSH Port Forwarding is a technique to send data with an existing SSH Connection. For example a corporate network has an internal web serveR noT accessible from Internet and you want access internal resources securely, the SSH Tunneling or SSH Port Forwarding allows external users to use the SSH Encrypted Tunnel to send Web Traffic to the internal server. Basically you will send a non-SSH traffic over the SSH Tunnel, this is why it is referred to SSH Tunneling, you tunnel a non-SSH traffic inside an SSH Tunnel.
If we take an analogy or a comparison, the remote access VPN has the same logic.
Remote access VPN connects securely external users to internal resources through a VPN Gateway which can be a Firewall or a Router.
External PC <-> VPN Gateway <-> Internal Web Server.
SSH Tunneling works the same ways.
External PC <-> SSH Server <-> Internal Web Server.
The SSH Server will act like a VPN Gateway.
Let's take an example with Putty Application.
In this topology we have a Web Server in the internal network which not accessible from Internet. The SSH Server is accessible from Internet using for example a Static NAT, and an external client located in the outside world.
The goal is to allow the external client to reach the web server through the SSH Server.
So first open the Putty application to access the command line of the SSH Server 192.168.1.61.
In the Tunnels field, you enter the destination IP Address of the web server 10.1.6.150 and the port it listens to.
In the Source Port field select any port you desire, for example 8888.
The first step when you click the Open button, you connect to the SSH Server.
But in the background when you type 127.0.0.1:8888 in the web browser on the external client, you are redirected to the web server 10.1.6.150. Below the SSH Server and the netstat output.
But there are security risks with The SSH Tunneling, if you allow SSH using port-based filtering with the standard port 22, bad actors can use the SSH Port Forwarding as an evasion technique to send non-ssh traffic inside the SSH tunnel, which increases the attack surface because any application can use an open port.
Using the port-based filtering to allow the standard SSH Port, any application, SSH or not is allowed, so what if inside the SSH Tunnel there is threat or non-legitimate connection to your internal resources ? This is why, it's alway recommended to create policy rules based on application, not port.
So when you used SSH application in your policy rule as a matching criteria to allow SSH. Any application that is not identified as SSH is blocked, denying any attempt to do SSH Port Forwarding, therefore you reduce attack surface.
