7.6 Using SOCKS for Proxying

The SOCKS package, originally written by David Koblas and Michelle Koblas, and currently maintained by Ying-Da Lee, is an example of the type of proxy system that requires custom clients. SOCKS is freely available, and it has become the de facto standard proxying package on the Internet. The package is on track to become an official Internet standard: a Request For Comments (RFC) has been written and is currently undergoing the approval process. Appendix B, Tools tells you how to get SOCKS.

In order to make it easy to support new clients, SOCKS is extremely generic. This is part of what makes it so popular, but it has the disadvantage that SOCKS can't provide intelligent logging or access control. It provides logging, but most of the logging is done on the client, making it difficult to collect the information in a single place for examination. SOCKS does log connection requests on the server; provides access control by source, and destination host and protocol; and allows configurable responses to access denials. For example, it can be configured to notify an administrator of incoming access attempts and to let users know why their outgoing access attempts were denied.

One drawback of SOCKS is that it works only for TCP-based clients; it doesn't work for UDP-based clients (like Archie clients, for example). If you are using a UDP-based client, you may want to get another package, the UDP Packet Relayer. This program serves much the same function for UDP-based clients as SOCKS serves for TCP-based clients. Like SOCKS, the UDP Packet Relayer is freely available on the Internet.

The prime advantage of SOCKS is its popularity. Because SOCKS is widely used, server implementations and SOCKS-ified clients (i.e., versions of programs like FTP and Telnet that have already been converted to use SOCKS) are commonly available, and help is easy to find. This can be a double-edged sword; cases have been reported where intruders to firewalled sites have installed their own SOCKS-knowledgeable clients.

The SOCKS package includes the following components:

• The SOCKS server. This server must run on a UNIX system, although it has been ported to many different variants of UNIX.

• The SOCKS client library for UNIX machines.

• SOCKS-ified versions of several standard UNIX client programs such as FTP and Telnet.

In addition, client libraries for Macintosh and Windows systems are available as separate packages.

Figure 7.3 shows the use of SOCKS for proxying.

Figure 7.3: Using SOCKS for proxying

Many Internet client programs (both commercial and freely available) already have SOCKS support built in to them as a compile-time or a run-time option.

How do you convert a client program to use SOCKS? You need to modify the program so it talks to the SOCKS server, rather than trying to talk to the real world directly. You do this by recompiling the program with the SOCKS library.

Converting a client program to use SOCKS is usually pretty easy. The SOCKS package makes certain assumptions about how client programs work, and most client programs already follow these assumptions. For a complete summary of these assumptions, see the file in the SOCKS release called What_SOCKS_expects.

To convert a client program, you must replace all calls to standard network functions with calls to the SOCKS versions of those functions. Here are the calls:

Standard Network Function	SOCKS Version
connect()	Rconnect()
getsockname()	Rgetsockname()
bind()	Rbind()
accept()	Raccept()
listen()	Rlisten()
select()	Rselect()

You can usually do this simply by adding the following to the "CFLAGS=" line of the program's Makefile.

-Dconnect=Rconnect 
     -Dgetsockname=Rgetsockname 
     -Dbind=Rbind 
     -Daccept=Raccept 
     -Dlisten=Rlisten 
     -Dselect=Rselect 

Then, recompile and link the program with the SOCKS client library.

The client machine needs to have not only the SOCKS-modified clients, but also something to tell it what SOCKS server to contact for what services (on UNIX machines, the /etc/socks.conf file). In addition, if you want to control access by user, the client machines must be running identd, which will allow the SOCKS server to identify what user is controlling the port that the connection comes from. Because there's no way for the SOCKS server to verify that the identd server is reliable, identd can't be trusted if there is anybody who might intentionally be circumventing it.