Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] نسخه متنی

Hack 92 SSH SOCKS 4 Proxy

Protect your web traffic using the basic VPN
functionality built into SSH itself.

In the search for the perfect way to
secure their wireless networks, many people overlook one of the most
useful features of SSH: the -D switch. This simple
little switch is buried within the SSH manpage, toward the bottom,
and is described next.

-D port

Specifies a local "dynamic"
application-level port forwarding. This works by allocating a socket
to listen to port on the local side, and whenever a connection is
made to this port, the connection is forwarded over the secure
channel, and the application protocol is then used to determine where
to connect to from the remote machine. Currently the SOCKS 4 protocol
is supported, and SSH will act as a SOCKS 4 server. Only root can
forward privileged ports. Dynamic port forwardings can also be
specified in the configuration file.

This turns out to be an insanely useful feature if you have software
that is capable of using a SOCKS 4 proxy. It effectively gives you an
instant encrypted proxy server to any machine that you can SSH to. It
does this without the need for further software, either on your
laptop or on the remote server.

Just as with SSH port forwarding [Hack #93], the
-D switch binds to the specified local port and
encrypts any traffic to that port, sends it down the tunnel, and
decrypts it on the other side. For example, to set up a SOCKS 4 proxy
from local port 8080 to remote from your
wireless laptop, type the following:

rob@caligula:~$ ssh -D 8080 remote

That's all there is to it. Now you simply specify
localhost:8080 as the SOCKS 4 proxy in your
application, and all connections made by that application will be
sent down the encrypted tunnel. For example, to set your SOCKS proxy
in Mozilla, go to Preferences
Advanced
Proxies, as shown in Figure 7-8.

Select Manual proxy configuration, then type in
localhost as the SOCKS host. Enter the port number that you passed to
the -D switch, and be sure to check the SOCKS 4
button.

Click OK, and you're finished.
All of the traffic that Mozilla generates is now encrypted, and
appears to originate from the remote machine that you logged into
with SSH. Anyone listening to your wireless traffic now sees a large
volume of encrypted SSH traffic, but your actual data is well
protected.

About DNS

One important point to keep in
mind is that SOCKS 4 has no native support for DNS traffic. This has
two important side effects to keep in mind when using it to secure
your wireless transmissions:

DNS lookups are still sent in the clear. This means that anyone
listening in can still see the names of sites that you browse to,
although the actual URLs and data are obscured. This is rarely a
security risk, but it is worth keeping in mind.

You are still using a local DNS server, but your traffic originates
from the remote end of the proxy. This can have interesting (and
undesirable) side effects when attempting to access private network
resources.

To illustrate the subtle problems that this can cause, consider a
typical corporate network with a web server called intranet.mybusiness.com. This web server uses
the private address 192.168.1.10, but is accessible from the Internet
through the use of a forwarding firewall. The DNS server for
intranet.mybusiness.com normally
responds with different IP addresses depending on where the request
comes from, perhaps using the views functionality in BIND 9. When
coming from the Internet, you would normally access intranet.mybusiness.com with the IP address
208.201.239.36, which is actually the IP address of the outside of
the corporate firewall.

Now suppose that you are using the SOCKS proxy example just shown,
and remote is actually a machine behind
the corporate firewall. Your local DNS server returns 208.201.239.36
as the IP address for intranet.mybusiness.com (since you are
looking up the name from outside the firewall). But the HTTP request
actually comes from remote, and attempts
to go to 208.201.239.36. Many times, this is forbidden by the
firewall rules, as internal users are supposed to access the intranet
by its internal IP address, 192.168.1.10. How can you work around
this DNS schizophrenia?

One simple method to avoid this trouble is to make use of a local
hosts file on your laptop. Add an entry like this to
/etc/hosts (or the equivalent on your operating
system):

192.168.1.10    intranet.mybusiness.com

Likewise, you can list any number of hosts that are only reachable
from the inside of your corporate firewall. When you attempt to
browse to one of those sites, the local hosts file is consulted
before DNS, so the private IP address is used. Since this request is
actually made from remote, it finds its
way to the internal server with no trouble. Likewise, responses
arrive back at the SOCKS proxy on remote,
are encrypted and forwarded over your SSH tunnel, and appear in your
browser as if they came in from the Internet.

SOCKS 5 support is planned for an upcoming version of SSH, which will
also make tunneled DNS resolution possible. This is particularly
exciting for OS X users, as there is support in the OS for SOCKS 5
proxies. Once SSH supports SOCKS 5, every native OS X application
will automatically be able to take advantage of encrypting SSH socks
proxies. In the meantime, we'll just have to settle
for encrypted HTTP proxies
[Hack #91].