The very first post on this blog, Is the Shadow Web a Reality? (Updated) discussed a mythological concept called the “Shadow Web,” which was based on the creepypasta entitled A Warning to Those Thinking About Accessing the Shadow Web. While the so-called “shadow web” itself has been debunked, there’s a part of that article that’s worth revisiting: SSH tunneling.
For context, a user on Quora at that time, in response to the question “What’s the worst thing you’ve seen on the dark web?” had claimed that she “invested in a non-American SSH tunnel and started digging even deeper.” Her answer, however, had a number of technical holes in it. SSH stands for “secure shell.” SSH tunneling, in the realm of reality, as opposed to creepypastas, is a method of accessing remote servers (which are sometimes restricted), or to make remote resources accessible on a local system. It’s also known as port forwarding. SSH tunneling literally means routing local network traffic through SSH to remote hosts; in and of itself, it’s nothing scary.
One use of SSH is to set up a basic version of a VPN, in order to create a secure connection over unsecured networks like the internet (i.e. the internet and private networks are not the same, though people may use the terms interchangeably). An SSH session allows tunneling network connections under its default settings. Three types of port forwarding exist: local, remote, and dynamic port forwarding.
You can connect to a remote server using SSH this way. One method is to configure passwordless SSH login between local and remote hosts; as a result, it will not ask for the admin’s password.
Local SSH Port Forwarding
Local SSH port forwarding gives you the ability to connect from your machine to a remote server. For example, if you are behind a firewall that restrains access to an application, or barricaded by an outgoing firewall from reaching an application running on port 3000 on your server, local SSH port forwarding can advance through this.
For instance, you can forward a local port (such as port 8080), which you can then use to reach an application locally, as such [replace “fakeserver” and “fakesite” with yours, of course]:
$ ssh firstname.lastname@example.org -L 8080: fakeserver.fakesite.com:3000
If you add the -N flag, this indicates to not execute a remote command.
$ ssh -N email@example.com -L 8080: fakeserver.fakesite.com:3000
If you then add the -f switch, this instructs SSH to run in the background.
$ ssh -f -N firstname.lastname@example.org -L 8080: fakeserver.fakesite.com:3000
Afterward, on your machine, open a browser, such as Firefox. You should be able to access the remote application using localhost:8080 or 192.168.43.41:8080.
Remote SSH Port Forwarding
Remote SSH port forwarding works in the opposite manner of local SSH port forwarding; this allows you to connect from your remote machine to a local one. Under normal circumstances, SSH does not allow remote port forwarding. You can enable it in the GatewayPorts directive in the SSHD configuration file etc/ssh/sshd_config, which is on the remote host.
Open the file in order to edit it using whichever text editor you prefer (Vim, for instance), and set the value under GatewayPorts to “yes.” (Note: the SSHD config file may be located in a different folder on your machine.)
When you finish adding the new value, save the file and exit the text editor. Afterward, restart sshd:
$ sudo systemctl restart sshd [or] sudo service sshd restart
Once sshd has been restarted, you need to forward port 5000 on your remote machine to port 3000 on the local machine.
$ ssh -f -N email@example.com -R 5000:localhost:3000
Dynamic SSH Port Forwarding
Dynamic SSH port forwarding, unlike the first two, allows a variety of TCP communications with a range of ports; local and remote only allow communication with a single port. The dynamic version makes your device act as a SOCKS proxy server which listens on port 1080.
To start a SOCKS proxy on port 1080, use this command:
$ ssh -f -N -D 1080 firstname.lastname@example.org
After setting this up, it is now possible to configure apps on your device to use the SSH proxy server so they can connect to the remote server. Be that as it may, the SOCKS proxy won’t run after you end your SSH session.
You may be asking, “What does all this have to do with the so-called shadow web?” Nothing, really – but in a real world example, were you to use port forwarding to access someone else’s site or database that was unprotected, there’s a chance that you could see content that wasn’t intended for you. It can also be taken advantage of by attackers in various ways. Therefore, it is possible, although unlikely, that you could see something disturbing.