sockd.conf(5)


NAME

   sockd.conf - SOCKS server configuration file

SYNOPSIS

   /etc/sockd.conf

DESCRIPTION

   The  file  /etc/sockd.conf  is  used  to  control access to SOCKS proxy
   server sockd and its services. (See sockd(8).)  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.  A line in
   /etc/sockd.conf can be up to  1023  characters  long.   Each  line  may
   contain the following fields in the indicated order:

    action   [?=use_identd]   [*=userlist]   src_addr  src_mask  [dst_addr
    dst_mask] [op dst_port] [ : shell_cmd ]

   Spaces and tabs separate the fields. Fields enclosed in square brackets
   are optional. Blank lines are allowed. Except for lines that start with
   #NO_IDENTD: or #BAD_ID:, everything from the first appearance of  #  to
   the  end  of  the  line is considered comment and thus ignored by sockd
   during normal validation.

   The action field must be either permit or deny and indicates the action
   to be taken if a request matches the conditions specified in that line.

   The  use_identd field, when present, must be I, i, or n, and is used to
   specify whether identd verification should be employed for the  current
   line.  ?=I demands the use of identd for verifying the user's identity,
   denying access if connection to client's identd fails or if the  result
   does  not  match  the  user-id reported by the client program. ?=i also
   specifies the use of identd, but denies access only if client's  identd
   reports  a  user-id  different from what the client program claims. ?=n
   turns off the use of identd. For the line in  which  these  fields  are
   used,  they  override the global identd setting, which is determined by
   options -I and -i on the sockd command line.

   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  requesting  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  src_addr and dst_addr fields either specify IP addresses of hosts,
   networks, or subnets in the usual dotted form, e.g., 129.201.4.0, or  a
   domain  name, e.g., internic.net.  The src_mask and dst_mask fields are
   masks for the corresponding IP addresses.  Bits in these masks that are
   set to 0 indicate the bit positions to be ignored during comparisons of
   IP addresses.  So, specifying 255.255.255.255 in the  mask  demands  an
   exact match with the specified IP address field, whereas 0.0.0.0 in the
   mask causes a match no  matter  what  IP  address  is  specified.   The
   contents  of  the  mask  fields  are  ignore, though they must still be
   supplied (use 0.0.0.0), if domain names are used for the  corresponding
   address fields. 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.com, while .xyz.com matches 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-insensitive.

   If  the  dst_addr  dst_mask  pair  is  omitted, the line applies to all
   destination hosts.

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

   For example, consider the line

    permit   *=root,clivep   128.103.4.10   255.255.255.255   179.200.20.0
    255.255.255.0 le 1023

   To  match  the  conditions  indicated in this line, a request must come
   from a user named 'root' or 'clivep' on the host whose  IP  address  is
   128.103.4.10  exactly, the destination host must have 179.200.20 in the
   first three bytes of its IP address (the last byte doesn't matter), and
   the  service  must  use a port number less than or equal to 1023 on the
   destination host. Since the action field is permit, such requests  will
   be granted.

   When  a  request  is  received by sockd, it checks against the lines in
   file /etc/sockd.conf, one line at a time. Once it  finds  a  line  with
   conditions  that  are  matched  by  the  request, the request is either
   granted or denied based on the action field of that line. The remaining
   lines of file /etc/sockd.conf are skipped. If no matching line is found
   in the entire file, the request is denied.

   Be very careful how you order the lines in file  /etc/sockd.conf.   The
   following two lines in the indicated order

    deny *=abxyz   128.140.13.24  0.0.0.0
    permit         128.140.13.24  0.0.0.0

   disallow  all  requests  by  user  'abxyz' from host 128.140.13.24, but
   allow all requests by other users from the same host. Switch the  order
   of the two lines and even requests by user 'abxyz' are granted.

   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", the command sockd is asked to execute
    %p -- replaced by the process id of sockd
    %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 reported by identd
    %u -- replaced by the user-id reported by the client program
    %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. For
   example,

    /usr/ucb/finger @%A | /usr/ucb/mail -s 'SOCKS: rejected %u@%A to %Z (%S)' root root@%A

   will finger the client host and pipe the result into an  email  message
   for  superusers  at  the  server  host  and  the  client  host  with an
   appropriate Subject line. Most often this feature is used with  a  deny
   line, but it can be used with permit also.

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

    deny 0.0.0.0 0.0.0.0 : /usr/ucb/finger @%A |
     /usr/ucb/mail -s 'SOCKS: rejected %u@%A to %Z (%S)' root root@%A

   You  may  also  specify in /etc/sockd.conf commands to be executed when
   sockd cannot connect to client's identd or when the  user-ids  reported
   by  the  client  programs  and the client's identd do not match.  These
   special  entries  must  have  #NO_IDENTD:  and  #BAD_ID:  at  the  very
   beginning  of  the line, followed by the shell commands to be executed.
   For example:

    #NO_IDENTD: /usr/ucb/mail -s 'Please run identd on host %A' root@%A
    #BAD_ID: finger @%A | /usr/ucb/mail -s '%U pretends to be %u on %A' root root@%A

   Strictly speaking, sockd has no concept of inside/outside, it does know
   which  is the requesting host and which the destination and that is the
   basis of its access control. Therefore it can  be  used  to  facilitate
   access from outside world into your internal networks as well. Needless
   to say, you have to take extreme caution if you choose to do so. If you
   don't need that kind of access, it is recommended that you specifically
   deny such connections in sockd.conf. For example, if  the  Class  B  IP
   network 129.1 is your internal network, use

    deny 0.0.0.0  0.0.0.0    129.1.0.0  255.255.0.0

   as  the first line of your sockd.conf to protect your inside hosts from
   all attempts of access from the outside world through SOCKS.   If  your
   internal  network  consists of several IP networks, you have to use one
   such line for each of them. In that case, it may be more convenient  to
   use domain name instead, for instance,

    deny    0.0.0.0  0.0.0.0        .myowm.com  0.0.0.0

   or

    deny    ALL  0.0.0.0        .myown.com  0.0.0.0

   may be used, assuming that myown.com is your domain.

   Though  the  use  of  domain  names can be very convenient and can also
   reduce start-up overhead  by  reducing  the  number  of  lines  in  the
   configuration  file,  you  should be very careful with your DNS (Domain
   Name System) setup.  Here are some details that you should know.

   The original information the SOCKS server has  of  the  source  or  the
   destination  host  is  in  the form of its IP address. The SOCKS server
   does a reverse DNS lookup to find the domain name correspodning to that
   IP  address.  It then does a normal DNS loopkup to translate the domain
   name back to an IP address.  If the two IP addresses match,  the  SOCKS
   server retains both the domain name and the IP address as identifier of
   the host, and will use whichever as appropriate  when  it  checkes  the
   configuration  file.   If either of the two DNS lookups fails or if the
   two IP addresses do not match, SOCKS server retains only  the  original
   IP  address  as  the  only identifier of the host, with the consequence
   that it will not  match  any  line  in  the  configuration  file  which
   specifies  a  domain name (other than ALL) in the corresponding address
   field.

   Suppose now you add a new host to your internal network before updating
   your nameserver's data with both the A record and the PTR record of the
   new host.  When the SOCKS server receives a request with the IP address
   of  the  new  host  as its destination, at least one of the DNS lookups
   will fail.  Consequently it will not be protected by lines in which the
   domain name is used in the destination address field.

   So,  if  you want to use domain name in the configuration file, be very
   sure that  you  always  keep  your  DNS  information  up-to-date.  It's
   probably  a  good idea to update your DNS data before adding a new host
   to your network. Also make sure that your SOCKS server always queries a
   nameserver  which  has the most up-to-date information of your internal
   network.

   You  have  the  option  of  using   the   frozen   configuration   file
   /etc/sockd.fc  instead  of /etc/sockd.conf. The frozen file is produced
   by make_sockdfc and is essentially the  memeory  image  of  the  parsed
   configuration file. Using it can reduce the start-up delay of the SOCKS
   server since it eliminates the need for parsing.

   When  the  SOCKS  server  starts,  it  always  looks  for  the   frozen
   configuration  first  and  reverts  to  the unfrozen version only if no
   frozen configuration is found. All modifications to  the  configuration
   must  be  done  on  the plain-text, unfrozen file. Be sure that you run
   make_sockdfc every time after you modify /etc/sockd.conf or your  SOCKS
   server would be using the frozen version of an older configuration.

SEE ALSO

   dump_sockdfc(8), make_sockdfc(8), sockd(8), socks.conf(5), sockd.fc(5),

                              May 6, 1996                    SOCKD.CONF(5)





Opportunity


Personal Opportunity - Free software gives you access to billions of dollars of software at no cost. Use this software for your business, personal use or to develop a profitable skill. Access to source code provides access to a level of capabilities/information that companies protect though copyrights. Open source is a core component of the Internet and it is available to you. Leverage the billions of dollars in resources and capabilities to build a career, establish a business or change the world. The potential is endless for those who understand the opportunity.

Business Opportunity - Goldman Sachs, IBM and countless large corporations are leveraging open source to reduce costs, develop products and increase their bottom lines. Learn what these companies know about open source and how open source can give you the advantage.





Free Software


Free Software provides computer programs and capabilities at no cost but more importantly, it provides the freedom to run, edit, contribute to, and share the software. The importance of free software is a matter of access, not price. Software at no cost is a benefit but ownership rights to the software and source code is far more significant.


Free Office Software - The Libre Office suite provides top desktop productivity tools for free. This includes, a word processor, spreadsheet, presentation engine, drawing and flowcharting, database and math applications. Libre Office is available for Linux or Windows.





Free Books


The Free Books Library is a collection of thousands of the most popular public domain books in an online readable format. The collection includes great classical literature and more recent works where the U.S. copyright has expired. These books are yours to read and use without restrictions.


Source Code - Want to change a program or know how it works? Open Source provides the source code for its programs so that anyone can use, modify or learn how to write those programs themselves. Visit the GNU source code repositories to download the source.





Education


Study at Harvard, Stanford or MIT - Open edX provides free online courses from Harvard, MIT, Columbia, UC Berkeley and other top Universities. Hundreds of courses for almost all major subjects and course levels. Open edx also offers some paid courses and selected certifications.


Linux Manual Pages - A man or manual page is a form of software documentation found on Linux/Unix operating systems. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.