Provided by: socks4-server_4.3.beta2-14ubuntu2_i386 bug

NAME

       sockd - Internet firewall secure socket server (proxy server)

SYNOPSIS

       sockd [ -ver | -i | -I ]

DESCRIPTION

       sockd   is  an  internet  secure  socket server, often referred to as a
       proxy server. It was designed  primarily  to  provide  hosts  within  a
       firewall access to resources outside of the firewall.

       Normally,  hosts  inside  a  firewall  has  no  IP-accessibility to the
       network outside of  the  firewall.  This  reduces  the  risk  of  being
       intruded  by  unauthorized  people  from  the  Internet. Unfortunately,
       without IP-accessibility users on the inside hosts can  no  longer  use
       many  of the important tools such as telnet, ftp, xgopher, Mosaic, etc.
       to access the tremendous resources available in the Internet.

       With sockd installed on a server host, users on the other inside  hosts
       can  gain  back  the  lost  functionalities  by  using clients programs
       designed to work with sockd proxy server,  e.g,  rtelnet  in  place  of
       telnet,  rftp  in  place of ftp, rfinger in place of finger, etc. Since
       these client programs  work  like  their  normal  counterparts  without
       requiring  direct  IP-connectivity  to the Internet, convenience to the
       users is accomplished without breaching the security. The  server  host
       that  runs sockd does have to be open to the Internet, and it therefore
       requires special attention to make sure that it is secure.

       A configuration file /etc/sockd.fc  (or  /etc/sockd.conf)  is  used  to
       control  access  to  sockd and its services. 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.  (See  sockd.conf(5)  and
       sockd.fc(5).)

       If  the  server host is multi-homed, i.e., having more than one network
       interface and with its IP_FORWARDING turned off, and the server support
       RBIND operation, then it must run a multi-homed version of sockd, which
       requires another control file /etc/sockd.fr  (or  /etc/sockd.route)  to
       decide  which  interface to use for connection to any given destination
       host. See sockd.route(5) and sockd.fr(5). A multi-homed  sockd  can  be
       run  on  a single-homed host as well if necessary; you just have to set
       up /etc/sockd.route to direct all traffic through the  host’s  one  and
       only network interface.

       sockd  uses  syslog  with  facility  daemon and level notice to log its
       activities and errors. Typical lines look like

        Apr 11 08:51:29 eon sockd[636]: connected -- Connect from don(don)@abc.edu to wxy.com (telnet)
        Apr 11 09:24:59 eon sockd[636]: terminated -- Connect from don(don)@abc.edu to wxy.com (telnet)
        Apr 11 09:24:59 eon sockd[636]: 1048 bytes from abc.edu, 285143 bytes from wxy.com
        Jun 22 18:24:54 eon sockd[884]: refused -- Connect from sam(unknown)@big.com to small.com (ftp)

       In these lines, the first user-id is the one  reported  by  the  client
       program, the second one (within the parentheses) is what is reported by
       identd on the client host.  These log  lines  usually  appear  in  file
       /var/adm/messages   though   that   can   be   changed   by   modifying
       /etc/syslog.conf. (See syslogd(8) and syslog.conf(5).)

       If you allow access to infosystems such as Gopher or WWW, you should be
       aware  that  they  by nature would tend to get connections to hosts all
       over the world and would use not only Gopher and WWW ports but possibly
       also  ports  for  finger,  telnet,  ftp,  nntp,  etc.  as  well as non-
       privileged ports ( > 1023).

       For  a  stand-alone  sockd,  /etc/sockd.fc  (or  /etc/sockd.conf)   and
       /etc/sockd.fr  (or  /etc/sockd.route),  if  required, are only read and
       parsed once at the beginning of program execution. If  you  change  the
       contents  of either file and want to make the running sockd use the new
       contents, you must send a SIGHUP signal to the running  sockd  process.
       Sending  a  running  stand-alone  sockd  a  SIGUSR1 signal causes it to
       record  on  the  systems’s  log  file   the   effective   contents   of
       configuration and route files that it is currently using.  You can find
       the process id of the stand-alone sockd in /etc/sockd.pid.

       Rather than using plain-text  configuration  file  /etc/sockd.conf  and
       route  file  /etc/sockd.route,  sockd  now  looks for the corresponding
       frozen files /etc/sockd.fc  and  /etc/sockd.fr  first.  The  plain-text
       files  are  used  only if the corresponding frozen files are not found.
       Use commands make_sockdfc and make_sockdfr to produce the frosen files.
       Use  commands  dump_sockdfc and dump_sockdfr to examine the contents of
       frozen files. (See make_sockdfc(8),  make_sockdfr(8),  dump_sockdfc(8),
       and  dump_sockdfr(8).)  Using  frozen configuration and route files can
       save a lot of overhead at start-up of sockd.

OPTIONS

       The options are mutually exclusive and thus may only be used one  at  a
       time.

       ver    With  this  option,  sockd  prints  its  own version number, the
              version number of the SOCKS protocol, whether it is  SOCKSified,
              whether  it  is  a standalone daemon or must be run under inetd,
              whether it support RBIND, and whether a route file is  required.

       I      Use  identd  (RFC  1413) to verify the requester’s user-id. Deny
              access if connection to client’s identd fails or if  the  result
              does  not  match  the  user-id  reported  by the client program.
              Client hosts without a properly installed identd daemon will not
              be  served.  User verification is done before and in addition to
              the normal  access  control.  This  can  be  overridden  in  the
              sockd.conf file on a line by line basis.

       i      Similar  to  -I  but  more  lenient.  Access  is  denied only if
              client’s identd reports a user-id that’s different from what the
              client  program claims. This can be overridden in the sockd.conf
              file on a line by line basis.

       Log entries similar to the following are produced upon failure of user-
       id verification:

        Apr 15 14:42:51 eon sockd[729]: cannot connect to identd on big.edu
        Apr 15 14:42:51 eon sockd[729]: refused -- Connect from bob(unknown)@big.edu to xyz.com (ftp)
        Jul 15 12:23:06 eon sockd[832]: *Alert*: real user is sam, not jim
        Jul 15 12:23:06 eon sockd[832]: refused -- Connect from jim(sam)@abc.org to bad.place.com (WWW)

FILES

       /etc/sockd.fc,    /etc/sockd.conf,   /etc/sockd.fr,   /etc/sockd.route,
       /etc/inetd.conf, /etc/services, /var/adm/messages, /etc/syslog.conf

SEE ALSO

       socks_clients(1),   sockd.conf(5),    sockd.route(5),    socks.conf(5),
       make_sockdfc(8), make_sockdfr(8), dump_sockdfc(8), dump_sockdfr(8)

AUTHOR

       David Koblas, koblas@sgi.com
       Ying-Da Lee, ylee@syl.dl.nec.com
       David Mischel, dm@kansas.gene.com

                                 June 6, 1996                         SOCKD(8)