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