hosts_access man page on BSDOS

Man page or keyword search:  
man Server   6284 pages
apropos Keyword Search (all sections)
Output format
BSDOS logo
[printable version]



HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

NAME
       hosts_access - format of host access control files

DESCRIPTION
       This  manual  page  describes a simple access control lan-
       guage that is based on  client  (host  name/address,  user
       name),  and  server (process name, host name/address) pat-
       terns.  Examples are  given  at	the  end.  The	impatient
       reader is encouraged to skip to the EXAMPLES section for a
       quick introduction.

       An extended version of  the  access  control  language  is
       described in the hosts_options(5) document. The extensions
       are turned on at	 program  build	 time  by  building  with
       -DPROCESS_OPTIONS.

       In the following text, 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 pro-
       cess names are specified in the inetd configuration  file.

ACCESS CONTROL FILES
       The access control software consults two files. The search
       stops at the first match:

       o      Access will be granted when a (daemon,client)  pair
	      matches an entry in the /etc/hosts.allow file.

       o      Otherwise,  access  will	be  denied  when  a (dae-
	      mon,client)  pair	  matches   an	 entry	 in   the
	      /etc/hosts.deny file.

       o      Otherwise, 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.

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

       o      Blank  lines or lines that begin with a `#' charac-
	      ter are ignored.	This permits you to  insert  com-
	      ments  and whitespace so that the tables are easier
	      to read.

       o      All other lines should satisfy the  following  for-
	      mat, things between [] being optional:

								1

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

		 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.

       The more	 complex  forms	 daemon@host  and  user@host  are
       explained  in the sections on server endpoint patterns and
       on client username lookups, respectively.

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

       If  the	delimiter (:) needs to be part of either list, it
       must either be escaped with a backslash, or the list  must
       be enclosed in double quotes.

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

PATTERNS
       The access control language implements the following  pat-
       terns:

       o      A	 string	 that begins with a `.' character. A host
	      name is matched if the last components of its  name
	      match the specified pattern.  For example, the pat-
	      tern    `.tue.nl'	   matches    the    host    name
	      `wzv.win.tue.nl'.

       o      A	 string	 that  begins  with  an	 `@' 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  sup-
	      ported  for daemon process names or for client user
	      names.

       o      A CIDR style network address, expressed in the form
	      `net/masklen'.   A  host	address is matched if the
	      first `masklen'  bits  of	 the  `net'  and  address
	      match.   Note  that  numeric IPv6 addresses must be
	      escaped or enclosed in double quotes to keep the	:
	      separator	 from being treated as a field delimiter.

       o      A string that ends with a	 `.'  character.  A  host
	      address  is  matched  if	its  first numeric fields
	      match the given string.  For example,  the  pattern
	      `131.155.'  matches  the	address of (almost) every
	      host   on	  the	Eindhoven   University	  network
	      (131.155.x.x).	This   is  only	 valid	for  IPv4
	      addresses.

								2

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

       o      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 bitwise 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'.	 This  is  only	 valid	for  IPv4
	      addresses.

WILDCARDS
       The access control language supports explicit wildcards:

       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 are 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 address 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.	  When	tcpd  is  built	 with  -DPARANOID
	      (default mode), it drops requests from such clients
	      even  before  looking at the access control tables.
	      Build without -DPARANOID when you want more control
	      over such requests.

OPERATORS
       EXCEPT Intended	 use  is  of  the  form:  `list_1  EXCEPT
	      list_2';	this  construct	 matches  anything   that
	      matches  list_1  unless  it  matches  list_2.   The
	      EXCEPT operator can be used in daemon_lists and  in
	      client_lists. The EXCEPT operator can be nested: if
	      the control language would permit the use of paren-
	      theses,  `a  EXCEPT  b EXCEPT c' would parse as `(a
	      EXCEPT (b EXCEPT c))'.

								3

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

SHELL COMMANDS
       If the first-matched access control rule contains a  shell
       command,	 that command is subjected to %<letter> substitu-
       tions (see next section).  The result  is  executed  by	a
       /bin/sh	child  process	with  standard	input, output and
       error connected to /dev/null.  Specify an `&' at	 the  end
       of  the	command	 if  you do not want to wait until it has
       completed.

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

       The  hosts_options(5)  document	describes  an alternative
       language that uses the shell command field in a	different
       and incompatible way.

% EXPANSIONS
       The  following  expansions are available within shell com-
       mands:

       %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 unavailable.

       %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 informa-
	      tion is available.

       %u     The client user name (or "unknown").

       %%     Expands to a single `%' character.

       Characters in % expansions that may confuse the shell  are
       replaced by underscores.

SERVER ENDPOINT PATTERNS
       In  order  to  distinguish  clients by the network address

								4

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

       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  dif-
       ferent  internet	 addresses  with different internet host-
       names.  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 the hosts_options(5) document. Some sys-
       tems (Solaris, FreeBSD) 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 network address space.

       The host_pattern obeys the same syntax rules as host names
       and addresses in client_list context. Usually, server end-
       point  information  is available only with connection-ori-
       ented services.

CLIENT USERNAME LOOKUP
       When the client host supports the RFC 931 protocol or  one
       of its descendants (TAP, IDENT, RFC 1413) the wrapper pro-
       grams can retrieve additional information about the  owner
       of  a connection. Client username information, when avail-
       able, 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 at compile 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  user-
       name  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).  One should not get carried  away  with
       username lookups, though.

       o      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.

       o      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".

       o      A well-known UNIX kernel	bug  may  cause	 loss  of

								5

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

	      service  when  username  lookups	are  blocked by a
	      firewall. The wrapper README document  describes	a
	      procedure	 to find out if your kernel has this bug.

       o      Username lookups may cause  noticeable  delays  for
	      non-UNIX	users.	 The default timeout for username
	      lookups is 10 seconds: too short to cope with  slow
	      networks, but long enough to irritate PC users.

       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 user-
       name  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
       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  strong  evidence  of  a host
       spoofing attack.

       A  positive  IDENT  lookup  result  (the	 client	  matches
       `KNOWN@host')  is  less trustworthy. 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 that the client's
       IDENT server is lying.

       Note: IDENT lookups don't work with UDP services.

EXAMPLES
       The  language  is  flexible enough that different types of
       access control policy can be expressed with a  minimum  of
       fuss.  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,
       that the search terminates when a match is found, and that
       access is granted when no match is found at all.

								6

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

       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
       In this case, access is denied by default. Only explicitly
       authorized hosts are permitted access.

       The default policy (no access) is implemented with a triv-
       ial deny file:

       /etc/hosts.deny:
	  ALL: ALL

       This denies all service to all hosts, unless they are per-
       mitted access by entries in the allow file.

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

       /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 (no `.' 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  lead-
       ing dot), with the exception of terminalserver.foobar.edu.

MOSTLY OPEN
       Here, access is granted by default; only explicitly speci-
       fied 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 in.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.

BOOBY TRAPS
       The next example permits tftp requests from hosts  in  the
       local  domain (notice the leading dot).	Requests from any
       other hosts are denied.	Instead of the requested file,	a
       finger  probe is sent to the offending host. The result is
       mailed to the superuser.

								7

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

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

       /etc/hosts.deny:
	  in.tftpd: ALL: (/some/where/safe_finger -l @%h | \
	       /usr/ucb/mail -s %d-%h root) &

       The safe_finger command comes with the  tcpd  wrapper  and
       should  be installed in a suitable place. It limits possi-
       ble 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 in the section on shell com-
       mands.

       Warning: do not booby-trap your finger daemon, unless  you
       are prepared for infinite finger loops.

       On network firewall systems this trick can be carried even
       further.	 The typical network  firewall	only  provides	a
       limited set of services to the outer world. All other ser-
       vices can be "bugged" just like the  above  tftp	 example.
       The result is an excellent early-warning system.

DIAGNOSTICS
       An  error  is  reported	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
       shouldn't.   All problems are reported via the syslog dae-
       mon.

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

SEE ALSO
       tcpd(8) tcp/ip daemon wrapper program.
       tcpdchk(8), tcpdmatch(8), test programs.

BUGS
       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 case insensitive; NIS (for-
       merly YP) netgroup lookups are case sensitive.

AUTHOR
       Wietse Venema (wietse@wzv.win.tue.nl)
       Department of Mathematics and Computing Science

								8

HOSTS_ACCESS(5)					  HOSTS_ACCESS(5)

       Eindhoven University of Technology
       Den Dolech 2, P.O. Box 513,
       5600 MB Eindhoven, The Netherlands

								9

[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server BSDOS

List of man pages available for BSDOS

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]
Tweet
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