sockd.conf.5

sock protocol ,it is useful!

.\" $Id: sockd.conf.5,v 1.28 1999/12/22 09:29:18 karls Exp $
.\"
.\" Copyright (c) 1997, 1998, 1999
.\"      Inferno Nettverk A/S, Norway.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. The above copyright notice, this list of conditions and the following
.\"    disclaimer must appear in all copies of the software, derivative works
.\"    or modified versions, and any portions thereof, aswell as in all
.\"    supporting documentation.
.\" 2. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"      This product includes software developed by
.\"      Inferno Nettverk A/S, Norway.
.\" 3. The name of the author may not be used to endorse or promote products
.\"    derived from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\" Inferno Nettverk A/S requests users of this software to return to
.\"
.\"  Software Distribution Coordinator  or  [e-mail]
.\"  Inferno Nettverk A/S
.\"  Oslo Research Park
.\"  Gaustadal閑n 21
.\"  N-0349 Oslo
.\"  Norway
.\"
.\" any improvements or extensions that they make and grant Inferno Nettverk A/S
.\" the rights to redistribute these changes.
.\"
.TH SOCKD.CONF 5 "June 14, 1999"
.SH NAME
sockd.conf \- Dante server configuration file syntax
.SH DESCRIPTION
The configuration file for the \fBDante\fP server controls both access
controls and logging.  It is divided into two parts, server settings
and rules.  A line can be commented using the standard comment
character \fB#\fP.
.SH SERVER SETTINGS
The server settings control the generic behaviour of the server.  Each
keyword is separated from it's value by a \fB':'\fP character.
.IP \fBlogouput\fP
This value controls where the server sends logoutput.  It can
be either \fBsyslog\fP[/\fBfacility\fP], \fBstdout\fP, \fBstderr\fP,
a filename, or a combination.
.IP \fBinternal\fP
The internal address.  Connections will only be accepted on this address.
Multiple \fBinternal\fP lines may be given.
.IP \fBexternal\fP
The address to be used for outgoing connections.
.IP \fBmethod\fP
A list of acceptable authentication methods, in order of preference.
Supported values are \fBusername\fP, \fBnone\fP and \fBrfc931\fP.
.IP \fBuser.privileged\fP
Username which will be used for doing privileged operations.
.IP \fBuser.notprivileged\fP
User which the server runs as most of the time.
.IP \fBuser.libwrap\fP
User used to execute libwrap commands.
.IP \fBcompatibility\fP
With the \fBsameport\fP keyword, the server attempts to use the same
port on the server and the client.  This functionality is the default, but
when this option is given it will also be done with privileged ports.
The \fBreuseaddr\fP keyword might solve problems when the
bind extension is used but the effects of enabling \fBreuseaddr\fP
is currently unknown, do not enable it unless you understand
the effects.
.IP \fBsrchost\fP
With the \fBnomismatch\fP keyword, the server will not accept
connects from addresses having a mismatch between DNS address and hostname.
Default is to accept them.
With the \fBnounknown\fP keyword, the server will not accept connects
from addresses without a DNS record.  Default is to accept them.
.IP \fBconnecttimeout\fP
The number of seconds a client has to send the request after a connect.
Set it to 0 for forever.
.IP \fBiotimeout\fP
The number of seconds an established connection can be idle.  Set it
to 0 for forever.
.SH RULES
There are two sets of rules and they work at different levels.
Rules prefixed with \fBclient\fP are checked first and are used to
see if the client is allowed to connect to the \fBDante\fP server.
We will call them "client-rules".
It is especially important that these do not use hostnames
but only IP addresses, both for security and performance reasons.
These rules work at the TCP/IP level.

The other rules, which we will call "socks-rules" are a level higher
and are checked after the client connection has been accepted by the
client-rules.  The socks-rules are used to evaluate the socks request
that the client sends.  They thus work at the socks protocol level.

Both set of rules start with a \fBpass\fP/\fBdeny\fP keyword (the
client-rules have "client" prefixed to the \fBpass\fP/\fBdeny\fP
keyword) which determines if connections matching the rule are to
pass or be blocked.  Both set of rules also specify a \fBfrom\fP/\fBto\fP
address pair which gives the addresses the rule will match.

In both contexts, \fBfrom\fP means the clients address.

In the client-rule context, \fBto\fP means the address the request
is accepted on, i.e. the address the \fBDante\fP server listens
on.

In the socks-rule context, \fBto\fP means the client's destination address,
as formulated in the client's proxy request.

In addition to the addresses there is a set of optional keywords which
can be given.  There are two forms of keywords, conditions and
actions.  For each rule, all conditions are checked and if they
match the request, the actions are executed.

The list of condition keywords is:
\fBfrom\fP, \fBto\fP, \fBcommand\fP, \fBmethod\fP,
\fBprotocol\fP, \fBproxyprotocol\fP, \fBuser\fP.

The list of actions keywords is: \fBlibwrap\fP, \fBlog\fP.

The format and content of the rules is identical, but client-rules
may contain only a subset of the socks-rules.  More concrete, they
may not contain any keywords related to the socks protocol.

.IP
The contents of the client-rule is be:

.IP \fBfrom\fP
The rule applies to requests coming from the address given as value.
.IP \fBto\fP
The rule applies to requests going to the address given as value.
.IP \fBport\fP
Parameter to \fBfrom\fP, \fBto\fP and \fBvia\fP.  Accepts the keywords
\fBeq/=, neq/!=, ge/>=, le/<=, gt/>, lt/<\fP followed by a number.
A portrange can also be given as "port <start #> - <end #>", which
will match all port numbers within the range <start #> and <end #>.
.IP \fBlibwrap\fP
The server will pass the line to libwrap for execution.
.IP \fBlog\fP
Used to control logging.  Accepted keywords are \fBconnect\fP,
\fBdisconnect\fP, \fBdata\fP and \fBiooperation\fP.
.IP \fBuser\fP
The server will only accept connections from users matching one
of the names given as value.
It is possible to implicitly list all users in the passwordfile for
a given authentication method by giving the name of the
authentication method as value to \fBuser\fP.
The given username \fBmust\fP regardless always be present in the
passwordfile used by \fBDante\fP.
The rule (and global methods) must also allow a usernamebased
method.  For client-rules this is method \fBrfc931\fP.

.IP
The contents of the socks-rules is:

.IP \fBfrom\fP
The rule applies to requests coming from the address given as value.
.IP \fBto\fP
The rule applies to requests going to or using the address given as value.
Note that the meaning of this address is affected by \fBcommand\fP.
.IP \fBport\fP
Parameter to \fBfrom\fP, \fBto\fP and \fBvia\fP.  Accepts the keywords
\fBeq/=, neq/!=, ge/>=, le/<=, gt/>, lt/<\fP followed by a number.
A portrange can also be given as "port <start #> - <end #>", which
will match all port numbers within the range <start #> and <end #>.
.IP \fBcommand\fP
The rule applies to the given commands.  Valid commands
are \fBbind\fP, \fBbindreply\fP, \fBconnect\fP, \fBudpassociate\fP
and \fBudpreply\fP.  Can be used instead of, or to complement,
\fBprotocol\fP.
.IP \fBlibwrap\fP
The server will pass the line to libwrap for execution.
.IP \fBlog\fP
Used to control logging.  Accepted keywords are \fBconnect\fP,
\fBdisconnect\fP, \fBdata\fP and \fBiooperation\fP.
.IP \fBmethod\fP
Require that the connection be established using one of the
given methods.
Valid values are the same as in the global \fBmethod\fP line.
.IP \fBprotocol\fP
The rule applies to the given protocols.  Valid values are
\fBtcp\fP and \fBudp\fP.  It is recommended that the \fBcommand\fP
form is used since it provides more accuracy in defining rules.
.IP \fBproxyprotocol\fP
The rule applies to requests using the given proxyprotocol.
Valid proxyprotocols are \fBsocks_v4\fP and \fBsocks_v5\fP.
.IP \fBuser\fP
The server will accept connections from users matching one
of the names given as value.
It is possible to implicitly list all users in the passwordfile for
a given authentication method by giving the name of the
authentication method as value to \fBuser\fP.
If no \fBuser\fP value is given, one will automatically be provided
that will match all users for the username-based methods in the rule.
The given username \fBmust\fP regardless always be present in the
passwordfile used by \fBDante\fP.
The rule (and global methods) must also allow a usernamebased
method.  For socks-rules this is method \fBrfc931\fP and \fBusername\fP.
.SH EXAMPLES
See the example directory in the distribution.
.SH FILES
.I /etc/sockd.conf
.SH AUTHORS
For Inferno Nettverk A/S, Norway:
 Michael Shuldman <[e-mail]>: Design and implementation.
 Karl-Andre' Skevik <[e-mail]>: Autoconf and porting.
.SH SEE ALSO
sockd(8), hosts_access(5)