Provided by: socks4-server_4.3.beta2-18_i386 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)