Ferramentas do usuário

Ferramentas do site


espec:man-host-access

Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

Link para esta página de comparações

Próxima revisão
Revisão anterior
espec:man-host-access [2008/06/19 16:40]
maziero created
espec:man-host-access [2008/06/19 16:42] (atual)
maziero
Linha 1: Linha 1:
 +** mudar para português**
  
 +<​code>​
 +HOSTS_ACCESS(5) ​                                               HOSTS_ACCESS(5)
 +
 +NAME
 +       ​hosts_access - format of host access control files
 +
 +DESCRIPTION
 +       ​This ​ manual ​ page  describes ​ a simple access control language that is
 +       based on client (host name/​address,​ user  name), ​ and  server ​ (process
 +       ​name, ​ host name/​address) patterns. ​ 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 dae-
 +       mon process, and client is the name and/or address of a host requesting
 +       ​service. ​ Network ​ daemon process names are specified in the inetd con-
 +       ​figuration 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  (daemon,​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 back-
 +              slash 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  `#' character are
 +              ignored. ​ This permits you to insert comments and whitespace ​ so
 +              that the tables are easier to read.
 +
 +       ​o ​     All  other  lines  should ​ satisfy ​ the following format, things
 +              between [] being optional:
 +
 +                 ​daemon_list : client_list [ : shell_command ]
 +
 +       ​daemon_list is a list of one or more daemon process names (argv[0] val-
 +       ues) or wildcards (see below).
 +
 +       ​client_list ​ is  a list of one or more host names, host addresses, pat-
 +       terns 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.
 +
 +       ​With ​ the  exception ​ of  NIS (YP) netgroup lookups, all access control
 +       ​checks are case insensitive.
 +
 +PATTERNS
 +       The access control language implements the following patterns:
 +
 +       ​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 pattern `.tue.nl' ​ matches ​ the  host
 +              name `wzv.win.tue.nl'​.
 +
 +       ​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).
 +
 +       ​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
 +              supported for daemon process names or for client user names.
 +
 +       ​o ​     An  expression of the form `n.n.n.n/​m.m.m.m'​ is interpreted as a
 +              `net/​mask'​ pair. An IPv4 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'​.
 +
 +       ​o ​     An expression of the form `[n:​n:​n:​n:​n:​n:​n:​n]/​m' ​ is  interpreted
 +              as  a `[net]/​prefixlen'​ pair. An IPv6 host address is matched if
 +              `prefixlen'​ bits of `net' is equal to the  `prefixlen' ​ bits  of
 +              the   ​address. ​  ​For ​  ​example, ​  ​the ​  ​[net]/​prefixlen ​ pattern
 +              `[3ffe:​505:​2:​1::​]/​64' ​ matches ​ every  address ​ in   ​the ​  range
 +              `3ffe:​505:​2:​1::'​ through `3ffe:​505:​2:​1:​ffff:​ffff:​ffff:​ffff'​.
 +
 +       ​o ​     A  string ​ that begins with a `/' character is treated as a file
 +              name. A host name or address is matched if it matches ​ any  host
 +              name  or address pattern listed in the named file. The file for-
 +              mat is zero or more lines with zero or more host name or address
 +              patterns ​ separated ​ by  whitespace. ​ A file name pattern can be
 +              used anywhere a host name or address pattern can be used.
 +
 +       ​o ​     Wildcards `*' and `?' can be  used  to  match  hostnames ​ or  IP
 +              addresses. ​  ​This ​ method of matching cannot be used in conjunc-
 +              tion with `net/​mask'​ matching, hostname matching beginning ​ with
 +              `.' or IP address matching ending with `.'.
 +
 +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 soft-
 +              ware 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  con-
 +              struct ​ 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 parentheses,​ `a EXCEPT b EXCEPT
 +              c' would parse as `(a EXCEPT (b EXCEPT c))'.
 +
 +SHELL COMMANDS
 +       If the first-matched access control rule contains a shell command, that
 +       ​command is subjected to %<​letter> ​ substitutions ​ (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 statement.
 +
 +       ​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 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
 +              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 dae-
 +              mon name, depending on how much information 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 that they con-
 +       nect 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  the  hosts_options(5) ​ document. ​ Some  systems ​  ​(Solaris,​
 +       ​FreeBSD) can have more than one internet address on one physical inter-
 +       face; 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 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. 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 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 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). ​  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  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 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
 +       ​attacks.
 +
 +       ​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 `UNKNOWN@host'​) is strong evidence of a host spoof-
 +       ing 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  imple-
 +       ​mented 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 ​ termi-
 +       ​nates ​ when  a match is found, and that access is granted when no match
 +       is found at all.
 +
 +       The examples use host and domain names. They can be improved by includ-
 +       ing 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 trivial deny file:
 +
 +       /​etc/​hosts.deny:​
 +          ALL: ALL
 +
 +       This denies all service to all hosts, unless they are permitted ​ 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  leading ​ dot),  with the exception of terminalserver.foo-
 +       ​bar.edu.
 +
 +MOSTLY OPEN
 +       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 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.
 +
 +       /​etc/​hosts.allow:​
 +          in.tftpd: LOCAL, .my.domain
 +
 +       /​etc/​hosts.deny:​
 +          in.tftpd: ALL: spawn (/​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 possible damage from data sent
 +       by the remote finger server. ​ It gives better protection than the stan-
 +       dard finger command.
 +
 +       The expansion of the %h (client host) and %d (service ​ name)  sequences
 +       is described in the section on shell commands.
 +
 +       ​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 services 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 con-
 +       trol rule; when the length of an access control rule exceeds the capac-
 +       ​ity ​ of  an  internal buffer; when an access control rule is not termi-
 +       nated 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 daemon.
 +
 +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 (formerly YP) net-
 +       group lookups are case sensitive.
 +
 +AUTHOR
 +       ​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
 +
 +                                                               ​HOSTS_ACCESS(5)
 +</​code>​