Provided by: dante-server_1.1.19.dfsg-3.1ubuntu3_amd64 bug

NAME

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

       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.

       connecttimeout
              The number of seconds a client has to send the request after a connect.  Set it to 0 for forever.

       external
              The address to be used for outgoing connections.  The address given may be either a IP address  or
              a interfacename.  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 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 a interfacename.

       iotimeout
              The number of seconds an established connection can be idle.  Set it to 0 for forever.

       logoutput
              This value controls where the server sends logoutput.  It can be either syslog[/facility], stdout,
              stderr, a filename, or a combination.

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

              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.

       clientmethod
              A  list  of acceptable authentication methods for client-rules, in order of preference.  These are
              the authenticationmethods that  can  provide  authentications  based  on  just  the  client's  TCP
              connection.   Supported values are 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 value is none.

              If a method is not set in this list it will never be selected.

       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.

       user.privileged
              Username which will be used for doing privileged operations.

       user.notprivileged
              User which the server runs as most of the time.

       user.libwrap
              User used to execute libwrap commands.

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  and allows you to both redirect client requests to a different addresses aswell as control
              the range of addresses and ports to be used on behalf of the client.

       session
              The session module gives you control over the number of sessions that can be created by  different
              socks users.

METHODS

       The  Dante  server supports the following methods.  Some installations of Dante may support only a subset
       of these.

       none   The method requires no form of authentication.

       username
              The method requires the client to provide a username and password.  This must match  the  username
              and password given in the system passwordfile.

       rfc931 The method requires the client host to provide a rfc931 ("ident") reply for the connecting client.
              The name given in the reply must be present in the password database.

       pam    The 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, or a domainname (designated so by the leading  '.').   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 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  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.

       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: from, to, command, method, protocol, proxyprotocol, user.

       The list of actions keywords is: bandwidth, libwrap, log and redirect.

       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:

       from   The rule applies to requests coming from the address given as value.

       to     The rule applies to requests going to the address given as value.

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

       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.

       user   The  server  will only accept connections from users matching one of the names given as value.  If
              no user value is given, everyone in the passwordfile will be matched.  The rule  must  also  allow
              usernamebased methods.

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

       pam.servicename
              Which servicename to use when involving pam.  Default is "sockd".

              The contents of a socks-rule is:

       from   The rule applies to requests coming from the address given as value.

       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.

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

       bandwidth
              The clients matching this rule will all share this amount of bandwidth.

       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.

       libwrap
              The server will pass the line to libwrap for execution.

       log    Used to control logging.  Accepted keywords are connect, disconnect, data and iooperation.

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

       protocol
              The  rule  applies  to the given protocols.  Valid values are tcp and udp.  It is recommended that
              the command form is used since it provides more accuracy in defining rules.

       proxyprotocol
              The rule applies to requests using the given proxyprotocol.  Valid proxyprotocols are socks_v4 and
              socks_v5.

       redirect
              The source and/or destination can be redirected using the redirect statement.  The syntax  of  the
              statement is as follows:

              redirect from: ADDRESS

              redirect to: ADDRESS

              The semantics of from and to vary according to command and should be intuitive enough.

       user   The  server  will  accept  connections from users matching one of the names given as value.  If no
              user value is given, everyone in the passwordfile will be matched.  The rule  must  in  this  case
              also allow usernamebased methods.

ROUTES

       The  routes  are  specified with a route keyword.  Inside a pair of parens ({}) a set of keywords control
       the behavior of the route.  See dante.conf(5) for a description.   This  is  used  to  perform  so-called
       "server-chaining", where one socks-server connects to another socks-server futher upstream.

EXAMPLES

       See the example directory in the distribution.

FILES

       /etc/danted.conf        Dante server configuration file.
       /etc/passwd             file used when checking username/passwords.

AUTHORS

       For Inferno Nettverk A/S, Norway:
        Michael Shuldman <michaels@inet.no>: Design and implementation.
        Karl-Andre' Skevik <karls@inet.no>: Autoconf and porting.

SEE ALSO

       danted(8), dante.conf(5), hosts_access(5)

       Information  about  new  releases  and  other  related  issues can be found on the Dante WWW home page at
       http://www.inet.no/dante.

                                                  May 11, 2001                                    DANTED.CONF(5)