readme.4.2

Linux下的socks的程序源程序,用于socks的代理服务

This is CSTC version 4.2 of SOCKS, a package that allows Unix hosts
behind a firewall to gain full access to the internet without requiring
direct IP reachability. It does require a SOCKS server program being
run on a hosts that can communicate directly to hosts behind the firewall
as well as hosts on the Internet at large.  It is based on the original
SOCKS written by David Koblas <[e-mail]>.

The package includes full source for the SOCKS server and SOCKSified
client programs of finger, ftp, telnet, and whois. A few other SOCKSified
clients may be found on ftp.nec.com, in directory /pub/security/socks.cstc.
Increasingly, software developers are beginning to include SOCKS support
directly into their products, for example, Mosaic, Netscape, Trumpet
Winsock, TCP/Connect II (from InterCon for Macintosh; they also intend
to do so for their Windows version), OutsideVew for Windows (from Crystal
Point, currently in beta).

Besides various minor bug fixes and improvements, the major differences
between this release and 4.1 are:

1) Can handle nonblocking connect() calls, or at least the way such calls
   are used in Mosaic.

2) SOCKSification of application programs is simplified. No code modification
   is necessary, just recompile with appropriate directives (see the file
   How_to_SOCKSify).

3) Option to build stand-alone sockd. This is especially beneficial for
   sites that have to use a big sockd.conf file.

This version is known to work on the following Unix platforms:

SunOS 4.1.3
Irix 4.0.5H, 5
Ultrix 4.3
HP-UX 9.05
AIX 3.2.5
Interactive 4.1
DEC OSF/1 AXP 3.0
Solaris 2.3, 2.4
Linux 1.1.18
SCO/ODT 2.x
DG/UX 5.4.3
FreeBSD 1.1.5.1

Though I have not received final confirmation, it is likely that
the package may also work on the following platforms:

NetBSD 0.9
UnixWare
BSDi 1.0
PS/2 AIX 1.2.1
NextStep 3.2 (server and library only)

-------------------
All 4.2 clients work with all 4.x servers. 4.0 clients work
with single-homed 4.2 servers but NOT with 4.2 multi-homed servers.
4.1 clients work with 4.2 servers, both single- and multi-homed.
'sockd -ver' tells you not only the version number but also whether
it is single- or multi-homed.

Please see below for the procedure for building and testing.
Remember that the names of the control files are all configurable
in include/socks.h. It will probably greatly reduce your frustration
while you are flipping between the old and the new versions if you
uses different file names for the new version. 

There is now a mailing list devoted to issues related
to SOCKS. To join the list, please send an email subscription request
to [e-mail] with

	subscribe socks [e-mail]

in the body of the message.

Finally, I want to thanks all the people who have helped in making
and shaping this release. These are the ones that I remember:

Jason Baietto, Brad Beach, David Blob, John Brezak, Dave Brower,
Brian M. Clapper, Matt Cohen, Adrian Colley, Bryan Curnutt, Ian Dunkin,
Steve Danz, Thomas Essebier, Andrew Fullford, Matthew R. Ganis,
Phil Hochstetler, LaMont Jones, Larry Jones, Cornell Kinderknecht,
Edwin Kremer, William Lewis, Rob Liebschutz, Jon Luini, Stephen Ma,
Andy McFadden, Alain Mellan, Craig Metz, David Mischel, Heinz Naef,
David Nochlin, Garry M. Paxinos, Hal Pomeranz, Chris Riney,
Andreas Siegert, John Scott, Fred Stephens, Shin'ichiro Tanaka,
Mike Tollerton, Satoshi Toyosawa, Paul van Deurzen, Syd Weinstein

My sincere apologies to those that I forget to mention -- please
remind me!

Without in any way diminishing the contributions of others in the
list, I would like to pay special tribute to David Mischel for his
code for the stand-alone sockd, and to Bryan Curnutt for porting to
and testing the package on 9 (!) platforms.

	Ying-Da Lee	[phone]	[phone] (FAX)
	Principal Member, Technical Staff
	NEC Systems Laboratory, C&C Software Technology Center /
	NEC USA, Corporate Network Administration Division
	[e-mail]
====================================================================

Please read the file 'COPYRIGHTS' before you proceed further.

In the following section, by 'top directory' we mean the top
directory of the SOCKS package, i.e., the directory you are
in right now.

-------------------------------------------------------------

HOW TO BUILD THE PROGRAMS

1. Check and modify the following files to suit your systems:

	Makefile
	include/socks.h

   Be sure that the macro 'SOCKS_DEFAULT_SERVER' in include/socks.h
   is set correctly to the host that will be running the proxy server
   for your site.  Although this can be overridden at run time with
   environment variable SOCKS_SERVER, it is a lot simpler if you put
   in the right name at compile time. Also be sure to uncomment and set
   the macro 'SOCKS_DEFAULT_NS' in the same file if your client machines
   normally can't do DNS resolution for outside hosts.

   Be sure that the macros 'ORIG_FINGER' and 'MULTIHOMED_SERVER' in
   include/socks.h are set correctly.

   If you need a large configuartion file with many rules for access
   control (I have heard of sites with up to 2,000 lines in sockd.conf!),
   you should try using a stand-alone SOCKS server, i.e., one that runs
   without the control of inetd. To build a stand-alone SOCKS server,
   you must define the macro NOT_THROUGH_INETD in include/socks.h.

   In most cases, you should have no needs to modify the Makefiles
   in the subdirectories. But if you run into problems, you may
   have to look into modifying

	sockd/Makefile
	libident/Makefile
	lib/Makefile
	rfinger/Makefile
	rftp/Makefile
	rtelnet/Makefile

   If your system is not among those included in the top Makefile,
   then you may also have to construct an entry for your system
   in the file rtelnet/Config.local.

2. cd to the top directory and issue 'make' command.  It's a good
   idea to direct stdout and stderr to a file so that you can
   see what's being done afterwards. There will be a few warning
   messages which you can ignore. This builds the server as well
   as all the clients.

   If you only want to build the server, use command 'make server'
   instead.  Use command 'make clients' to build only the client
   programs. You can also build the individual clients using
   'make RFINGER', 'make RFTP', and 'make RTELNET', all from the
   top directory.

3. All the man pages (except for libident) are in directory doc.
   You are encouraged to print them out and read them before proceeding
   to the next part.

-------------------------------------------------------------

HOW TO INSTALL THE SERVER

1. Become superuser on the proxy server host for your site. 

2. cd to the top directory and issue 'make install.server'.
   This installs sockd and its man page.

3. Add the line
socks	1080/tcp
   to file /etc/services. It would be nice also to include
gopher	70/tcp
WWW	80/tcp
   in the file if you don't already have them.

4. Set up access control with file /etc/sockd.conf. You have to
   read the man pages for sockd and sockd.conf for the details.
   For a quick test, you can use these four lines in the file: (Replace
   'client_IP' with the IP address of the host on which you will be
   testing the client programs.)
permit	client_IP   255.255.255.255
# One LONG line follows:
deny	0.0.0.0 0.0.0.0 : /usr/ucb/finger @%A | /usr/ucb/mail -s 'SOCKD: rejected -- from %u@%A to host %Z (service %S)' root
# Another LONG line:
#BAD_ID: /usr/ucb/finger @%A | /usr/ucb/mail -s '%U pretends to be %u on host %A' root@%A root
# Last line:
#NO_IDENTD: /usr/ucb/mail -s 'Please run identd on %A' %u@%A root@%A
   This is essentially the contents of file sockd/sockd.conf.sample.

5. If the server host is multi-homed and you built sockd with the
   macro MULTIHOMED_SERVER in include/socks.h defined, you must
   also supply the file /etc/sockd.route. For a typical dual-homed
   server, this can simply be a one-liner:
out_interface	0.0.0.0 0.0.0.0
   where out_interface is the IP address of the server's network
   interface leading to the outside world. The format for lines
   in this file should be
# comments
Interface_addr	dst_addr dst_mask

   Read the man page on sockd.route !!!

6a. For sockd that is to be controlled through inetd (i.e.,
   you made the server with NOT_THROUGH_INETD in include/socks.h
   undefined):
   Add the line
socks	stream	tcp	nowait	nobody	/usr/etc/sockd	sockd
   to file /etc/inetd.conf. Use the actual path where sockd
   is installed if not in /usr/etc. If you want to make use of
   identd on your client machines when it is available, use
socks	stream	tcp	nowait	nobody	/usr/etc/sockd	sockd -i
   If you want to REQUIRE identd be run on your client machines,
   use
socks	stream	tcp	nowait	nobody	/usr/etc/sockd	sockd -I
   Running sockd with -I will reject all requests from hosts that
   do not run identd.
   Send a SIGHUP signal to the running inetd process so that it will
   use the new configuration.

6b. For stand-alone sockd (i.e., you made the server with
   NOT_THROUGH_INETD in include/socks.h defined):
   Just invoke the sockd program, e.g., /usr/etc/sockd. Use the
   actual path where sockd is installed if not in /usr/etc. If you
   want to make use of identd on your client machine when it is
   available, use the -i option. If you want to REQUIRE identd be
   run on your client machines, use the -I option.

7. You may have to do some other things to accommodate syslog. Read
   the man pages on syslogd and syslog.conf.

-------------------------------------------------------------

HOW TO TEST THE CLIENT PROGRAMS

   NOTE: Build and install identd on your client hosts first. This is
   required if you run sockd with -I option. It is a good idea anyway.

   Set up the file /etc/socks.conf on the client host. Lines in this
   file should be of the form
# comments
deny [*=userlist] dst_addr dst_mask [op port]
direct [*=userlist] dst_addr dst_mask [op port]
sockd [@=serverlist] [*=userlist] dst_addr dst_mask [op port]
   Fields in square brackets are optional. The optional @=serverlist
   field with a 'sockd' line specifies the list of SOCKS servers
   the client should try (in the given order) instead of the default
   SOCKS server.  If the @=serverlist part is omitted, then the default
   SOCKS server is used. Commas are used in the userlist and serverlist
   as separators, no white spaces are allowed.

   Read the man page on socks.conf !!!

   On a client host (for testing purpose, this can be the same as
   the proxy server), the clients rfinger, rwhois, rftp, and rtelnet,
   can be tried out without any additional setup on the
   client host once the server is running. They should behave like
   finger, whois, ftp, and telnet, respectively. rftp DOES
   echo your password IF you are using 'anonymous' as the log-in name.

   Quite a lot of details of operations of both the clients and the
   server are logged. Checking the contents of the log files may be
   helpful when you run into problems. You should try using these
   clients to connect to both inside and outside hosts and check the
   log messages to see whether the correct ways are used.

-------------------------------------------------------------

HOW TO INSTALL CLIENT PROGRAMS

1. Become superuser on the client host.

2. cd to the top directory, then issue the command 'make install.clients'.
   This installs rfinger, rwhois, rftp, rtelnet, and
   their man pages.

3. Rename your regular 'finger', 'whois', 'ftp', and 'telnet'
   to something else. The new name for the 'finger' program
   must be EXACTLY what you used for defining the macro ORIG_FINGER in
   include/socks.h. Then either rename the SOCKS clients or use symbolic
   links for them. For example, if you have installed the clients in
   directory /usr/local/bin and your regular 'finger', 'whois', 'ftp',
   and 'telnet' were in /usr/ucb, then you should do
ln -s /usr/local/bin/rfinger /usr/ucb/finger
ln -s /usr/local/bin/rftp /usr/ucb/ftp
ln -s /usr/local/bin/rhwois /usr/ucb/whois
ln -s /usr/local/bin/rtelnet /usr/ucb/telnet