[ On Sunday, December 12, 1999 at 23:44:03 (-0700), Louis Glassy wrote: ]
> Subject: Time-windows for /etc/hosts.allow ?
>
> Suppose you could put time-windows on an entry in 
> hosts.allow.  Do you think this would give any 
> practical security benefit?

Why bother?

> If having time-windows on hosts.allow makes sense, I can already
> do this by having a cron job rewrite the hosts.allow
> as needed.  This has the advantage of not requiring any
> changes to userland proper.  :-)

Exactly.  Nothing caches any of the contents of /etc/hosts.{allow,deny}.
Just move the appropriate entries into place on a schedule controlled by
cron.  You can do this from one master file, generating hosts.* on a
regular basis, or keep separate files by time period.

The problem with doing anything at all to hosts.* is that wiggling its
implementation is likely going to be more of a hassle and potential
source of bugs than you might expect at first glance.

What really needs to be done is to re-write TCP Wrappers from the ground
up, and most especially provide a much better API to it with decent
error reporting and handling capabilities.  I've made one small change
to TCP Wrappers (the RBL patch, which is apparently widely used, and is
already in NetBSD), and I can tell you from experience that hacking TCP
Wrappers is not fun, nor was it much fun integrating it into a mailer
(smail) because of the sparseness and oddities of the API.  The config
file format itself has been extended at least once in a major way (see
hosts_options(5)) and it is indeed intended to be extensible (your
proposal would mostly fit right in though I'd suggest being explicit
with a keyword), but I'm not comfortable with the design, and I'm
definitely uncomfortable with the implementation of the parser.

As Wietse himself has explained many times in several forums the problem
with a security tool like TCP Wrappers is the number and complexity of
features it offers.  The more there are, the buggier it gets, and most
importantly of all the more the users get confused and make serious
configuration mistakes which end up actually reducing their security
instead of increasing it.

> So.. question 1.  Do you think there is any practical security benefit
>                   to be had from time-windowing the access to a host?

Nope, not likely.  Remember the "Net" is global and not all the good
guys are logged on at the same time, nor are all the bad guys busy
between 1am and 4am Eastern Standard Time, or even 1am and 4am PST.
In addition there's no sense in using fixed time periods to control the
availability of services if what you're really trying to do is to turn
them off when you're not actually sitting there watching the system like
a hawk.  If you're really that worried about it then you should just
power it down when you're not using it!  ;-)  [Not that watching a
system like a hawk really reduces the risk of attack...  just the mean
time to repair!  ;-)]

>      question 2.  If there is, is it better to do this with cron,
>                   or by changing libwrap to read new (optional)
> 		  timespecs from the hosts.allow file? 

See above!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>