hosts_access man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

hosts_access(5)						       hosts_access(5)

       hosts_access - format of host access control files

       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 section for a quick introduction.

       An  extended  version  of  the  access control language is described in

   Access Control Files
       is the process name of a network daemon process, and is the name and/or
       address of a host requesting service.  Network daemon process names are
       specified  in  the  configuration  file	The  access  control  software
       searches the contents of two files: and

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

	      ·	 file is checked first for a matching (daemon,	client)	 pair.
		 If one is found, access is granted and the search stops.

	      ·	 file  is checked if no match was found in the file and access
		 will be denied if a (daemon, client) pair match is found.

	      ·	 If no (daemon, client) match was found in either access  con‐
		 trol 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
       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 back‐
		 slash ("\").  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.

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

		 daemon_list	is  a list of one or more daemon process names
				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 and are explained in the and sections respec‐

       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.

       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 matches the host name

	      ·	 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	 exam‐
		 ple,  the  pattern matches the address of (almost) every host
		 (192.3.x.x) on the 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  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 matches every address in the range through

	      ·	 An  expression	 of the form is interpreted as an IPv6 network
		 prefix.  A host address is  matched  if  the  value  of  pre‐
		 fix_length  bits  in  IPv6_address  and  the host address are
		 equal.	 For example, the pattern matches every address in the
		 range through

       The access control language supports explicit wildcards.	 They are:

       The universal wildcard, always matches.

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

       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.

       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	tempo‐
		      rary  name  server  problems.  A network address will be
		      unavailable when the software  cannot  figure  out  what
		      type of network it is talking to.

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

       The access control language supports the following operator:

       The format of using this operator is as follows:

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

   Shell Commands
       If the first-matched access control rule contains a shell command,  the
       command	is  subjected to expansions (see next section).	 The result is
       executed by a child process with standard input, output, and error con‐
       nected  to 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	Instead,  they
       should use absolute path names or begin with an explicit

       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:

       The client (server) host address.

       Client information:
		 a host name, or just an address, depending on how much infor‐
		 mation is available.

       The daemon process name

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

       The client (server) host name (or

       The daemon process id.

       Server information:
		 or  just  a daemon name, depending on how much information is

       The client user name (or

       Expands to a single % character.

       Characters in % expansions that do not match any alpha-numeric or char‐
       acters are replaced by underscores.

   Server Endpoint Patterns
       In  order  to distinguish clients by the network address that they con‐
       nect to, use patterns of the form:

       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 option
       in hosts_options(5).  Some systems can  have  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  net‐
       work 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
       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:

       The  daemon wrappers can be configured (in 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 limita‐

	      ·	 The client username information cannot be trusted when it  is
		 needed	 most,	i.e.  when  the client system has been compro‐
		 mised.	 In general, and 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  config‐
		 urable through See the tcpd.conf(4) for more information.

       Selective  username  lookups can alleviate the last problem.  For exam‐
       ple, a rule like:

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

   Detecting Address Spoofing Attacks
       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

       Before  accepting a client request, the wrappers can use the IDENT ser‐
       vice 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 is a strong evidence of host-spoofing attack.

       A positive IDENT lookup result (the client matches  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.

       The language is flexible enough that different types of access  control
       policy  can  be	expressed with a minimum of effort.  Although the lan‐
       guage 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

       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
       In this example, access is denied by default.  Only  explicitly	autho‐
       rized hosts are permitted access.

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

       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 exam‐

       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 domain
       (notice	the  leading  dot  "."	in  with  the  exception   of	termi‐

   Mostly Open Access Control
       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:

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

   Setting Traps
       The  next  example  permits  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 probe is sent to the offending host.
       The result is mailed to the superuser.

       The command comes with wrappers.	 It limits possible damage  from  data
       sent  by	 the remote server.  It gives better protection than the stan‐
       dard command.

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

       WARNING:	 Do  not set traps on your daemon, unless you are prepared for
       infinite 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 above
       tftp example.  The result is an excellent early-warning system.

       Problems	 are  reported	via  the  daemon,  at and 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	capac‐
		 ity of an internal buffer,

	      ·	 When  an  access  control rule is not terminated by a newline

	      ·	 When the result of expansion would overflow an internal  buf‐

	      ·	 When a system call fails that should not.

       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.

       Wietse Venema (
       Department of Mathematics and Computing Science
       Eindhoven University of Technology
       Den Dolech 2, P.O. Box 513,
       5600 MB Eindhoven, The Netherlands

       (daemon,client) pairs that are granted access.

       (daemon,client) pairs that are denied access.

       tcpd(1M) TCP/IP daemon wrapper program.

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

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


List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net