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