I have had to repeatedly jog my faulty memory concerning how to set up a SOCKS proxy. Thus, I am using this blog as my public sticky note to remind myself. Specifically, I forget what options I like to pass through the SOCKS aware SSH client when connecting to the SOCKS aware SSH server.
A SOCKS proxy is easy to set up. It’s nothing more than an SSH server and an SSH client that speak the SOCKS protocol. In my case, I use OpenSSH. If you use a different SSH server or some other form of making a SOCKS proxy, this little post will be of little use to you. However, stick around because there’s a note down below concerning the false sense of security many people have when using a SOCKS proxy.
There’s a handy little option in the OpenSSH client that allows for the creation of a a local port binding that immediately forwards traffic to that port to another machine: -D. After that part of the command, simply include the username and host for the OpenSSH server that you want all local traffic bound for that local port to be relayed through. It makes it all the sweeter if you have RSA keypairs set up between hosts.
In my case, I usually use this set of options:
ssh -fCND localhost:8080 email@example.com
Let me peel back those other three options that I use:
-fsends ssh to the background just before the command is executed.
-Nrefuses to execute remote commands. This way I know nothing is going to be run via the SSH connection on the remote machine. I’m paranoid.
-Ccompresses the TCP traffic. This might not be ideal if you have a good connection as it is stated in the man pages for the OpenSSH client that -C slows down your throughput on fast connections.
The applications that you want to use with the SOCKS proxy need to have explicit options to support it. It’s not something that can be done underneath the application without its knowledge. For example, most web browsers have an option to use a SOCKS proxy within their advanced options section.
You will want to go to the options page of your application and search for SOCKS support. From there, tell the application to use localhost:port# as the proxy. In my case, I made port 8080 to be the local port that listens for traffic and then forwards it to my remote server.
If you need a secure connection that can be put in place without an application’s knowledge, you’ll need to implement a VPN.
You’re Not as Anonymous as You Think You Are
If you’re using the SOCKS proxy for the purposes of secure browsing, know that your DNS requests are an entirely different application layer traffic. Unless your DNS client is also set up to use the SOCKS proxy, your DNS requests will be plainly visible on the network that you are trying to remain anonymous / protected on. This can cause problems if you’re on an untrusted network. Owning the DNS servers that a machine is using is one of the most sure ways of wreaking havoc.
Have any other SOCKS tips? Do you use a different client or server? Let me know in the comments.