Introduction

Often I tunnel my web traffic through a SSH connection to a remote machine to have my HTTP and HTTPs connections originate from it. I do this for many reasons, the most common being that

  • I don’t trust the network I’m on so I don’t want to send my unencrypted HTTP traffic through it or that
  • there is a firewall that prevents me from getting from my laptop to a given server. For example, I can only get to most of the internal Google web servers from an IP address inside Google’s network.

This post explains how I do it. Basically, I establish an SSH connection with certain parameters that allow me to tunnel traffic through it and then configure Firefox to use the tunnel and to never do DNS lookups by itself.

Establish the SSH connection

Randomly select a port that is currently unused in your client machine. In this article we will refer to it as $PORT. If you don’t know which port to pick, pick a random number between 10.000 and 20.000, chances are it won’t be in use in your client machine.

Establish your SSH connection to your server as you usually would, but pass a -fND $PORT option. For example:

ssh -fND localhost:$PORT azul@freaks-unidos.net

Once you log in, the SSH process will go into the background and the tunnel will be established.

If you actually want to use the SSH connection for more than just the tunnel, do not pass the f nor the N options, just -D localhost:$PORT.

Note that although the localhost: part in the SSH command is optional, you should specify it to restrict the tunnel to processes running in your machine. Otherwise other users of your local network who knew about your tunnel would be able to use it.

Configuring Firefox to use the Tunnel

In Firefox click on the menus Edit > Preferences. Pick the Advanced tab and click on Settings next to Configure how Firefox connects to the internet. Select Manual proxy configuration, enter localhost in the SOCKS Host text field and enter the port you used for your tunnel. Close the dialog to apply the settings.

At this point most the traffic from Firefox will go to the port selected, where the SSH process will pick it and send it encrypted to your SSH server, which will in turn establish the actual connections to the web servers. There are two exceptions:

  • Hosts listed in the No proxy for setting. By default this setting lists localhost and 127.0.0.1. You could add other hosts or IP addresses if you want Firefox to connect to them directly (instead of using the tunnel).
  • Firefox will still do DNS lookups for the hostnames.

Configure Firefox to use the Tunnel also for DNS

To prevent Firefox from doing NS lookups enter about:config in the URL text field and double click on the network.proxy.socks_remote_dns to set it to true.

The following are reasons for you to prefer sending DNS traffic through the Tunnel instead of through the local network:

  • Although other users in your local network won’t be able to see your actual web traffic, they can still see the hostnames of the sites you are connecting to.
  • Your web content may have many URLs such as http://www/foo.htm, where your SSH server will be able to correctly resolve the hostname but, for different reasons, your client may not.

Voila, at this point Firefox will be sending all its traffic (except, again, for the No proxy for servers) through your SSH tunnel.

Verifying that it is working

At this point your tunnel should be working.

If you still wanted to verify it (rather than trust this guide from someone you don’t know, right?), run Wireshark or Tcpdump in your machine and double check that all network packets from Firefox are being sent encrypted through your SSH connection

Closing the tunnel

To close the tunnel simply kill the SSH process. Don’t forget to undo your Firefox configuration.

If you find that you’re changing your Proxy configuration often, you may want to install the FoxyProxy application, which lets you:

  • Change which proxy to use based on priorities and regular expressions on the URLs.
  • Change the default proxy from a list of pre-defined proxies with a single click.

One of the more neat things you can do with the versatile utility lsof is use it to recover a file you’ve just accidentally deleted.

A file in Linux is a pointer to an inode, which contains the file data (permissions, owner and where its actual content lives on the disk). Deleting the file removes the link, but not the inode itself – if another process has it open, the inode isn’t released for writing until that process is done with it.

To try this out, create a test text file, save it and then type less test.txt. Open another terminal window, and type rm testing.txt. If you try ls testing.txt you’ll get an error message. But! less still has a reference to the file. So:

> lsof | grep testing.txt
less	4607	juliet  4r  REG 254,4   21
           8880214 /home/juliet/testing.txt (deleted)

The important columns are the second one, which gives you the PID of the process that has the file open (4607), and the fourth one, which gives you the file descriptor (4). Now, we go look in /proc, where there will still be a reference to the inode, from which you can copy the file back out:

> ls -l /proc/4607/fd/4
lr-x------ 1 juliet juliet 64 Apr  7 03:19
             /proc/4607/fd/4 -> /home/juliet/testing.txt (deleted)
> cp /proc/4607/fd/4 testing.txt.bk

Note: don’t use the -a flag with cp, as this will copy the (broken) symbolic link, rather than the actual file contents.

Now check the file to make sure you’ve got what you think you have, and you’re done!

Problem

You want to save (capture) a RealAudio or RealVideo stream to a file for later
viewing or listening.

Keywords

Real, RealAudio, RealVideo, capture, record, streaming, stream, rip, ripping,
mplayer, Linux.

Solution

mplayer -noframedrop -dumpfile out.rm -dumpstream rtsp://url/to/file.rm

(Michael Carr notes that passing a -bandwidth N option, where N is
your available bandwidth may considerably speed up the download; the mplayer
manual seems to be unclear about it being bits or bytes, though.)

When the download is done you can watch or listen to out.rm with
a media player, like realplay or mplayer.

atheists

Sometimes we want to enable our servers/desktops to be able to send email without setting up a full featured mail server or configuring postfix to route through Gmail.

sSmtp is an extremely simple, resource conserving, SMTP server that will allow your desktop or server to send email. In this article we are going to use sSMTP to send outgoing email through Gmail.

Install sSMTP

Debian/Ubuntu users can Install with this command or click here to open up apt:

sudo apt-get install ssmtp

We need to then need to edit, ‘/etc/ssmtp/ssmtp.conf’:

root=username@gmail.com

mailhub=smtp.gmail.com:587

rewriteDomain=

hostname=username@gmail.com

UseSTARTTLS=YES

AuthUser=username

AuthPass=password

FromLineOverride=YES

Then add each account that you want to be able to send mail from by editing, ‘/etc/ssmtp/revaliases‘:

root:username@gmail.com:smtp.gmail.com:587

localusername:username@gmail.com:smtp.gmail.com:587

Now try sending an email

You can send an email through your favorite email client, like ‘mutt‘, or type:

sudo ssmtp someemail@email.com

You will then type your message, hit enter and ‘ctrl+d

Now that you have a simple outgoing email server setup, you can do all sorts of neat things:

  • Configure cron jobs to send log reports to your email address
  • Alert you of all kinds of system changes
  • Send email alerts when your computer reaches a certain temperature
  • Send email through PHP, Python, Ruby, and Perl

<!–This entry was posted
on Monday, June 29th, 2009 at 5:00 am and is filed under Linux.
You can follow any responses to this entry through the RSS 2.0 feed.

You can leave a response, or trackback from your own site.

–>