Education
Abstract
This document explains how TCP connections with unencrypted traffic can be tunnelled through encrypted SSH channels (AKA Tunnels), in order to make use of the SSH asynchronous key encryption feature and be kept from being compromised by any potential cyber attacks.
The document also describes how SSH port forwarding (Tunnelling) may be used by bypass firewall restrictions for some of the TCP applications' ports that are known for their applications insecurity or vulnerability to the different kinds of cyber attacks, like HTTP.
Content
Basically, this article illustrates using SSH Port Forwarding to secure the network applications that use TCP only, such as: HTTP, FTP/TFTP, Telnet, NTP, POP/IMAP and SMTP. So, any other applications that use UDP like: NFS, DNS, BOOTP, DHCP or SNMP are out of the scope.
What is SSH Port Forwarding?
SSH port forwarding is all about using the SSH encrypted communication channels to encrypt/decrypt connections for other applications that use TCP, the ones which are mentioned above. SSH uses TCP port 22 for the server side as its official well-known port number, and so this port will be involved in all the connections initiated by the different applications mentioned. These applications will appear to the network (including switches, routers and even firewalls) as if they are using port 22. This means that the underlying traffic generated by these applications is completely transparent to the network. It won't be until these encrypted packets reach their destination when they will start to be recognized by their official well-known port numbers i.e. HTTP packets for example, will eventually use port number 80 to reach their destination.
How it works?
Assuming we are going to send and receive HTTP traffic, the port details would be as follows:
On server side:
1. HTTP server will receive/respond to the HTTP requests using port 80.
2. SSH server will receive/send SSH traffic on port 22.
2. SSH server will receive/send SSH traffic on port 22.
Note:
Make sure that Port Forwarding is enabled on server side by checking the value of the attribute AllowTcpForwarding located in /etc/ssh/sshd_config. The value is "no" by default:
AllowTcpForwarding no
Which means Forwarding is disabled by default. Set the value to "yes" to enable:
AllowTcpForwarding yes
On client side:
1. SSH client will send/receive SSH traffic on a random port (within the range: 1024 - 65535), let's say 1100.
2. HTTP client will send/receive HTTP traffic on a random port (within the range: 1024 - 65535), let's say 8080.
2. HTTP client will send/receive HTTP traffic on a random port (within the range: 1024 - 65535), let's say 8080.
The communication process:
We have many scenarios for the SSH port forwarding based on where exactly both source port (the port to be tunnelled) is located located. Let's discuss some of the scenarios in the next lines:
1. Local Port Forwarding:
In this scenario, the source port is located at the client side (the localhost), and hence the naming "Local". In this case, the communication process follows this procedure:
1.1. The client listens for any incoming connections on port 8080, then forwards it to the local SSH port 1100.
1.2. The traffic is encrypted and transferred through the SSH tunnel.
1.3. The encrypted traffic is received on SSH server port 22, decrypted and forwarded to port 80 for HTTP processing.
Here is the command format for establishing a local SSH port forwarding channel:
ssh -L <LOCAL_PORT>:<SERVER_NAME/IP ADDRESS>:<DESTINATION_PORT> USER@<SERVER_NAME/IP ADDRESS>
The -L flag specifies that connections to the given TCP port or Unix socket on the local host (the client) are to be forwarded to the given host and port, or Unix socket, on the remote side. Figure 1 below shows an example local SSH forwarding communication channel:
All you need to do in order to access the web page on the HTTP server side is to use the URL: http://localhost:8080. In this example you can also use:
http://10.10.10.10:8080
2. Remote Port Forwarding:
This scenario is quite similar to the previous one and serves the same purpose. The difference here is that the source port (on the client) is remote as the tunnelling is going to be initiated from the server side this time. In other words, the server is going to be local and the client is going to be remote.
The command format that will be run on server side would be as follows:
ssh -R <REMOTE_PORT>:localhost:<DESTINATION_PORT> USER@<CLIENT_NAME/IP_ADDRESS>
The -R flag specifies that connections to the given TCP port or Unix socket on the remote host are to be forwarded to the local side (in this case the server is local). Figure 2 below shows an example of a remote SSH forwarding communication channel:
One can also access the web page on the HTTP server side by using the URL: http://localhost:8080.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"Component":"Network Apps","Platform":[{"code":"PF002","label":"AIX"}],"Version":"","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]
Was this topic helpful?
Document Information
Modified date:
15 September 2021
UID
ibm10885244
Manage My Notification Subscriptions