Provided by: socks4-clients_4.3.beta2-20_amd64 bug

NAME

       socks.conf - SOCKS clients configuration file

SYNOPSIS

       /etc/socks.conf

DESCRIPTION

       All  SOCKS  client  programs  use  this  file  to determine whether to use direct or proxy
       connection to a given  destination  host,  and  to  exert  access  control  based  on  the
       destination  host,  the  requested  service (port number on the destination host), and the
       effective user-id of the requesting local user. If this file is absent, SOCKS clients will
       only try direct connections, making them behave like their regular counterparts.

       Each  line  in  the  file  may be up to 1024 characters long.  Lines starting with a # are
       comments. Non-comment lines must be of one of the three forms:

       deny [*=userlist]   dst_addr  dst_mask  [op dst_port]  [: shell_cmd]
       direct    [*=userlist]   dst_addr  dst_mask  [op dst_port]  [: shell_cmd]
       sockd     [@=serverlist] [*=userlist]  dst_addr  dst_mask  [op dst_port]  [: shell_cmd]

       A deny line tells the SOCKS clients when to reject a request.  A direct lines  tells  when
       to  use  a  direct  connection. A sockd line indicates when to use a proxy connection and,
       optionally, which SOCKS proxy server or servers it should try.

       Spaces and tabs separate the fields. Fields enclosed in square brackets are optional.

       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 local 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  dst_addr  field  specifies either the IP address of a host, a network, or a subnet in
       the usual dotted form, e.g., 129.201.4.0, or a doamin name, e.g.,  internic.net.  dst_mask
       specifies  mask  for  the IP address used in dst_addr.  Bits in dst_mask that are set to 0
       indicate the bit positions to be ignored during comparison of IP addresses. So, specifying
       255.255.255.255  in  dst_mask  demands  an  exact  match with dst_addr, whereas 0.0.0.0 in
       dst_mask causes a matching with any  given  destination  address  regardless  of  what  is
       specified  for  dst_addr.  If a domain name is used for dst_addr, the contents of dst_mask
       are ignored, though it must still be supplied (simply use 0.0.0.0).  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.comP,   while   .xyz.com   macthes   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-insentive.

       When  using  a  domain  name in dst_addr, you have be very careful in maintaining your DNS
       setup. See the last few paragraphs in sockd.conf(5).

       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 file /etc/services, e.g., telnet for port number 23. If this pair is omitted,
       the line applies to all services.

       The serverlist, which may only be used in a sockd line, consists  of  one  or  more  SOCKS
       proxy  servers,  which  the  client program should try to use (in the indicated order) for
       establishing a proxy connection.  Only commas can be used as separator, no spaces or  tabs
       are allowed in the list. Domain names of the servers may be used in the list, though it is
       probably more prudent to specify IP addresses.  If  this  field  is  omitted,  the  client
       program  will  use  the default SOCKS proxy server, which is determined by the environment
       variable SOCKS_SERVER if it exists, or the name compiled into  the  SOCKS  client  program
       otherwise.

       Consider

       sockd  @=1.2.3.4  *=boss,root 11.12.13.14 255.255.255.255 eq telnet

       To match the condition indicated in this line, a request must come from a local user whose
       effective id is either boss or root,  the  destination  IP  address  must  be  11.12.13.14
       exactly,  and  the  service  requested  must  be  telnet. In that case, connection to host
       11.12.13.14 should be done via a SOCKS proxy server on host 1.2.3.4.

       Every time a SOCKS client has to make a network connection, it checks the pending  request
       against the file /etc/socks.conf, one line at a time. Once it finds a line with conditions
       that are matched by the request, the action specified on that line is taken. The remaining
       lines  of  file  /etc/socks.conf  are  skipped.  So  the order of the lines in the file is
       extremely important; switch two lines and you may have entirely different results.  If  no
       matching line is found throughout the file, the request is denied.

       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"
        %p -- replaced by the process id of the client program
        %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 at login
        %u -- replaced by the effective user-id
        %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 with `|', `;', etc.

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

        deny 0.0.0.0 0.0.0.0 : /usr/ucb/mail -s 'SOCKS: rejected %S from %u to %Z' root

       Unlike the previous version, connection to address 127.0.0.1 or  0.0.0.0  is  always  done
       directly to localhost, so there is no need to specify either of them in /etc/socks.conf.

       You have the option of using the frozen file /etc/socks.fc instead of /etc/socks.conf. The
       frozen file is produced by make_socksfc and is essentially the memory image of the  parsed
       configuration  file.  using it can reduced the start-up delay of SOCKS client applications
       since  no  parsing  is  needed.  Because  SOCKS  client  applications  always   look   for
       /etc/socks.fc  first, be sure that you always run make_socksfc every time after you modify
       /etc/socks.conf.

ENVIRONMENT

       SOCKS_SERVER, if defined, specifies the name or IP address of the SOCKS proxy server  host
       to use, overriding the default server compiled into the programs.

SEE ALSO

       dump_socksfc(8), make_socksfc(8), sockd(8), sockd.conf(5), socks_clients(1), socks.fc(5)

                                           May 6, 1996                              SOCKS.CONF(5)