socks.conf(5)



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)




Free and Open Source Software


Free Software Video

Useful Programs

Free Online Courses

Open Opportunity

Open Business