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
|
.TH SOCKD 8 "June 6, 1996"
.SH NAME
sockd \- Internet firewall secure socket server (proxy server)
.SH SYNOPSIS
\fBsockd [ \-ver | \-i | \-I ]\fP
.SH DESCRIPTION
\fIsockd \fR is an internet secure socket server, often referred to
as a proxy server. It was designed
primarily to provide hosts within a firewall access to resources
outside of the firewall.
Normally, hosts inside a firewall has no IP-accessibility to the network
outside of the firewall. This reduces the risk of being intruded
by unauthorized people from the Internet. Unfortunately, without
IP-accessibility users on the inside hosts can no longer use many
of the important tools such as telnet, ftp, xgopher, Mosaic, etc. to
access the tremendous resources available in the Internet.
With \fIsockd\fR installed on a server host, users on the other
inside hosts can gain back the lost functionalities by using
clients programs designed to work with \fIsockd\fR proxy server,
e.g, \fIrtelnet\fR in place of \fItelnet\fR, \fIrftp\fR in place
of \fIftp\fR, \fIrfinger\fR in place of \fIfinger\fR,
etc. Since these client programs work
like their normal counterparts without requiring direct IP-connectivity
to the Internet, convenience to the users is accomplished without
breaching the security. The server host that runs \fIsockd\fR does
have to be open to the Internet, and it therefore requires special
attention to make sure that it is secure.
A configuration file \fB/etc/sockd.fc\fP (or \fB/etc/sockd.conf\fP) is
used to control access
to \fIsockd\fR and its services. Permission and denial of a service
request can be decided based on various combinations of the requesting
host, the destination host, the type of service (destination port number),
as well as the requesting user. (See \fIsockd.conf\fR(5) and
\fIsockd.fc\fR(5).)
If the server host is multi-homed, i.e., having more than one network
interface and with its IP_FORWARDING turned off, \fIand\fR the server
support RBIND operation, then it must run a multi-homed
version of \fIsockd\fP, which requires another control file
\fB/etc/sockd.fr\fP (or
\fB/etc/sockd.route\fP) to decide which interface to use for connection
to any given destination host. See \fIsockd.route\fP(5) and
\fIsockd.fr\fP(5). A multi-homed
sockd can be run on a single-homed host as well if necessary; you just
have to set up \fB/etc/sockd.route\fP to direct all traffic through
the host's one and only network interface.
\fIsockd\fR uses \fIsyslog\fR with facility \fBdaemon\fP and level
\fBnotice\fP to log its activities and errors. Typical lines look
like
.nf
.in +1
Apr 11 08:51:29 eon sockd[636]: connected -- Connect from don(don)@abc.edu to wxy.com (telnet)
Apr 11 09:24:59 eon sockd[636]: terminated -- Connect from don(don)@abc.edu to wxy.com (telnet)
Apr 11 09:24:59 eon sockd[636]: 1048 bytes from abc.edu, 285143 bytes from wxy.com
Jun 22 18:24:54 eon sockd[884]: refused -- Connect from sam(unknown)@big.com to small.com (ftp)
.in -1
.fi
In these lines, the first user-id is the one reported by the client program,
the second one (within the parentheses) is what is reported by \fIidentd\fP
on the client host.
These log lines usually appear in file \fB/var/adm/messages\fP though that
can be changed by modifying \fB/etc/syslog.conf\fP. (See \fIsyslogd\fR(8)
and \fIsyslog.conf\fR(5).)
If you allow access to infosystems such as Gopher or WWW,
you should be aware that they by nature would tend to get connections
to hosts all over the world and would use not only Gopher and WWW ports
but possibly also ports for finger, telnet, ftp, nntp, etc. as well as
non-privileged ports ( > 1023).
For a stand-alone sockd, \fB/etc/sockd.fc\fP (or \fB/etc/sockd.conf\fP)
and \fB/etc/sockd.fr\fP (or \fB/etc/sockd.route\fP),
if required, are only read and parsed once at the beginning of program
execution. If you change the contents of either file and want to make
the running sockd use the new contents, you must send a SIGHUP signal
to the running sockd process. Sending a running stand-alone sockd a
SIGUSR1 signal causes it to record on the systems's log file the effective
contents of configuration and route files that it is currently using.
You can find the process id of the stand-alone sockd in
\fB/etc/sockd.pid\fP.
Rather than using plain-text configuration file \fB/etc/sockd.conf\fP
and route file \fB/etc/sockd.route\fP, \fIsockd\fR now looks for the
corresponding \fIfrozen\fR files \fB/etc/sockd.fc\fP and \fB/etc/sockd.fr\fP
first. The plain-text files are used only if the corresponding frozen
files are not found. Use commands \fImake_sockdfc\fR and \fImake_sockdfr\fR
to produce the frosen files. Use commands \fIdump_sockdfc\fR and
\fIdump_sockdfr\fR to examine the contents of frozen files. (See
\fImake_sockdfc\fR(8), \fImake_sockdfr\fR(8), \fIdump_sockdfc\fR(8),
and \fIdump_sockdfr\fR(8).) Using frozen configuration and route files
can save a lot of overhead at start-up of \fIsockd\fR.
.SH OPTIONS
The options are mutually exclusive and thus may only be used one at a time.
.TP
.B\-ver
With this option, \fIsockd\fR prints its own version number,
the version number of the SOCKS protocol, whether it is SOCKSified,
whether it is a standalone daemon or must be run under inetd, whether
it support RBIND, and whether a route file is required.
.TP
.B\-I
Use \fIidentd\fR (RFC 1413) to verify the requester's user-id. Deny access if
connection to client's \fIidentd\fR fails or if the result does not match
the user-id reported by the client program. Client hosts without a properly
installed \fIidentd\fR daemon will not be served. User verification is
done before and in addition to the normal access control. This can be
overridden in the sockd.conf file on a line by line basis.
.TP
.B\-i
Similar to \fB-I\fP but more lenient. Access is denied only if client's
\fIidentd\fR reports a user-id that's different from what the client
program claims. This can be overridden in the sockd.conf file on a line
by line basis.
.PP
Log entries similar to the following are produced upon failure of
user-id verification:
.nf
.in +1
Apr 15 14:42:51 eon sockd[729]: cannot connect to identd on big.edu
Apr 15 14:42:51 eon sockd[729]: refused -- Connect from bob(unknown)@big.edu to xyz.com (ftp)
Jul 15 12:23:06 eon sockd[832]: *Alert*: real user is sam, not jim
Jul 15 12:23:06 eon sockd[832]: refused -- Connect from jim(sam)@abc.org to bad.place.com (WWW)
.in -1
.fi
.SH FILES
\fB/etc/sockd.fc\fP, \fB/etc/sockd.conf\fP,
\fB/etc/sockd.fr\fP, \fB/etc/sockd.route\fP,
\fB/etc/inetd.conf\fP, \fB/etc/services\fP,
\fB/var/adm/messages\fP, \fB/etc/syslog.conf\fP
.SH SEE ALSO
\fIsocks_clients\fR(1), \fIsockd.conf\fR(5),
\fIsockd.route\fR(5), \fIsocks.conf\fR(5),
\fImake_sockdfc\fR(8), \fImake_sockdfr\fR(8),
\fIdump_sockdfc\fR(8), \fIdump_sockdfr\fR(8)
.SH AUTHOR
.nf
David Koblas, koblas@sgi.com
Ying-Da Lee, ylee@syl.dl.nec.com
David Mischel, dm@kansas.gene.com
|
