File: README.4.3.beta2

package info (click to toggle)
socks4-server 4.3.beta2-20
  • links: PTS
  • area: main
  • in suites: buster, stretch
  • size: 1,512 kB
  • ctags: 1,778
  • sloc: ansic: 19,305; makefile: 399; sh: 52
file content (284 lines) | stat: -rw-r--r-- 11,544 bytes parent folder | download | duplicates (9)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
With 4.3, implementing 4A extension to the SOCKS 4 protocol,
clients are no longer required to be able to resolve all
internal and external domain names. They may rely on the SOCKS
server to resolve names that they do not know. All 4.3 clients
can still work with previous 4.x servers except when they expect
the server to do name resolution for them, which is only available
on 4.3 servers.

With domain names now allowed in the configuration files for both the
SOCKS server and the clients, it is much simpler to set up the
configuration files. Most sites should find themselves needing nothing
more elaborate than the two-liners below (replacing my.domain with
your own domain name).

For sockd.conf:

deny  ALL 0.0.0.0  .my.domain 0.0.0.0
permit  .my.domain 0.0.0.0  ALL 0.0.0.0


For socks.conf:

direct  .my.domain 0.0.0.0
sockd  ALL 0.0.0.0


4.3 servers work with all 4.x clients unless you build the server
with NO_RBIND defined. The NO_RBIND servers does not support the
facility of allowing incoming secondary connections such as those
used in the normal mode of ftp. ftp (rftp) using PASSIVE mode works
fine with NO_RBIND servers. No route file (/etc/sockd.route) is
needed for NO_RBIND servers, even if they are multi-homed.

Please see below for the procedure for building and testing. Since
the configuration files now accept domain names which existing
applications do not yet understand, a good way to ease the transition
is to use a non-standard name for the new configuration (e.g.,
/etc/socks.conf.new) and produce a frozen configurations from it using
'make_socksfc /etc/socks.conf.new'. New applications can use the
frozen configuration while existing ones can use the old
configuration.

The use of domain names in configuration files can greatly simplify
their setup. On the other hand, it will also make SOCKS's actions
depend heavily on your DNS (Domain Name System) setup. Be sure to
read the man page on sockd.conf very carefully and consider how well
you maaintain your DNS data if you want to use domain names in your
configuration files.

To join the SOCKS mailing list, please send an email subscription request
to majordomo@syl.dl.nec.com with

	subscribe socks your@email.address

in the body of the message.


	Ying-Da Lee	yingda@best.com  or yingda@esd.sgi.com
	http://www.best.com/~yingda/

-------------------
Please see the file CHANGES for things that are different from previous
versions. I have incorporated patches and suggestions from many people,
these are the ones that I have the records for:

SAKAI Kiyotaka <ksakai@netwk.ntt-at.co.jp>
Ted E. Keller <keller@bfg.com>
Ian Dunkin <imd1707@ggr.co.uk>
"Joe Rhett" <joe@navigist.com>
rubenb@strat.jany.gs.com (W. Bradley Rubenstein)
Laurent Julliard <Laurent.Julliard@Grenoble.RXRC.Xerox.com>
larry.jones@sdrc.com (Larry Jones)
Mark Powell <medp@primag.co.uk>
Chuck Murcko <chuck@telebase.com>
hal@netmarket.com (Hal Pomeranz)
Damjan Lango <Damjan.Lango@snet.fer.uni-lj.si>
ken_simpson@tmai.com (Kenneth Simpson)
Russell Fulton <r.fulton@auckland.ac.nz>
john@oaty.com (John Grant)
Stanley Hu <hu@valisys.com>
Chee-Wai Yeung <cheewai@cs.ust.hk>

I am almost certain though that I lost a batch of mail messages
when I changed my job. So please remind me so I don't let your
contribution go unacknowledged. 

====================================================================

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 may want to use 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 STAND_ALONE_SERVER 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. Similarly, use 'make MKFC' from the top directory to
   build the programs that produce and show the contents of frozen
   configuration files.

   If you are using gcc and it is having major fits with rtelnet,
   add -traditional flag and try it again.

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 file. Two lines in this file should
   suffice for most sites:
deny  ALL  0.0.0.0    .xyz.com  0.0.0.0
permit  .xyz.com  0.0.0.0    ALL  0.0.0.0
   Use your own domain in place of xyz.com in the lines above;
   note the leading period before the domain name.
   You may want to use the program make_sockdfc to produce
   a frozen configuration after you have a stable setup for
   your configuration. Frozen configuration can reduce the server's
   startup time. Be sure to read the man page on sockd.conf
   very carefully!

5. If the server host is multi-homed and your server supports
   RBIND (i.e., you built sockd with the macro MULTIHOMED_SERVER
   in include/socks.h defined and NO_RBIND in the top Makefile
   undefined), 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 STAND_ALONE_SERVER 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
   STAND_ALONE_SERVER 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.

8. If you are going to use a SOCKSified SOCKS server, please read
   the man page on rsockd.

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

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 configuration file. This should normally be /etc/socks.conf.
   However, if you have existing SOCKS clients and you want to use
   domain names in the configuration, which the existing applications
   do not understand, it's better to call it /etc/socks.conf.new and
   use the command
make_socksfc /etc/socks.conf.new
   to produce frozen configuration for new SOCKS clients while the
   existing ones continue to use the old configuration. For most sites,
   two lines should suffice:
direct .xyz.com 0.0.0.0
sockd  ALL 0.0.0.0
   Use your domain name in place of xyz.com in the first line; note
   the period before the domain anme.

   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