*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->HP-UX 11i man pages -> hosts_access (5)              
Title
Content
Arch
Section
 

Contents


 hosts_access(5)                                             hosts_access(5)




 NAME    [Toc]    [Back]
      hosts_access - format of host access control files

 DESCRIPTION    [Toc]    [Back]
      The access control facility for internet services uses access control
      files to grant or deny access to its services.  These files are
      defined using a simple access control language based on client (host
      name/address, user name) and server (process name, hostname/address)
      patterns.  See the EXAMPLES section for a quick introduction.

      An extended version of the access control language is described in
      hosts_options(5).

    Access Control Files    [Toc]    [Back]
      daemon is the the process name of a network daemon process, and client
      is the name and/or address of a host requesting service.  Network
      daemon process names are specified in the inetd configuration file
      (/etc/inetd.conf).  The access control software searches the contents
      of two files: /etc/hosts.allow and /etc/hosts.deny.

      The files are searched in the following order.  The search stops with
      the first match:

           +  /etc/hosts.allow file is checked first for a matching (daemon,
              client) pair.  If one is found, access is granted and the
              search stops.

           +  /etc/hosts.deny file is checked if no match was found in the
              /etc/hosts.allow file and access will be denied if a (daemon,
              client) pair match is found.

           +  If no (daemon, client) match was found in either access
              control file, access will be granted.

      A non-existing access control file is treated as if it were an empty
      file.  Thus, access control can be turned off by providing no access
      control files.

    Access Control Rules    [Toc]    [Back]
      Each access control file consists of zero or more lines of text.
      These lines are processed in order of appearance.  The search
      terminates when a match is found.  The following points describe the
      format of the access control file:

           +  A newline character is ignored when it is preceded by a
              backslash ("\").  This permits you to break up long lines so
              that they are easier to edit.

           +  Blank lines or lines that begin with a # character are
              ignored.  This permits you to insert comments and whitespace
              so that the tables are easier to read.



 Hewlett-Packard Company            - 1 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




           +  All other lines should be in the following format.  Contents
              in between [] square brackets are optional:

              daemon_list : client_list [ : shell_command ]

              daemon_list    is a list of one or more daemon process names
                             (argv[0] values) or wildcards (see below).

              client_list    is a list of one or more host names, host
                             addresses, patterns or wildcards (see below)
                             that will be matched against the client host
                             name or address.  NOTE:  An IPv6 address should
                             be enclosed in square brackets [] without any
                             whitespace.

      The more complex forms daemon@host and user@host are explained in the
      Server Endpoint Patterns and Client Username Lookups sections
      respectively.

      List elements must be separated by blanks and/or commas.

      With the exception of NIS (YP) netgroup lookups, all access control
      checks are case-insensitive.

    Patterns    [Toc]    [Back]
      The access control language implements the following patterns:

           +  A string that begins with a dot (.) character specifies to
              match the components after the dot.  A host name is matched if
              the last components of its name match the specified pattern.
              For example, the pattern .xyz.com matches the host name
              abc.def.xyz.com.

           +  A string that ends with a dot (.) character specifies to match
              the components before the dot.  A host address is matched if
              its first numeric fields match the given string.  For example,
              the pattern 192.3.  matches the address of (almost) every host
              (192.3.x.x) on the 192.3 network.

           +  A string that begins with an at (@) character is treated as an
              NIS (formerly YP) netgroup name.  A host name is matched if it
              is a host member of the specified netgroup.  Netgroup matches
              are not supported for daemon process names or for client user
              names.

           +  An expression of the form n.n.n.n/m.m.m.m is interpreted as a
              "net/mask" pair.  A host address is matched if "net" is equal
              to the bit-wise AND of the address and the "mask".  For
              example, the net/mask pattern 131.155.72.0/255.255.254.0
              matches every address in the range 131.155.72.0 through
              131.155.73.255.



 Hewlett-Packard Company            - 2 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




           +  An expression of the form [IPv6_address/prefix_length] is
              interpreted as an IPv6 network prefix.  A host address is
              matched if the value of prefix_length bits in IPv6_address and
              the host address are equal.  For example, the pattern
              [3ffe::1111:1234/120] matches every address in the range
              3ffe::1111:0 through 3ffe::1111:ffff.

    Wildcards    [Toc]    [Back]
      The access control language supports explicit wildcards.  They are:

      ALL            The universal wildcard, always matches.

      LOCAL          Matches any host whose name does not contain a dot
                     character.

      UNKNOWN        Matches any user whose name is unknown, and matches any
                     host whose name or address is unknown.  This pattern
                     should be used with care; host names may be unavailable
                     due to temporary name server problems.  A network
                     address will be unavailable when the software cannot
                     figure out what type of network it is talking to.

      KNOWN          Matches any user whose name is known, and matches any
                     host whose name and addresses are known.  This pattern
                     should be used with care; host names may be unavailable
                     due to temporary name server problems.  A network
                     address will be unavailable when the software cannot
                     figure out what type of network it is talking to.

      PARANOID       Matches any host whose name does not match its address.
                     If the configuration parameter, on_reverselookup_fail
                     in /etc/tcpd.conf, is set to deny, tcpd drops requests
                     from such clients even before looking at the access
                     control tables.

    Operators    [Toc]    [Back]
      The access control language supports the following operator:

      EXCEPT         The format of using this operator is as follows:

                     list_1 EXCEPT list_2

      This construct matches anything that matches list_1, provided it does
      not match list_2.  The EXCEPT operator can be used in daemon_lists and
      client_lists.  The EXCEPT operator can be nested.  If the control
      language permits the use of parentheses, "a EXCEPT b EXCEPT c" parses
      as "(a EXCEPT (b EXCEPT c))" .

    Shell Commands    [Toc]    [Back]
      If the first-matched access control rule contains a shell command, the
      command is subjected to %letter expansions (see next section).  The



 Hewlett-Packard Company            - 3 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




      result is executed by a /bin/sh child process with standard input,
      output, and error connected to /dev/null.  Specify an ampersand (&) at
      the end of the command if you do not want to wait until the command
      has completed.

      Shell commands should not rely on the PATH setting of inetd.  Instead,
      they should use absolute path names or begin with an explicit
      PATH=whatever statement.

      The hosts_options(5) manual page describes the access control language
      that uses the shell command field.

    % Expansions
      The following expansions are available within shell commands:

      %a(%A)    The client (server) host address.

      %c        Client information: user@host, user@address, a host name, or
                just an address, depending on how much information is
                available.

      %d        The daemon process name (argv[0] value).

      %h(%H)    The client (server) host name or address, if the host name
                is not available.

      %n(%N)    The client (server) host name (or unknown or paranoid).

      %p        The daemon process id.

      %s        Server information: daemon@host, daemon@address, or just a
                daemon name, depending on how much information is available.

      %u        The client user name (or unknown).

      %%        Expands to a single % character.

      Characters in % expansions that do not match any alpha-numeric (A-Za-
      z0-9) or !@%-_=+:,./ characters are replaced by underscores.

    Server Endpoint Patterns    [Toc]    [Back]
      In order to distinguish clients by the network address that they
      connect to, use patterns of the form:

           process_name@host_pattern:client_list...

      Patterns like these can be used when the machine has different
      Internet addresses with different Internet hostnames.  Service
      providers can use this facility to offer FTP, GOPHER or WWW archives
      with Internet names that may even belong to different organizations.
      See also the twist option in hosts_options(5).  Some systems can have



 Hewlett-Packard Company            - 4 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




      more than one Internet address on one physical interface.  With other
      systems you may have to resort to SLIP or PPP pseudo interfaces that
      live in a dedicated network address space.

      The host_pattern conforms to the same syntax rules as host names and
      addresses in client_list context.  Usually, server endpoint
      information is available only with connection-oriented services.

    Client Username Lookup    [Toc]    [Back]
      When the client host supports the RFC 931 protocol or one of its
      descendants (TAP, IDENT, RFC 1413), the wrapper programs can retrieve
      additional information about the owner of a connection.  The client
      username information, when available, is logged together with the
      client host name and can be used to match patterns like:

           daemon_list:...  user_pattern@host_pattern...

      The daemon wrappers can be configured (in /etc/tcpd.conf) at run time
      to perform rule-driven username lookups (default) or to always
      interrogate the client host.  In the case of rule-driven username
      lookups, the above rule would cause username lookup only when both the
      daemon_list and the host_pattern match.

      A user pattern has the same syntax as a daemon process pattern, so the
      same wildcards apply (netgroup membership is not supported).  Username
      lookup needs to be evaluated carefully because of the following
      limitations:

           +  The client username information cannot be trusted when it is
              needed most, i.e. when the client system has been compromised.
              In general, ALL and (UN)KNOWN are the only user name patterns
              that make sense.

           +  Username lookups are possible only with TCP-based services,
              and only when the client host runs a suitable daemon.  In all
              other cases the result is "unknown".

           +  Username lookups may cause noticeable delays for non-UNIX
              users.  The timeout value for username lookups is configurable
              through /etc/tcpd.conf.  See the tcpd.conf(4) for more
              information.

      Selective username lookups can alleviate the last problem.  For
      example, a rule like:

           daemon_list : @pcnetgroup ALL@ALL

      would match members of the pc netgroup without doing username lookups,
      but would perform username lookups with all other systems.





 Hewlett-Packard Company            - 5 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




    Detecting Address Spoofing Attacks    [Toc]    [Back]
      A flaw in the sequence number generator of many TCP/IP implementations
      allows intruders to easily impersonate trusted hosts and to break in
      via; for example, the remote shell service.  The IDENT (RFC931 etc.)
      service can be used to detect such and other host address spoofing
      attacks.

      Before accepting a client request, the wrappers can use the IDENT
      service to find out that the client did not send the request at all.
      When the client host provides IDENT service, a negative IDENT lookup
      result (the client matches UNKNOWN@host) is a strong evidence of
      host-spoofing attack.

      A positive IDENT lookup result (the client matches KNOWN@host) is less
      reliable.  It is possible for an intruder to spoof both the client
      connection and the IDENT lookup, although doing so is much harder than
      spoofing just a client connection.  It may also be possible that the
      client's IDENT server is lying.

      NOTE: IDENT lookups do not work with UDP services.

 EXAMPLES    [Toc]    [Back]
      The language is flexible enough that different types of access control
      policy can be expressed with a minimum of effort.  Although the
      language uses two access control tables, the most common policies can
      be implemented with one of the tables being trivial or even empty.

      When reading the examples below, it is important to realize that the
      allow table is scanned before the deny table.  The search terminates
      when a match is found, and access is granted when no match is found at
      all.

      The examples use host and domain names.  They can be improved by
      including address and/or network/netmask information to reduce the
      impact of temporary name server lookup failures.

    Mostly Closed Access Control    [Toc]    [Back]
      In this example, access is denied by default.  Only explicitly
      authorized hosts are permitted access.

      The default policy (no access) is implemented with a trivial deny
      file:

                /etc/hosts.deny:
                    ALL: ALL

      This denies all services to all the hosts unless they are permitted
      access by entries in the allow file.

      The explicitly authorized hosts are listed in the allow file. For
      example:



 Hewlett-Packard Company            - 6 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




                /etc/hosts.allow:
                    ALL: LOCAL @some_netgroup
                    ALL: .foobar.edu EXCEPT terminalserver.foobar.edu

      The first rule permits access from hosts in the local domain (there is
      no dot "." in the host name) and from members of the some_netgroup
      netgroup.  The second rule permits access from all hosts in the
      foobar.edu domain (notice the leading dot "." in .foobar.edu), with
      the exception of terminalserver.foobar.edu.

    Mostly Open Access Control    [Toc]    [Back]
      Here, access is granted by default.  Only explicitly specified hosts
      are refused service.

      The default policy (access granted) makes the allow file redundant so
      that it can be omitted.  The explicitly non-authorized hosts are
      listed in the deny file.  For example:

                /etc/hosts.deny:
                    ALL: some.host.name, .some.domain
                    ALL EXCEPT fingerd: other.host.name, .other.domain

      The first rule denies some hosts and domains all services.  The second
      rule still permits finger requests from other hosts and domains.

    Setting Traps    [Toc]    [Back]
      The next example permits tftp requests from hosts in the local domain
      (notice the leading dot).  Requests from any other hosts are denied
      and instead of the requested file, a finger probe is sent to the
      offending host.  The result is mailed to the superuser.

           /etc/hosts.allow:
               tftpd: LOCAL, .my.domain

           /etc/hosts.deny:
               tftpd: ALL: spawn (/usr/bin/sffinger -l @%h | \
                        /usr/bin/mailx -s %d-%h root) &

      The sffinger command comes with tcp wrappers.  It limits possible
      damage from data sent by the remote finger server.  It gives better
      protection than the standard finger command.

      The expansion of the %h (client host) and %d (service name) sequences
      is described earlier in the "Shell Commands" section.

      WARNING: Do not set traps on your finger daemon, unless you are
      prepared for infinite finger loops.

      Service trapping can be especially useful on network firewall systems.
      The typical network firewall only provides a limited set of services
      to the outer world.  All other services can be trapped just like the



 Hewlett-Packard Company            - 7 -   HP-UX 11i Version 2: August 2003






 hosts_access(5)                                             hosts_access(5)




      above tftp example.  The result is an excellent early-warning system.

 DIAGNOSTICS    [Toc]    [Back]
      Problems are reported via syslogd, the syslog daemon, at info, notice,
      warning and err levels.  An error is reported in the following cases:

           +  When a syntax error is found in a host access control rule,

           +  When the length of an access control rule exceeds the capacity
              of an internal buffer,

           +  When an access control rule is not terminated by a newline
              character,

           +  When the result of %letter expansion would overflow an
              internal buffer,

           +  When a system call fails that should not.

 WARNINGS    [Toc]    [Back]
      If a name server lookup times out, the host name will not be available
      to the access control software, even though the host is registered.

      Domain name server lookups are not case-sensitive. NIS (formerly YP)
      netgroup lookups are case-sensitive.

 AUTHOR    [Toc]    [Back]
      Wietse Venema (wietse@wzv.win.tue.nl)
      Department of Mathematics and Computing Science
      Eindhoven University of Technology
      Den Dolech 2, P.O. Box 513,
      5600 MB Eindhoven, The Netherlands

 FILES    [Toc]    [Back]
      /etc/hosts.allow         (daemon,client) pairs that are granted
                               access.

      /etc/hosts.deny          (daemon,client) pairs that are denied access.

 SEE ALSO    [Toc]    [Back]
      tcpd(1M) TCP/IP daemon wrapper program.

      tcpdchk(1) and tcpdmatch(1) test programs.

      tryfrom(1) and sffinger(1) TCP Wrapper utility programs.


 Hewlett-Packard Company            - 8 -   HP-UX 11i Version 2: August 2003
[ Back ]
      
      
 Similar pages
Name OS Title
hosts.allow OpenBSD tcp wrapper format of host access control files
hosts.deny OpenBSD tcp wrapper format of host access control files
hosts_access OpenBSD tcp wrapper format of host access control files
hosts_options HP-UX host access control language extensions
hosts_options Linux host access control language extensions
hosts_options FreeBSD host access control language extensions
hosts_options OpenBSD tcp wrapper host access control language extensions
maclabel FreeBSD Mandatory Access Control label format
.rhosts HP-UX security files authorizing access by remote hosts and users on local host
hosts.equiv HP-UX security files authorizing access by remote hosts and users on local host
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service