So I’m here in California, staying at a hotel for ten days and want to look at some websites. Nothing too fancy, some blog entries, research for upcoming reports, maybe some racy stuff like No-Load Mutual Funds. And I am, of course, like you, on a free, open, wireless connection. My mail is tunneled, but web isn’t. So I realize I should set up a proxy server somewhere else, like at home, and tunnel into it, lest anyone sniffing on the local WiFi LAN (not that I’d ever do something like that with something like Wireshark) or indeed the hotel’s wireless contractor have a record of everything I look at and type.
No brainer: Squid’s your man. But in looking around for a plain-English How-To set up Squid and then use it guide, I couldn’t find one. So here it is. The first thing to do then, is install and configure Squid.
Setting Up Squid
Because I am on Gentoo, this was easy:
I bet on Debian it’s as simple as
sudo apt-get update
sudo apt-get install squid
Once Squid was installed, I saved the original /etc/squid/squid.conf file as a backup and then made this my new one:
cache_mem 50 MB
cache_dir ufs /var/cache/squid 500 16 256
maximum_object_size 102400 KB
acl my_network src 192.168.0.0/255.255.255.0
acl localhost src 127.0.0.1/255.255.255.255
acl all src 0.0.0.0/0.0.0.0
http_access allow my_network
http_access allow localhost
http_access deny all
Then save, and restart squid (or start it)
That, you’ll see, allows traffic from both local network and localhost but not to anyone else. We’re accessing via SSH, so once we’re tunneled in, we are on localhost.
I only allow access to the box via one port for SSH, and that is not a standard port. This little security-by-obscurity kludge was not for defense against hackers, but only to stop the bots from constantly knocking on my door and filling up my auth.log with automated login attempts. Those attempts were useless anyway because of the actual (non-obscurity-related) security measure: I don’t allow remote login with a keyboard password – you need a pre-saved key. Also, of course, the firewall does not accept connections to the Squid port – to get at that port, you need to SSH in and do port forwarding. (If anyone can tell me a better, safer way to do this I’d be obliged.)
There’s some other authentication stuff one could do quite easily (forcing a user prompt in the browser when users start a new session to authenticate to Squid via pam) that I feel comfortable ignoring in this case because I’m fairly confident about the physical access to the network (if that’s breached I have bigger problems) and also because web access to the box is limited as I’ve just described.
Setting Up The Tunnel
Now the trick is to get my machine here in the hotel to talk to Squid across an encrypted SSH tunnel lest I send my blog password and evidence of my looking at IBEX 35 stocks to everyone in my 17-floor hotel. This machine is an Ubuntu box, so I set up a simple SSH tunnel with port forwarding – using the technique first rattled off to me by Ian Sacklow, head of the Capital District Linux Users Group, while we were standing in a Barnes & Noble store about three years ago:
sudo ssh -L 3128:127.0.0.1:3128 email@example.com -p 7890 -f -N
The -L means bind the local port (given first) to the remote port (given last) of the server (given in the middle, wrapped between ::s). Put in a mnemonic way,
SSH BIND MY_PORT_HERE:server:THEIR_PORT_THERE.
By that standard, I’m binding port 3128 of my local machine (127.0.0.1) to port 3128 of the remote machine. Then I specify the remote machine with the firstname.lastname@example.org and specific port command (if that is required).
The -f sends the SSH shell to the background – but brings it back if the SSH server prompts for a password or sends something else back. The -N (in SSH2 only) says, “And while you’re in the background, don’t execute any remote commands,” or in this case, “Just set up the tunnel and make yerself scarce.”
If you’ve timed out a sudo session or if you have just opened the terminal, you’ll be first prompted for your user password to carry out the sudo part of the command. Once that’s done, if your SSH server allows you to use keyboard interactive logins and you don’t have a remote key, then you’ll be prompted for the password of the user name on the remote server. Enter it and if accepted, you should just return to a local user prompt. Same if you have an SSH key – after running the tunnel command, you’ll just be returned to a local user prompt.
Tip: If you set up the tunnel and you get a message saying that the local port is already in use, find out what’s using it: in this case, you’d run:
sudo lsof -i tcp:3128
That should get you info about what’s running. Kill it and then start the tunnel again. Unless you decide that you don’t want to kill it, in which case, you’d change the local bind to a different port. It doesn’t matter a whit to either SSH or Squid.
Setting up Firefox
Now things are easy. You’ve got Squid running on the remote server. You’ve got an SSH tunnel connecting you to it. Now just tell Firefox where to look. In Firefox select Edit -> Preferences -> Network -> Connection Settings. Tick the radio button marked, ‘Manual Proxy Configuration’, type E’127.0.0.1’ in the HTTP Proxy box and ‘3128’ (or whatever) into the Port box, click OK, then Close. Now type http://www.google.com into your URL bar and see what happens. With luck, you’ll get taken to Google.
To make sure you’re actually using the proxy, SSH into the Squid server box, and look at the tail of /var/log/squid/store.log. You should see something about google. To watch it change in near real time, do:
tail -f /var/log/squid/store.log
And surf to another location.
Web surfing in hotels or coffee shops is nasty stuff. This is one way to add a modicum of privacy to your activities at no cost but your time. Of course, corporate firewall requirements might require some modification to the tunnel commands to get out to your server, but shouldn’t present too much trouble. But beware – an entire industry exists which seeks to discover people engaged in just that kind of activity, which is certainly against your corporate access policy.