|
To surf or not to surf - that is the question pondered by many employees
before using the company Internet connection to check their stocks or
follow the breaking news on the Net. And while many companies do not have
a "no surfing" policy, it is reasonable to suspect that the security
administrator is keeping an eye on the firewall logs; after all, that is
his job, right?
The debate over the ethics of using an employer's system to surf the Net is ongoing. Employee privacy rights
and whether or not the company owns the contents of employees' machines are just two facets of it. The
opportunity for system administrators to view personal information disclosed through Web surfing may also
pose serious security concerns, as many ill-designed Web interfaces embed the usernames and passwords in the
URL string. Concealing the URL of a visited site from prying eyes makes a lot of sense. In such cases, the
need for anonymous web access may well be justified.
Two Solutions: Web Anonymizers and Web Proxy Cache
So, how can this be accomplished? There are a number of anonymizing web proxies available
online; however, these may not be the best option. The number of such services offered for free has decreased
during the last year, likely due to dot-com bust (in a list of anonymizing Web proxies compiled by Electronic Frontiers Georgia only one link is still operational.) The most famous of
them, The Anonymizer, still offers free service, but
it does not conceal URLs - only the paid service offers this feature. Furthermore, using a known anonymizing
service may attract the attention of systems administrators, in which case such sites would be blocked.
Another prohibitive issue is trust. Why should one trust the owners of a web anonymizer service? After all,
what is to stop them from disclosing the access logs - either deliberately or inadvertently due to bugs in
the software.
While anonymizing solutions offered on the Internet may not provide
adequate anonymity, a Web proxy cache will. Squid is a full-featured Web proxy
cache designed to run on Unix systems. The software allows proxying and
caching of HTTP, FTP protocols, extensive access controls, HTTP server
acceleration, caching of DNS lookups and has many other features. Squid is
distributed under free open source license. It has been chosen for this
setup due to its popularity, quality of existing documentation and
availability on most Linux distributions. It should be noted, that squid
by itself is not an anonymizer and will provide no additional security to
Web surfing.
Squid proxy serves two useful functions: it redirects Web page requests to
the Web server that the user wants to visit (called proxying) and it
speeds up Web browsing by storing the frequently-visited pages (the
caching function.) At the same time, it uses SSH port forwarding to enable
encryption of all traffic between the web surfer and the proxy so that
both web contents and requested URLs are encrypted with a SSH-supported
encryption algorithm (such as DES, 3DES, IDEA, Blowfish for SSH1 and 3DES,
Blowfish, Twofish, CA ST128 and RC4 for SSH2.) The only unencrypted
communication will be performed on the local host interface, thus no plain
text traffic will ever leave the office machine where the browser is used.
On the client side, this method will be supported by the regular Web
browser and the SSH client software (available for free for both Linux and
Windows.)
Setting Up a Squid Web Proxy Cache
Let's proceed with the set-up, which will entail setting up a Linux
system running Web proxy (Squid) and secure shell server (SSH) on a fast
Internet connection outside of present location. A secure shell port
forwarding feature is used to tunnel requests from the local Web browser
to a remote Squid proxy in an encrypted fashion. Any Web browser for
Windows or UNIX/Linux can then be utilized for secure Web access.
A certain degree of familiarity with Linux setup is assumed in the current document. Only one computer
running Linux is required. Any version of UNIX will do, but the instructions that follow will apply to Linux.
It is assumed that a fresh install of RedHat 7.1 is available. The specific Linux distribution and version
are not important for the setup: RedHat Linux has been chosen as an example due to its popularity. The
machine should be connected to the Internet through a high-speed connection such as cable or DSL.
Technically, this is not required: a regular dial-up connection can be used, but the performance of our
anonymizer proxy will suffer.
If the surfing is to be done from office, then the Linux machine should be installed at home location or
elsewhere. RedHat offers three modes of installation: Server, Workstation and Custom. As the machine will be
able to be used for purposes other than Web proxying, the most likely installation mode will be
Workstation, which is also the best install option for the general purpose machine that will also be used for
proxying. (This machine will also be called a server later in this paper, since it will work as a server for
the connecting browser clients.)
As was mentioned, two pieces of software need to be installed on the
server for the anonymizer to work: Squid Web Proxy
Cache and Secure Shell Server by OpenSSH.
Secure Shell server for UNIX by SSH Communication Security can also be
used. Both Squid and OpenSSH server are included on the RedHat CDs, but
are not installed by default on Workstation version of the set-up. Since
RedHat Linux uses RPM (RedHat Package Manager) system, the installation of
new software is extremely easy. One can use any of the RPM GUIs such as
kpackage or GnoRPM or a good old "rpm -U" command. RedHat 7.1 includes
Squid v. 2.3 and OpenSSH v. 2.5.2.
To install Squid Proxy Cache using command-line RPM, go to the RedHat CD and
then to the RPM directory and run the command:
rpm -U squid-2.3.STABLE4-10.i386.rpm
If no error messages appear, that means that Squid has been installed
successfully. If a message reading "the package is already installed"
shows up, then no further action is needed.
To install Secure Shell go to the same directory and run:
rpm -U openssh-server*rpm
That installs the Secure Shell server package. SSH client has already been
installed during RedHat installation.
A default configuration of Secure Shell server will be used. No changes to
config files (located in /etc/ssh) are required.
Squid also will use default configuration (usually in /etc/squid
directory). While some performance tuning might be a good idea, it is not
required for the current setup.
Access Control and Security
The next important issue is access control and security. The access to
Squid Proxy should be limited. It is recommended that all other
network-visible services be removed from the machine. RedHat workstation
configuration does
not install any server daemons, so the out-of-the-box configuration is
fine. It is highly recommended that the newly-installed RedHat box is
portscanned with nmap or some other scanner to
confirm that only Squid (default port 3128) and SSH server (port 22) are
visible. Other services that might be installed by default are sendmail
(port 25), X11 (port 6000) and bind (port 53). Those should be kept only
if needed.
SSH access control can be set using TCP wrappers config files
/etc/hosts.allow
and /etc/hosts.deny. Access to the proxy machine should only be permitted
from the browsing machine or network. Edit /etc/hosts.deny to have a
single line
ALL:ALL and make sure that /etc/hosts.allow contains a single
line similar to the line below:
sshd: .good.network.com my.box.at.work.com
Squid access control only allows connection from the localhost. One might
think that this is exactly what is needed, since the only machine
connecting to Squid program will be the same Linux box; however, this is
deceptive. Localhost is mapped to only 127.0.0.1 IP address and the
requests will come from the real IP address of the local machine (assigned
by the ISP). Thus Squid access controls (implemented as a set of Access
Control Lists - ACLs - in /etc/squid/squid.conf) will have to be relaxed.
Go to /etc/squid/squid.conf
and add a line:
acl localweb src YOUR.HOME.IP.ADDRESS/255.255.255.255
to the part of the file where other ACLs are located, replacing the
YOUR.HOME.IP.ADDRESS with the actual IP address. The line above creates a
new
ACL with a single IP of the home machine. Then add a line to actually
allow
access from the machine listed in the above ACL:
http_access allow localweb
just above the lines:
http_access allow localhost
http_access deny all
Now let's discuss client setup. Most likely, one would want to use Windows
9x/Me/2000 in the office. Users will need to download a Secure Shell
client
that supports port forwarding. The best choice is the SSH client from SSH
Communication Security. The software comes as a standard Windows
installation package and is free for personal use (that is what we have in
mind, in this setup anyway.) Install the software according to
instructions on
the package. By now, the IP address or the hostname of the home Linux
server machine should be known. Check the "ifconfig" command from Linux
cmacnhien command prompt to learn the IP address.
Now let's deal with the Windows SSH client:
1. Start up SSH client and establish a connection to a server using the IP
address learned above and any account you created on your Linux machine
2. Go to Edit -> Settings-> Profile Settings-> Tunneling
3. Setup Outgoing tunnel for port 3128, choose local port 3128 as well
4. Restart the connection to a remote Linux server for tunnel to be
initiated
For UNIX client the following command will do the trick:
1. ssh -L 3128:squid.linux.server.com:3128 username@squid.linux.server.com
That also assumes that a valid account was created on the Linux server to
be
used with port forwarding.
Authentication
Now let's address the authentication issue. The above set-up for a secure shell client will prompt for a
password every time before establishing a tunnel. Users can use public key cryptography to authenticate with
a secure shell server. To make use of the public key authentication, user should create a key pair for
authentication. The public key is then uploaded to the SSH server and private key is kept on the user client
machine. To this setup, read one of the many guides available (such as http://mah.everybody.org/docs/ssh for Linux.) Note that some Windows
SSH clients can have problems with public key authentication with OpenSSH version of Secure Shell. Now, the
user can start using the automatic connection to the SSH server for remote access and port forwarding.
After the Secure Shell set-up is completed, the rest is simple. Depending upon the browser type, the user
will need to enter location of proxy server. Keep in mind that due to port forwarding our Web proxy for the
browser is 'localhost' and NOT the remote machine. This is due to the fact that the connection to the
specified port on the local machine will be forewarded to the Squid Linux machine.
For IE 4.x and 5.x go to Tool->Internet Options -> Connections->LAN
Settings,
then check the box for "Use a proxy server" and enter "localhost" and port
3128 into the corresponding forms.
For Netscape Navigator 4.x go to Edit->Prefernece->Advanced->Proxies->Manual Proxy Configuration and enter
"localhost" or 127.0.0.1 in the provided field.
Now, test the setup by going to a Web site. All the connections to the Web
should be encrypted. If the browser hangs and does not connect, make sure
that SSH client is running and connected to the Linux server. Now, what if
the company does not allow outbound connections to port 22? It might mean
that the user is not supposed to use SSH for remote access from company
premises and that he or she should clarify the issue with whoever is
responsible for security policy.
What are the limitations of such a setup? First, it's necessary that the ISP that hosts the home machine
allow Secure Shell connections from remote location. Some cable ISPs such as AT&T Broadband allow connections
to SSH, but not to port 80 (so that people don't run web servers on their home machines and to protect from
CodeRed-like IIS worms.) Other companies can be more or less restrictive. Second, since the Web pages
requests will go unencrypted from Squid to the Web server, the user should be sure that the ISP allows access
to the web servers being accessed and that there are no issues with ISP knowing what sites are visited (the
ISP will always know that). Third, some of the pages with dynamic content and slightly broken HTML can
confuse squid into displaying not the newest version of the web page, but some locally stored version. This
can be solved by tweaking the Squid configuration files. Check the Squid documentation for more details.
Other Solutions to the Anonymity Problem
Readers should note that there are a couple of other possible ways to achieve
anonymity in Web surfing. First, one can use a special SSL wrapper (such
as Stunnel from
Stunnel.org) with the proper SSL encryption library to achieve the same
result. However, the solution discussed in this article was intended to
involve only commonly-used software (which Stunnel isn't) that can already
be installed on the typical office machine. Second, if the home machine
has Linux IPSec code (such as FreeSWAN from
Freeswan.org) compiled into the kernel, one can use IPSec tunneling to
secure the proxy connection. In this case, the user will use something
like free PGPnet client from www.pgp.com.
However, RedHat kernel does not have IPSec included (some other less
well-known Linux distributions such as Connectiva or Polish(ed) Linux do)
and thus the setup will involve kernel recompilation.
Conclusions
This article has offered a brief overview of how users can configure a simple but secure Web anonymizer using
only commonly-used free software. Now Web surfing should be safe from the prying eyes on the local LAN.
Readers should be reminded that the use of such set-ups may be prohibited in their workplace. Please, use
the proposed setup responsibly without violating your company's ethical guidelines or security policy.
Anton Chuvakin,
Ph.D. is in the process of looking for another infosec job after having his fun summer dot-bomb
experience. Running Linux at home is one of his hobbies.
|