• No results found

Bypass restrictive firewalls using SSH tunnelling

Create a SOCKS proxy server and get your services past fi rewalls that block the necessary ports

Bypass over-restrictive content fi ltering by tunnelling your browsing via your server, protecting your unencrypted web traffi c from insecure networks, too

Monitor your servers from outside the network without running the corporate VPN client – connect on the fl y from any device for out-of- hours monitoring

Need to chat to coders or your offi ce on Jabber when the client site’s fi rewall blocks the XMPP port? Tunnel it over an open port and simply connect your chat client to localhost:8080, for example

If you’re still using SSH as just a telnet replacement, you are missing out on borrowing

its secure encryption to carry many other network services through insecure Wi-Fi, and overly restrictive fi rewalls, from wherever you have a laptop or smartphone.

For the bulk of this article, we shall be looking at local port forwarding – the most common and the most useful type – to give secure, VPN-like connections. Why not just use a virtual private network? VPNs aren’t always available to you, and some corporate VPNs demand particular client software and confi guration, but SSH

tunnels can always be created on the fl y, as and when you need them.

Perhaps you have never read the SSH man page? No? Well, the options you should have been looking at are -L and -R, with a little attention to -N and -f.

Skipping lots of theory, we’ll take a practical approach and show you how to use SSH tunnelling in various common scenarios. Read on and fi nd just what these magic switches to the ssh command can do for you, but beware – the power to run rings around fi rewalls should be used carefully!

Resources

SSH client

with SSH daemon on the server

A server

connected to the internet, preferably with a fi xed IP address

01

A different port

When you run a normal SSH session, it simply opens an encrypted connection from a spare port on your computer to port 22 on a remote device. For security reasons – many scripts are knocking on port 22 with well-known passwords – you can specify another port.

02

Insecure access

However, inside this encrypted connection you can carry other traffi c – hence SSH tunnelling. This means that however insecure your connection (eg cafe Wi-Fi), your traffi c is as secure as the level of encryption used by SSH (ie good enough).

03

Confi dential mail

Tunnelling allows you to hide your unencrypted email traffi c inside the SSH connection. The -L local-port:host:remote-port creates the tunnel, allowing SMTP (port 25) traffi c from the mail-server to appear on (for example) port 3909 locally.

04

Local confi g

Now just confi gure your email client to connect to port 3909 of the local machine. Localhost and 127.0.0.1 are synonymous, but you

05

Pick a number

Why port 3909? Port numbers below 1024 are for privileged services. No non-root users should be looking higher than this, but taking a peek at the popular ports in use by other software. Pick a free number such as 6555 or 3989 as your default.

08

Security basics

As well as security settings like a port other than 22, and not allowing root login, here you should uncomment the protocol version 2 setting, so only the more secure protocol version 2 will be used. If both are listed, delete the ‘1’.

09

Error check

Check you can log in on the new port from another terminal before you close this session! If there is a problem, check that you restarted the SSH server, and typed the correct port and username. If in doubt, return to default port setting.

06

Two-lane tunnel

While outward-bound SMTP is occasionally blocked, if you’re tunnelling for security, best do the incoming POP mail with the same command. As you can see, multiple local tunnels can be expressed in the same ssh command, each with the -L switch.

could also use the fully qualifi ed domain name (FQDN) of your local machine. You can do the

same for receiving mail via POP.

07

On the server

Before we go any further, best get a couple of things straight on our server. SSH in (without the tunnel this time), gain root privileges, and fi re up your favourite editor to open /etc/ssh/sshd_confi g (or whatever your distro names the fi le).

11

Keeping track

Confi gs for local and reverse tunnels can also be added at the client end too – handy for keeping track of multiple connections over multiple ports, as well as enabling easier connections from shell scripts. RemoteForward = reverse tunnel.

12

Switching on

Did you notice those extra switches earlier? -f will put SSH in the background before executing a command; -N stops the execution of remote commands; -i allows you to specify a fi le for private key, for passwordless connection – other than the standard fi le locations in ~/.ssh/

16

Invisible server

Surprisingly, you may need to tunnel SSH itself through SSH. For example, where the machine we need to reach is invisible to the

14

Unfi ltering content

Similarly, you may fi nd access to a security-related site blocked by overzealous content fi ltering, and need to tunnel browsing through a machine outside the fi lter: this time we need to set up a different sort of tunnel, a SOCKS proxy.

10

Keep yourself alive

While you can add ServerAliveInterval 60 to your ~/.ssh/confi g fi le, adding KeepAlive on the server will work when you connect from other devices or PCs – the ClientAlive directives will keep you connected during inactive periods, which is useful for reverse tunnels.

13

Through the fi rewall

There’s much more to SSH tunnelling than keeping your emails from prying eyes. If you’re on site and the client company’s fi rewall is blocking ports you need, such as Jabber, set up the tunnel and confi gure your client to use the appropriate port on localhost.

15

Sock it to me!

ssh -C -D 1080 -p 443 root@ myserver.com

-D is for dynamic port forwarding, creating

a SOCKS proxy, over which many services can be carried at once. However, the client applications (such as Firefox), need to be capable of using SOCKS, and need to be confi gured in the application’s preferences.

1080 is the default port for SOCKS. Others may

be tried, but won’t work with all software. Get your server to listen on port 443, instead of the non-standard ports we suggested earlier, and you’ll fi nd your way unblocked as most fi rewalls allow 443 for https://.

-C turns on compression, which speeds up

non-binary (ie text) downloading.