Socksify Anything

April 15, 2010

As a follow-up to one of my posts awhile back, I figured I’d share a small tip with those who don’t use SOCKS proxies quite as often as I do. In my previous post, I showed how to set up an SOCKS proxy that tunnelled your (now encrypted) traffic through a remote SSH server, as well as how to configure Firefox to use that tunnel. But what if your application doesn’t support SOCKS proxies? And what if you want to tunnel through multiple hosts (I’m sure you could think of a situation :P)?

Well, you’re in luck: proxychains can handle all of that. When used to execute an application, proxychains acts a middleware layer, intercepting all TCP connections, wrapping them in the SOCKS protocol, and routing them through the proxies of your choice. If you’re on Ubuntu, it’s, as usual, brilliantly easy to install. One “sudo apt-get install proxychains” and you’re good to go. Now how do we go about using it?

The first thing you need to do to use proxychains is to set up a configuration file. On Ubuntu (and I’m assuming, any other install), there is a default file in /etc/proxychains.conf that you can look at for guidance, but I have included mine for reference just in case. Now, there are three places proxychains will look for a config file when it is executed: in the local directory, at ~/.proxychains/proxychains.conf , and in /etc/proxychains.conf (and they are prioritized in that order). Chose yours according to what works best for you. I’d assume that either your home folder or etc folder would be the best, as it will work without a fuss no matter what your $PWD is. Now, the proxychains config has a good number of options, so you’ll need to know what’s best for you. For most, the dynamic chain is best: it functions as long as one of the proxies in it’s configuration page is online. I’d also recommend enabling proxy_dns if it’s not on, to prevent DNS leakage. The rest of the default options should be fine. After that, all you need to do is add your proxy in the form of “proxy_type host port”, which, if you’re using an SSH proxy like in my previous post, will be something like “socks4 6789” .

Now save the file, and you’re ready to go. If you, say, want to update your system, all you need to do is “sudo proxychains apt-get update”, and away it goes. If you want to chain your traffic through multiple hosts, simply add more to your config file, and run “proxychains ./myapp”. Enjoy!

Update 04/16/2010: As mentioned in a previous post, tsocks is also a good application for socksifying connections, and worth trying if proxychains doesn’t work for you. However, you can’t (as far as I know) use it to chain multiple proxies together, so keep that in mind.

Reblog this post [with Zemanta]

Once again, I find myself singing the praises of SSH. Seriously, is there much of a reason to have any other ports open anymore? The latest trick I have added to my list of things SSH can do is presenting a remote filesystem, securely.  Now, I’m sure most of us are aware that you can transfer files over SSH using a protocol called SFTP. What you may or may not be aware is that you can mount this remote filesystem locally using a nifty little tool called SSHFS. This is incredibly useful in a number of situations, allowing you to access remote files in a way that is easy for the user (as easy as local filesystems), easier to set up than solutions such as NFS, and as secure as SSH itself.

All you have to do on the remote machine you wish to access is have OpenSSH listening somewhere. For the client machine, you need to make sure you have SSHFS installed. To do this on Ubuntu, simply run:

sudo apt-get install sshfs

Now, to mount the filesystem locally, we first need to create a mount point for the filesystem:

mkdir /path/to/mountpoint
chown user /path/to/mountpoint

Where user is your username and sshfs is the location of the mountpoint. Now, to go ahead and mount the remote filesystem, simply execute this command with your own information inserted:

sshfs remote-username@address.of.server:/remote/folder/to/mount /path/to/mountpoint

Enter your password, and that’s it! Your remote filesystem should now be mounted.

Well that’s pretty cool in itself, but what if we want to go farther and have it mount at startup without any interaction from us? No problem, thanks to another cool feature of SSH called public key authentication. This feature allows us to log in to a system without providing the password of the user we are authenticating as, and instead authenticating users based on their RSA keys. If you trust me that this is secure, you can skip the next paragraph, but if you don’t, or you are curious how this works, read on.

The initial key exchange that SSH does is encrypted using an asymmetric encryption algorithm called RSA. In this key exchange, the goal is to exchange a symmetric key (AES, DES, whatever  you want) over RSA, which is unfortunately too slow to handle the large amount of data that needs to be encrypted to secure all of the SSH traffic. It is ideal, however, for assuring that a key exchange stays secure. The way it works is that each participant, both client and server, have a public key and a private key, and you give out the public key to anyone you want to be able to send you data. Once encrypted with the public key, the only way you can decrypt the data is with the private key, which only the local computer has. This technique has the useful property of providing both confidentiality and, as long as the private key is kept secret, authenticity. This means that as long as the private key is kept secret, you can authenticate to a system based solely on the public key, because no one but the authorized machine should be able to decrypt the proper symmetric key if it does not have the private key. If you would like more explanation than the incredibly brief overview I just gave, go check out the Wikipedia articles on RSA and on SSH, it should give you all the information you want.

Now that you don’t feel like you’re doing something incredibly dangerous (or maybe you still do, and you just like danger…:P ), follow these steps provided by OpenSSH on how to set up public key authentication between two hosts.  Once done, all that’s left to do is add the sshfs command that we used earlier to mount the remote filesystem to a startup script somewhere. To do this in Ubuntu/GNOME, you can simply go to System->Preferences->Startup Applications and add a new entry that uses our command from earlier as the command to be executed at login. If you are not on Ubuntu or using GNOME, you should be able to find documentation somewhere on how to make something run on startup.

That’s all there is too it, hope someone finds it useful. Just a short note, if you need to unmount the share, simply execute sudo umount /path/to/mountpoint and you’ll be fine. Enjoy!

Reblog this post [with Zemanta]

It seems that not a week goes by any more that I don’t find some new, fun trick to do with SSH. A few weeks ago, I found one that to me has been especially useful.

I was sitting in the Tulsa International Airport, once again wishing that airports would just suck it up and provide free wireless access throughout their terminals. It’s a real pet peeve of mine, as layovers become incredibly more painful when I can’t waste away my time stumbling about the internet. I might even have to do something *shudder* productive…

Anyway, there I was, sipping some coffee and working on a project, when I noticed that there was an open wireless network available that was not one of those god forsaken Boingo hotspots. Being the curious person that I am, I decided to see if I could connect. Sure enough, it let me right on. Being the cautious person I am, I went to an HTTPS secured site to see what would happen. And sure enough, the normally valid certificate was invalid, pretty much guaranteeing someone was trying to listen in.  I was still happy though, at least I still I had internet access and could keep myself mildly entertained with that.

However, I was feeling especially curious that day, so I decided to try to tunnel my traffic over SSH to a box back in my apartment, keeping my oh-so precious personal data away from prying eyes. Besides, beats working. After a little digging through man pages, this task, to my surprise, turned out to be much simpler than I had expected. All you need is one SSH command and an SSH server that you have access to and has forwarding enabled (the default OpenSSH installation on Ubuntu does).

If you don’t have an SSH server set up and you’re using Ubuntu at home, simply execute this on your home machine:

sudo apt-get install openssh-server

This will install and start the service. Make sure that a.) your user password is of decent strength (SSH is a common target for password bruteforcing) and b.) that you have port 22 forwarded on your router if you are behind a NAT so that you can access it from outside of your local network. The SSH client should already be installed on a default Ubuntu install (you can also do this using PuTTY on windows).

Once you have these two things ready, just open up terminal on your laptop/netbook/mobile device and type the following:

ssh -Nf -D randPortNum

Replace randPortNum with a port number of your choosing (something above 1024 if you are not root, which is probable), remote-username with your username on the remote system, and with the hostname or IP address of your SSH server. If you are using your home server, I’d suggest using DynDNS to get a simple domain name to access it with. If you do not feel very comfortable with the command line, or you are lazy like me (I hate having to close the window after I’m done…), you can execute this command using Alt+F2, and the SSH client will prompt you for your password.

Now let me explain what exactly this command is doing. The N and f flags both specify that the command is to be forked into the background, so that you can do whatever you want after you execute it. Close the terminal, keep using it for something else, anything you please (just not killall ssh!). The D flag is the one doing the really interesting stuff: the OpenSSH developers decided it would be cool to put SOCKS proxy functionality straight into the client, and the D flag is how you access it. Basically, you are just telling SSH to start “local dynamic application-level port forwarding” (SOCKS proxy) from the specified port on your local machine to the remote host. Now, any program on your computer that supports SOCKS proxies will be able to connect to that port on your machine and have its traffic automagically forwarded (and encrypted!) across the internet to your remote machine, where it will then go out to its destination.

To add to it, tons of programs do support SOCKS proxies, more than you might think. Firefox, Opera, Pidgin, Deluge, Transmission (Tracker only), the list goes on. On top of that, using some programs (like tsocks) you can actually use any TCP based program over it. Very cool stuff.

To go ahead and encrypt your web traffic, open up Firefox (if you need Opera instructions, they’re probably very similar).  Go to Edit->Preferences->Advanced->Network->Settings (Configure How Firefox Connects To The Internet) . Select “Manual proxy configuration”, enter “localhost” for your SOCKS host and the port number you chose earlier as your port. Either SOCKS 4 or 5 should work (I use 5). Now, it should look similar to the picture below:

An Example Configuration

An Example Configuration

Now just click OK, close out the Settings dialog, and you’re done! Go here and check it out, your IP is now the same as the remote host’s. If you’re really paranoid, you can also make Firefox tunnel your DNS queries over the proxy. This prevents the nameserver of the local network feeding you bad DNS information or keeping tabs on what you are viewing (you are still relying on the remote nameserver being trustworthy though :P) . To do this, open up a tab, enter the address “about:config”, search for “network.proxy.socks_remote_dns” and set it to true. And that’s it!

This trick can be immensely useful in many situations, from securing your traffic across untrusted local networks, to getting around packet shaping/filtering, to remaining anonymous online. I now use it all the time on my laptop, and very rarely trust the local network. A word of warning before I sign off though, I was lucky on that hotspot because the attacker was not trying to launch a MITM attack against my SSH traffic. If they had, the keys would not have matched my previous connection attempts to my SSH server, and I would have been warned in big bold letters that I was being listened in on, and the SSH client would have quit. In this situation, securing your traffic may be more difficult, but not impossible. I may post later on how one might go about this.

Anyway, hope someone else finds this as useful and interesting as I do. As always, feel free to ask if you have any questions.

UPDATE 04/15/2010: I have done a follow-up post to this article describing how you can use proxychains to allow any program that uses TCP sockets to tunnel traffic over SOCKS proxies, not just ones that have built-in proxy support. I also show how to chain multiple proxies together.