1
.\" $Id: sockd.conf.5,v 1.58 2001/12/12 13:18:07 karls Exp $
3
.\" Copyright (c) 1997, 1998, 1999, 2000, 2001
4
.\" Inferno Nettverk A/S, Norway. All rights reserved.
6
.\" Redistribution and use in source and binary forms, with or without
7
.\" modification, are permitted provided that the following conditions
9
.\" 1. The above copyright notice, this list of conditions and the following
10
.\" disclaimer must appear in all copies of the software, derivative works
11
.\" or modified versions, and any portions thereof, aswell as in all
12
.\" supporting documentation.
13
.\" 2. All advertising materials mentioning features or use of this software
14
.\" must display the following acknowledgement:
15
.\" This product includes software developed by
16
.\" Inferno Nettverk A/S, Norway.
17
.\" 3. The name of the author may not be used to endorse or promote products
18
.\" derived from this software without specific prior written permission.
20
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
21
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
22
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
23
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
24
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
25
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
26
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
27
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
28
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
29
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
31
.\" Inferno Nettverk A/S requests users of this software to return to
33
.\" Software Distribution Coordinator or sdc@inet.no
34
.\" Inferno Nettverk A/S
35
.\" Oslo Research Park
40
.\" any improvements or extensions that they make and grant Inferno Nettverk A/S
41
.\" the rights to redistribute these changes.
43
.TH SOCKD.CONF 5 "May 11, 2001"
45
sockd.conf \- \fBDante\fP server configuration file syntax
47
The configuration file for the \fBDante\fP server controls both access
48
controls and logging. It is divided into two parts, server settings
49
and rules. A line can be commented using the standard comment
52
The server settings control the generic behaviour of the server. Each
53
keyword is separated from it's value by a \fB':'\fP character.
54
.IP \fBcompatibility\fP
55
With the \fBsameport\fP keyword, the server attempts to use the same
56
port on the server and the client. This functionality is the default, but
57
when this option is given it will also be done with privileged ports.
58
The \fBreuseaddr\fP keyword might solve problems when the
59
bind extension is used but the effects of enabling \fBreuseaddr\fP
60
is currently unknown, do not enable it unless you understand
62
.IP \fBconnecttimeout\fP
63
The number of seconds a client has to send the request after a connect.
64
Set it to 0 for forever.
66
The address to be used for outgoing connections.
67
The address given may be either a IP address or a interfacename.
68
Can be given multiple times for different addresses.
69
.IP \fBexternal.rotation\fP
70
If more than one external address is given, this governs which
71
address is selected. Valid values are \fBnone\fP (the default) and
72
\fBroute\fP. Note that \fBroute\fP might create problems for
73
ftp-clients using active ftp if the \fBDante\fP bind extension
74
is enabled for the ftp-client.
76
The internal addresses. Connections will only be accepted on these addresses.
77
The address given may be either a IP address or a interfacename.
79
The number of seconds an established connection can be idle. Set it
82
This value controls where the server sends logoutput. It can
83
be either \fBsyslog\fP[/\fBfacility\fP], \fBstdout\fP, \fBstderr\fP,
84
a filename, or a combination.
86
A list of acceptable authentication methods for socks-rules, in order
88
Supported values are \fBusername\fP, \fBnone\fP, \fBrfc931\fP and \fBpam\fP.
89
This list is used as the default for all coming rules until
90
changed. Then the changed list is used as the default for
93
If a method is not set in this list it will never be selected.
95
See the section on methods for a explanation of the different methods.
97
.IP \fBclientmethod\fP
98
A list of acceptable authentication methods for client-rules,
99
in order of preference. These are the authenticationmethods
100
that can provide authentications based on just the client's
102
Supported values are \fBnone\fP, \fBrfc931\fP and \fBpam\fP.
103
This list is used as the default for all coming rules until
104
changed. Then the changed list is used as the default for
105
the next rules. The default value is \fBnone\fP.
107
If a method is not set in this list it will never be selected.
110
With the \fBnomismatch\fP keyword, the server will not accept
111
connects from addresses having a mismatch between DNS address and hostname.
112
Default is to accept them.
113
With the \fBnounknown\fP keyword, the server will not accept connects
114
from addresses without a DNS record. Default is to accept them.
116
.IP \fBuser.privileged\fP
117
Username which will be used for doing privileged operations.
118
.IP \fBuser.notprivileged\fP
119
User which the server runs as most of the time.
120
.IP \fBuser.libwrap\fP
121
User used to execute libwrap commands.
124
The following modules are supported by \fBDante\fP. Modules are purchased
125
separately from Inferno Nettverk A/S. See the \fBDante\fP homepage
126
for more information.
129
The \fBredirect\fP module gives you control over what addresses the
130
server will use on behalf of the client and allows you to both
131
redirect client requests to a different addresses aswell as control
132
the range of addresses and ports to be used on behalf of the client.
134
It can also be used to restrict the number of concurrent sessions
138
The \fBbandwidth\fP module gives you control over how much
139
bandwidth the Dante server uses on behalf of different clients.
142
The \fBDante\fP server supports the following methods. Some
143
installations of \fBDante\fP may support only a subset of these.
146
The method requires no form of authentication.
148
The method requires the client to provide a username and password.
149
This must match the username and password given in the system
152
The method requires the client host to provide a rfc931 ("ident")
153
reply for the connecting client. The name given in the reply
154
must be present in the password database.
156
The method requires the available clientdata to match against the
161
Each address field can consist of a IP address (and where meaningful,
162
a netmask, separated from the IP address by a '\fB/\fP' sign.), a hostname,
163
or a domainname (designated so by the leading '\fB.\fP').
164
Each address can be followed by a optional \fBport\fP specifier.
166
There are two sets of rules and they work at different levels.
167
Rules prefixed with \fBclient\fP are checked first and are used to
168
see if the client is allowed to connect to the \fBDante\fP server.
169
We will call them "client-rules".
170
It is especially important that these do not use hostnames
171
but only IP addresses, both for security and performance reasons.
172
These rules work at the TCP/IP level.
174
The other rules, which we will call "socks-rules" are a level higher
175
and are checked after the client connection has been accepted by the
176
client-rules. The socks-rules are used to evaluate the socks request
177
that the client sends. They thus work at the socks protocol level.
179
Both set of rules start with a \fBpass\fP/\fBdeny\fP keyword (the
180
client-rules have "client" prefixed to the \fBpass\fP/\fBdeny\fP
181
keyword) which determines if connections matching the rule are to
182
pass or be blocked. Both set of rules also specify a \fBfrom\fP/\fBto\fP
183
address pair which gives the addresses the rule will match.
185
In both contexts, \fBfrom\fP means the clients address.
187
In the client-rule context, \fBto\fP means the address the request
188
is accepted on, i.e. the address the \fBDante\fP server listens
191
In the socks-rule context, \fBto\fP means the client's destination address,
192
as formulated in the client's proxy request.
194
In addition to the addresses there is a set of optional keywords which
195
can be given. There are two forms of keywords, conditions and
196
actions. For each rule, all conditions are checked and if they
197
match the request, the actions are executed.
199
The list of condition keywords is:
200
\fBfrom\fP, \fBto\fP, \fBcommand\fP, \fBmethod\fP,
201
\fBprotocol\fP, \fBproxyprotocol\fP, \fBuser\fP.
203
The list of actions keywords is: \fBbandwidth\fP, \fBlibwrap\fP,
204
\fBlog\fP and \fBredirect\fP.
206
The format and content of the rules is identical, but client-rules
207
may contain only a subset of the socks-rules. More concrete, they
208
may not contain any keywords related to the socks protocol.
211
The contents of a client-rule is:
214
The rule applies to requests coming from the address given as value.
216
The rule applies to requests going to the address given as value.
218
Parameter to \fBfrom\fP, \fBto\fP and \fBvia\fP. Accepts the keywords
219
\fBeq/=, neq/!=, ge/>=, le/<=, gt/>, lt/<\fP followed by a number.
220
A portrange can also be given as "port <start #> - <end #>", which
221
will match all port numbers within the range <start #> and <end #>.
223
The server will pass the line to libwrap for execution.
225
Used to control logging. Accepted keywords are \fBconnect\fP,
226
\fBdisconnect\fP, \fBdata\fP, \fBerror\fP and \fBiooperation\fP.
228
The server will only accept connections from users matching one
229
of the names given as value.
230
If no \fBuser\fP value is given, everyone in the passwordfile
232
The rule must also allow usernamebased methods.
234
Require that the connection be "authenticated" using one of the
236
.IP \fBpam.servicename\fP
237
Which servicename to use when involving pam. Default is "sockd".
240
The contents of a socks-rule is:
243
The rule applies to requests coming from the address given as value.
245
The rule applies to requests going to or using the address given as value.
246
Note that the meaning of this address is affected by \fBcommand\fP.
248
Parameter to \fBfrom\fP, \fBto\fP and \fBvia\fP. Accepts the keywords
249
\fBeq/=, neq/!=, ge/>=, le/<=, gt/>, lt/<\fP followed by a number.
250
A portrange can also be given as "port <start #> - <end #>", which
251
will match all port numbers within the range <start #> and <end #>.
254
The clients matching this rule will all share this amount of bandwidth.
256
The rule applies to the given commands. Valid commands
257
are \fBbind\fP, \fBbindreply\fP, \fBconnect\fP, \fBudpassociate\fP
258
and \fBudpreply\fP. Can be used instead of, or to complement,
261
The server will pass the line to libwrap for execution.
263
Used to control logging. Accepted keywords are \fBconnect\fP,
264
\fBdisconnect\fP, \fBdata\fP and \fBiooperation\fP.
266
Require that the connection be established using one of the
267
given methods. \fBmethod\fP always refers to the source part of
269
Valid values are the same as in the global \fBmethod\fP line.
270
.IP \fBpam.servicename\fP
271
What servicename to use when involving pam. Default is "sockd".
273
The rule applies to the given protocols. Valid values are
274
\fBtcp\fP and \fBudp\fP. It is recommended that the \fBcommand\fP
275
form is used since it provides more accuracy in defining rules.
276
.IP \fBproxyprotocol\fP
277
The rule applies to requests using the given proxyprotocol.
278
Valid proxyprotocols are \fBsocks_v4\fP and \fBsocks_v5\fP.
280
The source and/or destination can be redirected using the
281
\fBredirect\fP statement. The syntax of the statement is
285
\fBredirect\fP from: \fBADDRESS\fP
288
\fBredirect\fP to: \fBADDRESS\fP
290
The semantics of \fBfrom\fP and \fBto\fP vary according to
291
\fBcommand\fP and should be intuitive enough.
294
The server will accept connections from users matching one
295
of the names given as value.
296
If no \fBuser\fP value is given, everyone in the passwordfile
298
The rule must also allow usernamebased methods.
300
See the example directory in the distribution.
304
/etc/sockd.conf \fBDante\fP server configuration file.
305
/etc/passwd file used when checking username/passwords.
308
For Inferno Nettverk A/S, Norway:
309
Michael Shuldman <michaels@inet.no>: Design and implementation.
310
Karl-Andre' Skevik <karls@inet.no>: Autoconf and porting.
312
sockd(8), hosts_access(5)
314
Information about new releases and other related issues can be found
317
WWW home page at http://www.inet.no/dante.
added
removed
doc/sockd.conf.5
