 |  |
9.5. Using SOCKS for Proxying
The SOCKS package, originally written by David Koblas and Michelle Koblas, and subsequently maintained by Ying-Da Lee, is an example of the type of proxy system that can support both proxy-aware applications and proxy-aware clients. A reference implementation of SOCKS is freely available, and it has become the de facto standard proxying package on the Internet. It is also a proposed official Internet standard, documented in RFC 1928. Appendix B, "Tools", tells you how to get the freely available version of SOCKS; multiple commercial versions are also available.9.5.1. Versions of SOCKS
Two versions of the SOCKS protocol are currently in use, SOCKS4 and SOCKS5. The two protocols are not compatible, but most SOCKS5 servers will detect attempts to use SOCKS4 and handle them appropriately. The main additions in SOCKS5 are:
- User authentication
- UDP and ICMP
Hostname resolution at the SOCKS server
SOCKS4 works only for TCP-based clients; it doesn't work for UDP-based clients or ICMP functions like ping and traceroute. If you are using a UDP-based client, you will need to get another package. You can either use SOCKS5 or 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. SOCKS5 is the only widely used freely available proxy for ICMP.
SOCKS4 requires the client to be able to map hostnames to IP addresses. With SOCKS5, the client can provide the hostname instead of the IP address, and the socks server will do the hostname resolution. This is convenient for sites that do what is called "fake root" DNS, where internal hosts use a purely internal name server that does not communicate with the Internet. (This configuration is discussed further in Chapter 20, "Naming and Directory Services".)
9.5.2. SOCKS Features
In order to make it easy to support new clients, SOCKS is extremely generic. This limits the features that it can provide. SOCKS doesn't do any protocol-specific control or logging.SOCKS does log connection requests on the server; provide access control by user, by source host and port number, or by destination host and port number; and allow 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.
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.
9.5.3. SOCKS Components
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.
- SOCKS wrappers for ping and traceroute.
- The runsocks program to SOCKS-ify dynamically linked programs at runtime without recompiling.
Figure 9-4 shows the use of SOCKS for proxying.
Figure 9-4. Using SOCKS for proxying
9.5.4. Converting Clients to Use SOCKS
any Internet client programs (both commercial and freely available) already have SOCKS support built in to them as a compile-time or a runtime 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 including the file socks.h, included in the SOCKS distribution. If not, you can use the older method of adding the following to the CFLAGS= line of the program's Makefile:
-Dconnect=Rconnect
-Dgetsockname=Rgetsockname
-Dbind=Rbind
-Daccept=Raccept
-Dlisten=Rlisten
-Dselect=RselectThe 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 with Auth, the client machines must be running an Auth server (for instance, 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 Auth server is reliable, Auth can't be trusted if anybody might intentionally be circumventing it; we recommend using SOCKS5 with user authentication instead. See Chapter 21, "Authentication and Auditing Services", for more information about Auth.
|  | |
| 9.4. Proxying Without a Proxy Server |  | 9.6. Using the TIS Internet Firewall Toolkit for Proxying |
