dante   Frontpage - Dante - Download - Status - Support - Modules - Docs - Links - Survey - GDPR
 

Manual Page: SOCKD.CONF(5)

SOCKD.CONF(5)                 File Formats Manual                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.

       child.maxidle
              Maintains a rough max on how many children of each type can
              remain idle, waiting for clients.  This is used to reduce the
              amount of idle processes after a "client burst" has passed.  The
              default is no (no maximum), which is the recommended value for
              high load environments, but it can be set to "yes" if it is
              desirable to limit the process count, though note that setting
              it to "yes" may decrease performance.


       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 necessary 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
              privileged 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 this draft that Dante
              supports is the "USECLIENTSPORT" extension.  Note that there is
              a conflicting interpretation of this extension, so enabling it
              might prevent clients using the conflicting interpretation from
              working correctly.  This only affects udp.


       timeout.negotiate
              The number of seconds a client can spend negotiating 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
              forever, 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 ".<protocolname>", i.e. timeout.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, and will try to determine what local address would normaly
              be selected by the kernel for connecting to the given
              destination.  If that address is listed amongst the external
              addresses, the Dante server will connect out from that address.

              Note that route might create problems for ftp-clients using
              active ftp if the Dante bind extension 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.

       logoutput
              This value controls where the server sends logoutput.  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 username, 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 compatible with some udp-based application protocols as it
              means the server can only receive packets 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 authentication, 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 requests to a different addresses.


       session
              The session module gives you control over the number 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 username and
              password.  This must match the username and password given in
              the system passwordfile.

       gssapi This method requires the setup of a Kerberos environment 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 reasons.  These rules work
       at the TCP 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.

       Both set of rules start with a pass/deny keyword (the client-rules have
       "client" prefixed to the pass/deny keyword) 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 destination 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 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: 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 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 normally 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-authenticated
              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 execution.

       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 module.

       method Require that the connection be "authenticated" using one of the
              given methods.

       port   Parameter to from, to and via.  Accepts the keywords eq/=,
              neq/!=, ge/>=, le/<=, gt/>, lt/< 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
              #>.

              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 normally 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 commands are
              bind, bindreply, connect, udpassociate and udpreply.  Can be
              used instead of, or to complement, 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 execution.

       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 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 keywords eq/=,
              neq/!=, ge/>=, le/<=, gt/>, lt/< 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
              #>.

              The default is all ports.


       protocol
              The rule applies to the given protocols.  Valid values are tcp
              and udp.  The default is all supported 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 protocols.

       redirect
              The source and/or destination can be redirected using the
              redirect statement.  Requires the redirect 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 command.  See the
              redirect manual for detailed information.


       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, 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 description.  This is used to perform so-called
       "server-chaining", 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                   SOCKD.CONF(5)



Copyright © 1998-2018 Inferno Nettverk A/S