Proxying Web Traffic Via SSH

In an attempt to preserve the magic of SSH: You don’t need a VPN to proxy your web traffic. You can instead proxy browser data through an SSH tunnel using a SOCKS proxy.

Setting up a SOCKS5 proxy for your web traffic:

1. Spin up an instance you can SSH into. You can use any cloud provider, or hardware like a Raspberry Pi.

2. SSH into that instance while binding a port on your local machine to SSH (port 8081 in this example, can be changed):

3. Change your browser proxy settings to point to localhost port 8081 (127.0.0.1:8081) and specify it is a SOCKS v5 proxy.

You can use a browser extension such as FoxyProxy to make it easier to switch proxy settings. Optionally, enable remote DNS to ensure those requests are also sent to the proxy server instead of being resolved locally.

4. Browse the internet! Your traffic will seem to be coming from your proxy server.

Here’s the setup using an Azure instance in Korea.

1. Ensure you have an SSH key generated on your machine.

To generate an SSH key, run:

Your public key will be saved under ~/.ssh/id_rsa.pub

Your PRIVATE key will be under ~/.ssh/id_rsa and should never leave your system.

2. Log into your Azure portal, and create a new Virtual Machine in a region you want your traffic to originate from.

In this example, I used an Ubuntu 20.04 LTS server, and set the region to (Asia Pacific) Korea Central.

3. Scroll down to the “Administrator account” section, and set the authentication type to be an SSH public key, and the source to “Use existing public key”.

4. Copy the contents of your public key and paste them as your SSH public key in Azure.

To copy your SSH public key, run:

5. Review and create your instance, it will automatically be assigned a public IP address.

6. Once it is created, search for “Virtual Machines” and find the IP address assigned.

7. Connect to the IP via SSH, binding a port for SOCKS:

Optionally, use this instead (arguments explained below):

8. Launch Firefox and install the FoxyProxy Basic extension. This is optional and you can instead change the proxy settings in your browser directly. I like to use a browser dedicated for testing.

9. Click on the extension, then on “Options”, then “+ Add”.

10. Fill in the details as per the screenshot below. Note we’re connecting to our port bound to SSH on localhost, and that this particular shade of fuchsia is critical.

11. Enable the proxy by clicking on the extension and your proxy name, which should add a colored bar to the extension logo.

12. Your traffic now appears to be coming from the region associated with your instance!

Here’s a before/after comparison, my real location is New York, and after enabling the proxy, it appears to be Korea, which is where my Azure instance is located.

Before:

After:

Web servers you browse to will now see the IP of your instance as your origin:

What is SOCKS5?

The fifth version of the SOCKS protocol (RFC1928) which operates at layer 5 of the OSI model, and proxies TCP and UDP connections. It does not add additional encryption, which we get from SSH instead. It does not support network-layer gateway services, such as ICMP.

What’s the impact of SOCKS not encrypting traffic?

If you are using HTTPS, your web traffic is encrypted between your browser, and the destination web server.

If you are using a protocol that does not offer a layer of encryption, like HTTP or DNS:

Therefore, system administrators controlling your local machine, or the machine you SSH into, may be able to see traffic that is not already encrypted at a higher layer.

Toggle remote DNS depending on which network you want resolving those request.

What’s the benefit of encapsulating SOCKS within SSH?

Combining both adds a layer of encryption in transit, allows you to bypass firewalls, and makes your traffic originate from a different location.

If you do not trust your local network, but trust your local machine and cloud jump box, it allows you to create an encrypted tunnel out of the network, and initiate your connections from outside.

This bypasses many content monitoring/filtering systems, and some Data Loss Protection (DLP) controls, since they typically assume HTTP(S), and do not have any introspection into your SSH traffic.

As always, security and privacy are not guaranteed if the system is not yours.

Is a VPN more secure?

It depends on configuration and use case.

You can use a VPN vendor, in which case your traffic goes through a server you do not own nor control. Alternatively, you can set up your own OpenVPN server. You’ll have to separately configure it, set up user accounts, etc.

Instead, proxying traffic via SSH means you already have a user account on a server you can securely connect to (using SSH keys), and do not need any additional setup, limiting the number of services exposed on your server, and using existing authentication methods. You can configure additional SSH users to allow SOCKS5 proxying without a shell nor the ability to run commands on the server.

On the client side, a VPN profile may not necessarily be configured as a full-tunnel solution, hence only part of your web traffic could be going through the VPN, and the rest leaked through your local ISP. In the case of a SOCKS5 proxy, all of your web traffic is being proxied as configured in your browser’s settings. Although, operating system traffic, and anything that is not encapsulated within TCP or UDP, will not go through your SOCKS5 proxy.

A VPN solution’s main benefit is ease of setup and use (if you go with a vendor and do not want to maintain your own infrastructure), and the ability to be configured as a full-tunnel system-wide proxy.

Does this solution scale?

This is not meant as a long-term scalable solution, but you can have multiple users SSH’d into the same server.

I did not test the upper bound of how many SSH users could simultaneously browse via SOCKS5, let me know if you do.

Is it easy to tell I’m proxying my traffic through a cloud provider?

Yes, public IP addresses assigned to cloud VMs belong to a pool of IPs registered to the provider. In the example I used above, the IP is known to be associated with Microsoft Azure. Some web application firewalls can be configured to block or flag traffic originating from known datacenter IPs.

Can this be used on a pentest?

Typically yes! Depending on the rules and scope of engagement, pentesters often find themselves with SSH access, either to a jump box or a compromised host. You can use this solution to interact with web applications that are only available on the internal network.

Can this be used with an intercepting proxy such as Burp Suite?

Yes, if you need to inspect or modify web traffic, proxy your browser traffic through Burp Suite normally, and then redirect the requests on Burp to a SOCKS5 proxy at the port bound to SSH, for example: 127.0.0.1:8081

Here’s what it would look like:

[This post was originally published April 1st 2023 on LinkedIn]