.\" $Id: sockd.conf.5,v 1.71 2006/01/20 12:59:09 michaels Exp $ .\" .\" Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 .\" 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 sdc@inet.no .\" Inferno Nettverk A/S .\" Oslo Research Park .\" Gaustadalléen 21 .\" NO-0349 Oslo .\" Norway .\" .\" any improvements or extensions that they make and grant Inferno Nettverk A/S .\" the rights to redistribute these changes. .\" .TH DANTED.CONF 5 "May 11, 2001" .SH NAME danted.conf \- \fBDante\fP server configuration file syntax .SH DESCRIPTION The configuration file for the \fBDante\fP 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 \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 \fBchild.maxidle\fP .\" Maintains a maximum on how many children of each type can remain .\" idle. Used to reduce the amount of idle processes after a "client burst" .\" has occured. The default is \fB0\fP (no maximum). .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 \fBconnecttimeout\fP The number of seconds a client has to send the request after a connect. Set it to 0 for forever. .IP \fBexternal\fP 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. .IP \fBexternal.rotation\fP If more than one external address is given, this governs which address is selected. Valid values are \fBnone\fP (the default) and \fBroute\fP. The latter might require you to set \fBuser.privileged\fP to \fBroot\fP. Note that \fBroute\fP might create problems for ftp-clients using active ftp if the \fBDante\fP bind extension is enabled for the ftp-client. .IP \fBinternal\fP The internal addresses. Connections will only be accepted on these addresses. The address given may be either a IP address or a interfacename. .IP \fBiotimeout\fP The number of seconds an established connection can be idle. Set it to 0 for forever. .IP \fBlogoutput\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 \fBmethod\fP A list of acceptable authentication methods for socks-rules, in order of preference. Supported values are \fBusername\fP, \fBnone\fP, \fBrfc931\fP and \fBpam\fP. 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. .IP \fBclientmethod\fP 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 \fBnone\fP, \fBrfc931\fP and \fBpam\fP. 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 \fBnone\fP. If a method is not set in this list it will never be selected. .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 \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. .SH MODULES The following modules are supported by \fBDante\fP. Modules are purchased separately from Inferno Nettverk A/S. See the \fBDante\fP homepage for more information. .IP \fBbandwidth\fP The \fBbandwidth\fP module gives you control over how much bandwidth the Dante server uses on behalf of different clients. .IP \fBredirect\fP The \fBredirect\fP 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. .IP \fBsession\fP The \fBsession\fP module gives you control over the number of sessions that can be created by different socks users. .SH METHODS The \fBDante\fP server supports the following methods. Some installations of \fBDante\fP may support only a subset of these. .IP \fBnone\fP The method requires no form of authentication. .IP \fBusername\fP The method requires the client to provide a username and password. This must match the username and password given in the system passwordfile. .IP \fBrfc931\fP 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. .IP \fBpam\fP The method requires the available clientdata to match against the pam database. .SH ADDRESSES Each address field can consist of a IP address (and where meaningful, a netmask, separated from the IP address by a '\fB/\fP' sign.), a hostname, or a domainname (designated so by the leading '\fB.\fP'). Each address can be followed by a optional \fBport\fP specifier. .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: \fBbandwidth\fP, \fBlibwrap\fP, \fBlog\fP and \fBredirect\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 a client-rule 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 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 - ", which will match all port numbers within the range and . .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, \fBerror\fP and \fBiooperation\fP. .IP \fBuser\fP The server will only accept connections from users matching one of the names given as value. If no \fBuser\fP value is given, everyone in the passwordfile will be matched. The rule must also allow usernamebased methods. .IP \fBmethod\fP Require that the connection be "authenticated" using one of the given methods. .IP \fBpam.servicename\fP Which servicename to use when involving pam. Default is "sockd". .IP The contents of a socks-rule 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 - ", which will match all port numbers within the range and . .IP \fBbandwidth\fP The clients matching this rule will all share this amount of bandwidth. .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. \fBmethod\fP always refers to the source part of the rule. Valid values are the same as in the global \fBmethod\fP line. .IP \fBpam.servicename\fP What servicename to use when involving pam. Default is "sockd". .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 \fBredirect\fP The source and/or destination can be redirected using the \fBredirect\fP statement. The syntax of the statement is as follows: .IP \fBredirect\fP from: \fBADDRESS\fP .IP \fBredirect\fP to: \fBADDRESS\fP The semantics of \fBfrom\fP and \fBto\fP vary according to \fBcommand\fP and should be intuitive enough. .IP \fBuser\fP The server will accept connections from users matching one of the names given as value. If no \fBuser\fP value is given, everyone in the passwordfile will be matched. The rule must in this case also allow usernamebased methods. .SH ROUTES The routes are specified with a \fBroute\fP 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. .SH EXAMPLES See the example directory in the distribution. .SH FILES .nf .ta \w 1 /etc/danted.conf \fBDante\fP server configuration file. /etc/passwd file used when checking username/passwords. .fi .SH AUTHORS For Inferno Nettverk A/S, Norway: Michael Shuldman : Design and implementation. Karl-Andre' Skevik : Autoconf and porting. .SH SEE ALSO danted(8), dante.conf(5), hosts_access(5) .PP Information about new releases and other related issues can be found on the .B Dante WWW home page at http://www.inet.no/dante.