Dante Manual Page: SOCKD.CONF(5)
SOCKD.CONF(5) SOCKD.CONF(5)
NAME
sockd.conf - Dante server configuration file syntax
DESCRIPTION
The configuration file for the Dante server controls both
access controls and logging. It is divided into three
parts; server settings, rules, and routes. A line can be
commented using the standard comment character #.
SERVER SETTINGS
The server settings control the generic behaviour of the
server. Each keyword is separated from it's value by a
':' character.
clientmethod
A list of acceptable authentication methods for
client-rules, in order of preference. These are
the authentication methods that can be checked
before the socks-negotiation has completed.
Supported values are none, gssapi, rfc931 and pam.
For all methods except gssapi, that means the
authentication will be based on solely on the IP-
address of the client, possibly in combination with
a rfc931 ("ident") lookup.
This list is used as the default for all coming
rules until changed. Then the changed list is used
as the default for the next rules.
The default value is all methods that may be neces-
sary for the later socks-based authentication, as
specified in the socks-method line. Normally you
should not need to set this variable.
Any credentials provided during this pass will also
be available for use in later socks-rules, when the
socks-request from the client is evaluated.
compatibility
With the sameport 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 privi-
leged ports.
The reuseaddr keyword might solve problems when the
bind extension is used but the effects of enabling
reuseaddr is currently unknown, do not enable it
unless you understand the effects.
The draft-5.05 keyword will enable usage of parts
of the socks v5-05 draft. The only feature from
January, 2009 1
SOCKD.CONF(5) SOCKD.CONF(5)
this draft that Dante supports is the "USE-
CLIENTSPORT" extension. Note that there is a con-
flicting interpretation of this extension, so
enabling it might prevent clients using the con-
flicting interpretation from working correctly.
This only affects udp.
timeout.connect
The number of seconds the server will wait for a
connect initiated on behalf of the socks-client to
complete. The default is 15. Setting it to 0 will
use the systems default.
timeout.negotiate
The number of seconds a client can spend negotiat-
ing with the Dante server for a socks session
before Dante will close the connection to the
client. The default is 30. Set it to 0 for for-
ever, though that is strongly discouraged.
timeout.io
The number of seconds an established connection can
be idle. The default is 86400 (24 hours). Set it
to 0 for forever. See also the "-n" option in the
sockd(8) manpage.
Individual timeouts can be set for tcp and udp by
suffixing io with ".", i.e. time-
out.io.tcp or timeout.io.udp
debug Print debug info to the logs. The value sets the
debug level.
external
The address to be used for outgoing connections.
The address given may be either a IP address or an
interface name. Can be given multiple times for
different addresses.
external.rotation
If more than one external address is given, this
governs which address is selected. Valid values
are none (the default) and route. The latter might
require you to set user.privileged to root.
Note that route might create problems for ftp-
clients using active ftp if the Dante bind exten-
sion is enabled for the ftp-client.
internal
The internal addresses. Connections will only be
accepted on these addresses. The address given may
be either a IP address or an interface name.
January, 2009 2
SOCKD.CONF(5) SOCKD.CONF(5)
logoutput
This value controls where the server sends logout-
put. It can be either syslog[/facility], stdout,
stderr, a filename, or a combination. The default
is nowhere.
method Also known as the socks-method line. A list of
acceptable authentication methods for socks-rules,
in order of preference. Supported values are user-
name, none, rfc931 and pam.
This list is used as the default for all coming
rules until changed. Then the changed list is used
as the default for the next rules. The default is
no methods, which means all socks-requests will be
blocked.
If a method is not set in this list it will never
be selected.
See the section on methods for a explanation of the
different methods and their meaning.
srchost
With the nomismatch keyword, the server will not
accept connects from addresses having a mismatch
between DNS address and hostname. Default is to
accept them.
With the nounknown keyword, the server will not
accept connects from addresses without a DNS
record. Default is to accept them.
With the checkreplyauth keyword, the server will
check that the authentication on bind-replies and
udp-replies matches that which is set in the rule
and global method. Normally, authentication is not
desired on these replies, as they are replies sent
to the socks-clients, from non-socks clients, and
thus only a limited set of authentication methods
are possible. These methods are the methods not
involving the socks protocol; rfc931 and pam (using
only the ipaddress and portnumber). Default is not
to check the authentication on replies.
udp.connectdst
Enables or disables whether the server should
attempt connecting udp sockets to the destination.
Valid values are yes and no. The default is yes,
which improves udp performance, but may not be com-
patible with some udp-based application protocols
as it means the server can only receive packets
January, 2009 3
SOCKD.CONF(5) SOCKD.CONF(5)
from the destination address.
Userids
On platforms providing a privilege-model supported
by Dante, the Dante server does not use userid-
switching via the seteuid(2) system call. On other
platforms, it is prudent to set the userid to be
used by the Dante server to appropriate values.
The Dante server can use two different userids,
three if compiled with libwrap support. They are
as follows:
user.privileged
Username which will be used for doing privileged
operations. If you need special privileges to read
the sockd.conf file or to write the sockd.pid file
(you can create it manually before starting sockd),
have anything in your configuration that requires
binding privileged tcp/udp ports (ports below
1024), or use some sort of password-based authenti-
cation, this probably needs to be set to root.
If not, you can probably set it to the same value
as user.unprivileged.
user.unprivileged
User which the server runs as most of the time.
This should be an id with as little privileges as
possible.
user.libwrap
User used to execute libwrap commands. Normally
this should be the same as user.unprivileged
MODULES
The following modules are supported by Dante. Modules are
purchased separately from Inferno Nettverk A/S. See the
Dante homepage for more information.
bandwidth
The bandwidth module gives you control over how
much bandwidth the Dante server uses on behalf of
different clients.
redirect
The redirect module gives you control over what
addresses the server will use on behalf of the
client, aswell as allowing you to redirect client
January, 2009 4
SOCKD.CONF(5) SOCKD.CONF(5)
requests to a different addresses.
session
The session module gives you control over the num-
ber of sessions that can be created by different
socks users.
AUTHENTICATION METHODS
The Dante server supports the following authentication
methods. Some installations of Dante may support only a
subset of these.
none This method requires no form of authentication.
username
This method requires the client to provide a user-
name and password. This must match the username
and password given in the system passwordfile.
gssapi This method requires the setup of a Kerberos envi-
ronment and can provide strong encryption and
authentication.
rfc931 This method requires the client host to provide a
rfc931 ("ident") reply for the connecting client.
This must match a username given in the system
passwordfile.
pam This method requires the available clientdata to
match against the pam database.
ADDRESSES
Each address field can consist of a IP address (and where
meaningful, a netmask, separated from the IP address by a
'/' sign.), a hostname, a domainname (designated so by the
leading '.'), or an interface name. Each address can be
followed by a optional port specifier.
RULES
There are two sets of rules and they work at different
levels. Rules prefixed with client are checked first and
are used to see if the client is allowed to connect to the
Dante server. We will call them "client-rules".
It is recommended that these do not use hostnames but
only IP addresses, both for security and performance rea-
sons. These rules work at the TCP level.
January, 2009 5
SOCKD.CONF(5) SOCKD.CONF(5)
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.
Both set of rules start with a pass/deny keyword (the
client-rules have "client" prefixed to the pass/deny key-
word) which determines if connections matching the rule
are to pass or be blocked. Both set of rules also specify
a from/to address pair which gives the addresses the rule
will match.
In both contexts, from means the clients address.
In the client-rule context, to means the address the
request is accepted on, i.e. the address the Dante server
listens on.
In the socks-rule context, to means the client's destina-
tion address, as formulated in the client's proxy request.
Both set of rules are evaluated on a "first match is best
match" basis. That means, the first rule matched for a
particular client or socks request is the rule that will
be used.
In addition to the addresses there is a set of optional
keywords which can be given. There are two forms of key-
words, conditions and actions. For each rule, all condi-
tions are checked and if they match the request, the
actions are executed.
The list of condition keywords is: clientcompatibility,
command, from, method, protocol, proxyprotocol, to, user.
The list of actions keywords is: bandwidth, libwrap, log,
maxsessions, redirect, and udp.portrange.
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.
The contents of a client-rule is:
bandwidth
The clients matching this rule will all share the
given amount of bandwidth, measured in bytes per
second. Requires the bandwidth module.
clientcompatibility
Enables certain options for compatibility with
January, 2009 6
SOCKD.CONF(5) SOCKD.CONF(5)
broken clients. Valid values are: necgssapi, for
compatibility with clients implementing GSSAPI the
NEC socks way.
from The rule applies to requests coming from the
address given as value.
group The user must belong to one of the groups given as
value.
Note that if gssapi-based authentication is used,
the username as provided to the Dante server nor-
mally includes the Kerberos domain. The name must
be listed on the same form here and in the system
groupfile (usually /etc/passwd) if it is to be
used.
gssapi.enctype
Which encryption to enforce for GSSAPI-authenti-
cated communication. Possible values are clear,
integrity, or confidentiality. The default is to
accept whatever the client offers.
gssapi.keytab
Value for keytab to use. The default is
"FILE:/etc/sockd.keytab".
gssapi.servicename
Which servicename to use when involving GSSAPI.
Default is "rcmd".
libwrap
The server will pass the line to libwrap for execu-
tion.
log Used to control logging. Accepted keywords are
connect, disconnect, data, error and iooperation.
The default is no logging.
maxsessions
Limit the number of active sessions allowed by this
rule to the given value. Requires the session mod-
ule.
method Require that the connection be "authenticated"
using one of the given methods.
port Parameter to from, to and via. Accepts the key-
words eq/=, neq/!=, ge/>=, le/<=, gt/>, lt/< fol-
lowed by a number. A portrange can also be given
as "port - ", which will match all
port numbers within the range and .
The default is all ports.
pam.servicename
Which servicename to use when involving pam.
Default is "sockd".
to The rule applies to requests going to the address
given as value.
user The user must match one of the names given as
value. If no user value is given for a rule
requiring usernames, the effect will be the same as
listing every user in the passwordfile.
Note that if gssapi-based authentication is used,
the username as provided to the Dante server nor-
mally includes the Kerberos domain. The name must
be listed on the same form here if it is to be
used.
The contents of a socks-rule is:
bandwidth
The clients matching this rule will all share the
given amount of bandwidth, measured in bytes per
second. Requires the bandwidth module.
command
The rule applies to the given commands. Valid com-
mands are bind, bindreply, connect, udpassociate
and udpreply. Can be used instead of, or to com-
plement, protocol. The default is all commands
valid for the protocols allowed by the rule.
from The rule applies to requests coming from the
address given as value.
group The user must belong to one of the groups given as
value.
libwrap
The server will pass the line to libwrap for execu-
tion.
log Used to control logging. Accepted keywords are
connect, disconnect, data and iooperation.
maxsessions
Limit the number of active sessions allowed by this
rule to the given value. Requires the session
January, 2009 8
SOCKD.CONF(5) SOCKD.CONF(5)
module.
method Require that the connection be established using
one of the given methods. method always refers to
the source part of the rule. Valid values are the
same as in the global method line.
pam.servicename
What servicename to use when involving pam.
Default is "sockd".
port Parameter to from, to and via. Accepts the key-
words eq/=, neq/!=, ge/>=, le/<=, gt/>, lt/< fol-
lowed by a number. A portrange can also be given
as "port - ", which will match all
port numbers within the range and .
The default is all ports.
protocol
The rule applies to the given protocols. Valid
values are tcp and udp. The default is all sup-
ported protocols.
proxyprotocol
The rule applies to requests using the given proxy
protocol. Valid proxy protocols are socks_v4 and
socks_v5. The default is all supported proxy pro-
tocols.
redirect
The source and/or destination can be redirected
using the redirect statement. Requires the redi-
rect module.
The syntax of the redirect statement is as follows:
redirect from: ADDRESS
redirect to: ADDRESS
The semantics of from and to vary according to com-
mand. See the redirect manual for detailed infor-
mation.
to The rule applies to requests going to or using the
address given as value. Note that the meaning of
this address is affected by command.
udprange
The argument to this keyword is two portnumbers,
January, 2009 9
SOCKD.CONF(5) SOCKD.CONF(5)
separated by a dash ('-'). They specify the udp
port-range that will be used between the socks-
client and the Dante-server for udp packets. Note
that this has no relation to the udp port-range
used between the Dante-server and external, non-
socks, clients/servers.
user The user must match one of the names given as
value. If no user value is given for a rule
requiring usernames, the effect will be the same as
listing every user in the passwordfile.
ROUTES
The routes are specified with a route keyword. Inside a
pair of parenthesis ({}) a set of keywords control the
behavior of the route. See socks.conf(5) for a descrip-
tion. This is used to perform so-called "server-chain-
ing", where one socks-server connects to another socks-
server further upstream.
Note that at present, server-chaining is only supported
for the connect command.
EXAMPLES
See the example directory in the distribution.
FILES
/etc/sockd.conf Dante server configuration file.
/etc/passwd file used when checking username/passwords.
AUTHORS
For inferno Nettverk A/S:
Michael Shuldman
Karl-Andre' Skevik
SEE ALSO
sockd(8), socks.conf(5), hosts_access(5) Information about
new releases and other related issues can be found on the
WWW home page: http://www.inet.no/dante/
January, 2009 10
Inferno Nettverk A/S
Oslo Research Park, Gaustadalléen 21, NO-0349 Oslo, Norway
Tlf.: +47 22958303 Fax: +47 22604427
![[BANNER]](/icons/stripetoppinns_01.jpg){kind=icon}