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  des-
       tination  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.

       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_md]

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

       Spaces and tabs separate the fields.  Fields  enclosed  in
       sqaure 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  destina-
       tion 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  sepa-
       rators.  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 dst_mask pair together specify  the  destina-
       tion  IP address or the range of destination IP addresses.
       They are both  given  in  the  usual  dotted  form,  e.g.,
       129.1.2.3. Bits in dst_mask that are set to 0 indicate the
       bit positions which should be masked off  (i.e.,  ignored)
       during  comparison  of dst_addr and the actual destination
       IP address.  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 an address match no matter what is  speci-
       fied  for  dst_addr.  (NOTE: This is the same way netmasks
       are interpreted, but is the direct  opposite  of  how  the
       address masks are used in cisco router's access-lists.)

       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, respec-
       tively.  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 deter-
       mined 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  detination  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 connec-
       tion, 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 (localhost) is always done directly, so there is
       no need to specify that in /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.


SOCKS_CLIENTS(1)                                 SOCKS_CLIENTS(1)


NAME
       rfinger - SOCKS client version of finger
       rftp - SOCKS client version of ftp

SYNOPSIS
       See   ftp(1),  telnet(1),

DESCRIPTION
       These programs provide the well-known  functionalities  to
       hosts within a firewall. Normally, when a firewall is con-
       structed, IP-accessibility across the firewall is cut  off
       to reduce security risk to hosts within the firewall. As a
       result, inside hosts can no longer use many of  the  well-
       known  tools  directly to access the resources outside the
       firewall.

       These programs restore the convenience of  the  well-known
       tools  while  maintaining the security requirement. Though
       the programs differ very much from their  counterparts  in
       the  use  of  the communication scheme, they should behave
       almost indistinguishably to the users.  Note  though  that
       rftp  does  echo the password as you type it in if you are
       using anonymous as log-in name. Unlike those of the previ-
       ous  versions, these are "versatile" clinets, meaning that
       they can be used for connections to inside hosts  directly
       and  to outside hosts via SOCKS proxy servers. So they can
       be used as replacements of their traditional counterparts.

       When any of these programs starts, it prints to stderr its
       version number and the name or IP address of  its  default
       SOCKS  proxy  server.   It then consults the configuration
       file /etc/socks.conf to determine whether a request should
       be  allowed  or  denied  based on the requesting user, the
       destination host, and the requested service. For allowable
       requests,  the  configuration  file  also dictates whether
       direct or proxy connection should be  used  to  the  given
       destination,  and  optionally  the actual SOCKS servers to
       use for the proxy connection.  See socks.conf(5).

       You can use environment variable SOCKS_NS to set the name-
       server  for domainname resolutions. Be sure you use the IP
       address of the nameserver you want to use, not its domain-
       name. If SOCKS_NS doesn't exist, the IP address defined by
       the symbol SOCKS_DEFAULT_NS at compile time is used if the
       programs were compiled with that symbol defined. Otherwise
       the nameservers specified in /etc/resolv.conf are used.

       All the client programs uses syslog with  facility  daemon
       and level notice to log their activities.  

SOCKS_CLIENTS(1)                                 SOCKS_CLIENTS(1)


       Typical lines look like

        Apr 11 10:02:23 eon rfinger[631]: connect() from don(don) to abc.com (finger) using sockd at socksserv
        May 10 08:39:07 eon rftp[603]: connect() directly from blue(blue) to xyz.edu (ftp)
        May 10 08:39:09 eon rftp[603]: bind() directly from blue(blue) for xyz.edu (ftp)
        May 18 13:31:19 eon rtelnet[830]: connect() from root(jon) to xyz.edu (telnet) using sockd at sockd2
        May 18 14:51:19 eon rtelnet[921]: refused -- connect() from jon(jon) to xyz.edu (telnet)

       Of the two user-ids appearing in each log line, the  first
       is  the effective user-id when the program is invoked, the
       second (that within the parentheses) is the  one  used  at
       login. Access control applies to the effective user-ids.

SEE ALSO
       ftp(1), telnet(1)

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.

       SOCKS_NS, if defined, specify the IP address of the domain
       nameserver that should be used for name resolution,  over-
       riding  both the definition of symbol SOCKS_DEFAULT_NS and
       the file /etc/resolv.conf.

       ORIG_FINGER, if  defined,  specified  the  (altered)  full
       pathname of the original finger program, which should have
       been renamed before installing the rfinger as the  regular
       finger.  The  rfinger  program invokes the original finger
       program to lookup information on  local  users.   Normally
       this name should be compiled directly into rfinger, avoid-
       ing  the  need  for   this   environment   variable.   Use
       ORIG_FINGERFR  only  if  you want to override what is com-
       piled into rfinger.

AUTHOR
       David Koblas, koblas@netcom.com
       Ying-Da Lee, ylee@syl.dl.nec.com
