Provided by: socks4-server_4.3.beta2-18_amd64 bug

NAME

       sockd.conf - SOCKS server configuration file

SYNOPSIS

       /etc/sockd.conf

DESCRIPTION

       The  file  /etc/sockd.conf  is  used to control access to SOCKS proxy server sockd and its
       services. (See sockd(8).)  Permission and denial of a service request can be decided based
       on  various combinations of the requesting host, the destination host, the type of service
       (destination port number), as well as the requesting user.  A line in /etc/sockd.conf  can
       be  up  to  1023  characters  long.   Each  line  may  contain the following fields in the
       indicated order:

        action [?=use_identd] [*=userlist] src_addr src_mask [dst_addr dst_mask] [op dst_port]  [
        : shell_cmd ]

       Spaces  and  tabs  separate  the  fields. Fields enclosed in square brackets are optional.
       Blank lines are allowed. Except  for  lines  that  start  with  #NO_IDENTD:  or  #BAD_ID:,
       everything from the first appearance of # to the end of the line is considered comment and
       thus ignored by sockd during normal validation.

       The action field must be either permit or deny and indicates the action to be taken  if  a
       request matches the conditions specified in that line.

       The  use_identd  field,  when  present, must be I, i, or n, and is used to specify whether
       identd verification should be employed for the current line. ?=I demands the use of identd
       for  verifying  the user's identity, denying access if connection to client's identd fails
       or if the result does not match the user-id reported  by  the  client  program.  ?=i  also
       specifies  the  use of identd, but denies access only if client's identd reports a user-id
       different from what the client program claims. ?=n turns off the use of  identd.  For  the
       line  in  which  these  fields are used, they override the global identd setting, which is
       determined by options -I and -i on the sockd command line.

       The userlist field, when present, consists of one or  more  user-ids  or  filenames,  with
       comma  as separator. No spaces or tabs are allowed in the list. The user-ids should be ids
       of users on the requesting host, not those on the destination host  or  the  SOCKS  server
       host.   The  filenames  must  be  full  pathnames with the leading /. Inside the specified
       files, user-ids may be listed one or several per line, with  any  combination  of  blanks,
       tabs,  and  commas  as  separators. The appearance of # marks the remainder of the line as
       comment. Each line in the files may be up to 1023  characters  long.   If  the  *=userlist
       field is omitted, the line applies to all user-ids.

       The  src_addr  and  dst_addr  fields  either  specify  IP addresses of hosts, networks, or
       subnets in the usual dotted form, e.g., 129.201.4.0, or a domain name, e.g., internic.net.
       The  src_mask  and  dst_mask fields are masks for the corresponding IP addresses.  Bits in
       these masks that are set to 0 indicate the bit positions to be ignored during  comparisons
       of  IP  addresses.  So, specifying 255.255.255.255 in the mask demands an exact match with
       the specified IP address field, whereas 0.0.0.0 in the mask causes a match no matter  what
       IP  address  is  specified.   The contents of the mask fields are ignore, though they must
       still be supplied (use 0.0.0.0), if domain names are used for  the  corresponding  address
       fields.  If  the  domain  name  starts  with a period, it specifies a zone and matches all
       domain names within that zone, otherwise it matches  only  the  domain  name  itself.  For
       example,  xyz.com  matches only xyz.com, while .xyz.com matches not only xyz.com, but also
       abc.xyz.com and this.and.that.xyz.com, among others. The special symbol ALL (which must be
       entirely in uppercase) matches everything. Domain names are otherwise case-insensitive.

       If the dst_addr dst_mask pair is omitted, the line applies to all destination hosts.

       The  op  field  must be eq, neq, lt, gt, le, or ge, for the condition of equal, not equal,
       less than, greater than, less than or equal, and greater than or equal, respectively.  The
       dst_port  field  can  be either a port number, e.g., 23, or the equivalent service name as
       specified in the file /etc/services, e.g., telnet for port number  23.  If  this  pair  is
       omitted, the line applies to all services, i.e., all destination port numbers.

       For example, consider the line

        permit *=root,clivep 128.103.4.10 255.255.255.255 179.200.20.0 255.255.255.0 le 1023

       To  match  the  conditions  indicated  in this line, a request must come from a user named
       'root' or 'clivep' on the host whose IP address is 128.103.4.10 exactly,  the  destination
       host  must  have  179.200.20  in  the  first  three bytes of its IP address (the last byte
       doesn't matter), and the service must use a port number less than or equal to 1023 on  the
       destination host. Since the action field is permit, such requests will be granted.

       When  a request is received by sockd, it checks against the lines in file /etc/sockd.conf,
       one line at a time. Once it finds a line with conditions that are matched by the  request,
       the  request  is  either  granted  or  denied  based on the action field of that line. The
       remaining lines of file /etc/sockd.conf are skipped. If no matching line is found  in  the
       entire file, the request is denied.

       Be  very careful how you order the lines in file /etc/sockd.conf.  The following two lines
       in the indicated order

        deny *=abxyz   128.140.13.24  0.0.0.0
        permit         128.140.13.24  0.0.0.0

       disallow all requests by user 'abxyz' from host 128.140.13.24, but allow all  requests  by
       other  users  from  the  same host. Switch the order of the two lines and even requests by
       user 'abxyz' are granted.

       The shell_cmd field specifies a command string that is executed  when  the  conditions  on
       that  line are satisfied. The following substitutions occur before the string is presented
       to the Borne shell for execution:

        %A -- replaced by the client host's domainname if known, by its IP address otherwise
        %a -- replaced by the client host's IP address
        %c -- replaced by "connect" or "bind", the command sockd is asked to execute
        %p -- replaced by the process id of sockd
        %S -- replaced by the service name (e.g., ftp) if known, by the destination port number otherwise
        %s -- replaced by the destination port number
        %U -- replaced by the user-id reported by identd
        %u -- replaced by the user-id reported by the client program
        %Z -- replaced by the destination host's domainname if known, by its IP address otherwise
        %z -- replaced by the destination host's IP address
        %% -- replaced by a single %

       Several shell commands can be strung together in the usual way. For example,

        /usr/ucb/finger @%A | /usr/ucb/mail -s 'SOCKS: rejected %u@%A to %Z (%S)' root root@%A

       will finger the client host and pipe the result into an email message  for  superusers  at
       the  server  host  and  the  client host with an appropriate Subject line. Most often this
       feature is used with a deny line, but it can be used with permit also.

       Although there is an implied 'deny all' at the end of  the  configuration  file,  you  may
       supply  one  explicitly  so as to take some specific action when requests are so rejected,
       e.g., (in one continuous line),

        deny 0.0.0.0 0.0.0.0 : /usr/ucb/finger @%A |
         /usr/ucb/mail -s 'SOCKS: rejected %u@%A to %Z (%S)' root root@%A

       You may also specify in /etc/sockd.conf commands to be executed when sockd cannot  connect
       to  client's  identd or when the user-ids reported by the client programs and the client's
       identd do not match.  These special entries must have #NO_IDENTD: and #BAD_ID: at the very
       beginning of the line, followed by the shell commands to be executed. For example:

        #NO_IDENTD: /usr/ucb/mail -s 'Please run identd on host %A' root@%A
        #BAD_ID: finger @%A | /usr/ucb/mail -s '%U pretends to be %u on %A' root root@%A

       Strictly  speaking,  sockd  has  no  concept  of inside/outside, it does know which is the
       requesting host and which the destination and that is the basis  of  its  access  control.
       Therefore  it  can  be  used  to  facilitate  access from outside world into your internal
       networks as well. Needless to say, you have to take extreme caution if you  choose  to  do
       so.  If  you  don't need that kind of access, it is recommended that you specifically deny
       such connections in sockd.conf. For example, if the Class  B  IP  network  129.1  is  your
       internal network, use

        deny 0.0.0.0  0.0.0.0    129.1.0.0  255.255.0.0

       as  the  first  line  of your sockd.conf to protect your inside hosts from all attempts of
       access from the outside world through SOCKS.  If your internal network consists of several
       IP  networks, you have to use one such line for each of them. In that case, it may be more
       convenient to use domain name instead, for instance,

        deny    0.0.0.0  0.0.0.0        .myowm.com  0.0.0.0

       or

        deny    ALL  0.0.0.0        .myown.com  0.0.0.0

       may be used, assuming that myown.com is your domain.

       Though the use of domain names can  be  very  convenient  and  can  also  reduce  start-up
       overhead  by  reducing  the  number of lines in the configuration file, you should be very
       careful with your DNS (Domain Name System) setup.  Here are some details that  you  should
       know.

       The  original information the SOCKS server has of the source or the destination host is in
       the form of its IP address. The SOCKS server does a reverse DNS lookup to find the  domain
       name  correspodning to that IP address. It then does a normal DNS loopkup to translate the
       domain name back to an IP address.  If the  two  IP  addresses  match,  the  SOCKS  server
       retains  both  the  domain name and the IP address as identifier of the host, and will use
       whichever as appropriate when it checkes the configuration file.  If either of the two DNS
       lookups  fails  or  if  the  two  IP addresses do not match, SOCKS server retains only the
       original IP address as the only identifier of the host, with the consequence that it  will
       not  match  any  line  in the configuration file which specifies a domain name (other than
       ALL) in the corresponding address field.

       Suppose now you add a new host to your internal network before updating your  nameserver's
       data  with  both  the  A record and the PTR record of the new host.  When the SOCKS server
       receives a request with the IP address of the new host as its destination, at least one of
       the  DNS  lookups  will fail.  Consequently it will not be protected by lines in which the
       domain name is used in the destination address field.

       So, if you want to use domain name in the configuration file, be very sure that you always
       keep  your  DNS  information up-to-date. It's probably a good idea to update your DNS data
       before adding a new host to your network. Also make sure that  your  SOCKS  server  always
       queries a nameserver which has the most up-to-date information of your internal network.

       You  have  the  option  of  using  the  frozen configuration file /etc/sockd.fc instead of
       /etc/sockd.conf. The frozen file is  produced  by  make_sockdfc  and  is  essentially  the
       memeory  image of the parsed configuration file. Using it can reduce the start-up delay of
       the SOCKS server since it eliminates the need for parsing.

       When the SOCKS server starts, it always looks  for  the  frozen  configuration  first  and
       reverts   to  the  unfrozen  version  only  if  no  frozen  configuration  is  found.  All
       modifications to the configuration must be done on the plain-text, unfrozen file. Be  sure
       that you run make_sockdfc every time after you modify /etc/sockd.conf or your SOCKS server
       would be using the frozen version of an older configuration.

SEE ALSO

       dump_sockdfc(8), make_sockdfc(8), sockd(8), socks.conf(5), sockd.fc(5),

                                           May 6, 1996                              SOCKD.CONF(5)