SUMMARY: hosts.deny

From: Carole Thompson <carole_at_robles.callutheran.edu>
Date: Wed, 24 Sep 1997 09:57:34 -0700

> My hosts.deny file, containing 43 lines of hosts&domains, refuses some
> hosts, but not all hosts listed in the file. There are no > errors or warnings written to the log.
> It seems that the hosts at the top of the file are
> refused, but not those farther down.

Regarding hosts.deny, I have not exactly found the reason for the 37
line cutoff, but there are things to do which have helped, eliminated
errors, and increased the number of refused services to 'undesirables'.
The first part of this summary contains general suggestions by a number
of persons. The second part contains specific reference to the syntax
which the hosts.allow and hosts.deny file should/can contain.
(Regarding my second question in the original post, e.g., anti-hacker
techniques, I will post a separate summary.)

First, be careful how the hacker source is entered into the hosts.deny
file. If too specific, the hacker can change the machine name and come
in again. Thus, if xxx.xxx.jps.net hacks, I've found it's better to put
.jps.net into the ALL: section of the hosts.deny file. That way, one
restricts the entire site. (I'm not too concerned about denying service
to the entire site, but this may be an issue depending on the kind of
users one needs to permit in.)

In general, allow service to specific sites/domains by putting an entry
in the hosts.allow file, and then deny everyone else with an entry "ALL"
in the hosts.deny file, e.g., for fingerd, I decided to allow only
finger requests from my domain, and deny the rest of the world, thus

hosts.allow contains
fingerd: .callutheran.edu 199.107

While hosts.deny contains
fingerd:ALL:DENY

I did the same for ftpd, but for other services like rlogind and rshd, I
just denied all! On the whole, the more restrictive the better. As
soon as tcp_wrappers finds a match, it stops looking further. As it
checks the .allow file first, any entry there takes precedence.

To discover errors which hosts.allow or hosts.deny may contain, run

tcpdchk -v

it will report errors and warnings from both the .allow and .deny file,
and other problems. Also, this will check and report line length
problems.


Another option is good enough to quote directly:

If you have compiled tcpd with the -DPROCESS_OPTIONS to enable the
extended language in host_options(5) you can place all your access
rules in hosts.allow and modify the syslog facility and level.

# _at_(#) hosts.allow
ALL: verybadhost.domain : severity auth.alert : DENY :
ALL: host.domain : DENY :
ALL: ALL : ALLOW

(And add one line to hosts.deny "ALL:ALL:DENY"

If you don't intend to use commands, then this syntax can be simplified:

1) Since you are not doing anything with shell commands (see manpage
[for hosts_access]) I would simplify the format from
      ALL : \
      host.domain .domain \
      domain host.domain \
      :
   to
      ALL : \
      host.domain .domain

Many thanks to:
george_at_esa.nascom.nasa.gov (G. Dimitoglou)
Becki Kain <beckers_at_josephus.furph.com>
Carlos A M dos Santos <casantos_at_urano.cpmet.ufpel.tche.br>
"Christopher J. Tengi" <tengi_at_CS.Princeton.EDU>
Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com>
James Sainsbury <sainsb_j_at_shrub.chem.su.oz.au>
Mark Gelinas USG <gelinas_at_zk3.dec.com>
Received on Wed Sep 24 1997 - 19:25:44 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:36 NZDT