Misleading security message output

[Joel]

I'm just a newb, but 

> > > I had an interesting experience, this morning. The nightly
> > > security message from a CVS server machine that runs a version
> > > of FreeBSD-4 had arrived, and it claimed that someone who hadn't
> > > done any work for us for some considerable time had had three
> > > failed login attempts, late that night.  Curious.
> > >
> > > After much hunting around, and checking perimeter logs, it
> > > turned out that nothing of the sort had happened.  The security
> > > log script had been fooled by the age of the messages.0.gz file,
> > > which contained messages from more than a year ago. 

The first question that comes to mind: do you really need logs from a
year back? 

Even though you say the server hardly ever needs touching, it seems to
me that general backup principles would say that if you need logs that
old, you would have your automatic backup sript gleaning the old logs at
one to three months, putting the old logs on some backup medium and
deleting them from the server.

> > > The search
> > > pattern "$yesterday" doesn't contain a year, because log file
> > > timestamps don't contain years.  The log file was so old because
> > > rotation is determined by size, and this machine simply doesn't
> > > have much to log, despite being used daily.  It never goes down,
> > > and is basically completely stable.

Something seems upside down here. Maybe it's just the way I'm reading it.

Anyway, as Joshua pointed out, you can combine conditions:

> > Well, you could modify /etc/newsyslog.conf, where it says:
> > 
> > /var/log/messages                       600  14    100  *     J
> > 
> > change it to:
> > 
> > /var/log/messages                       600  14    *    @T00  J
> > 
> > This assumes you want 14 message logs, rotated once a day at midnight. 
> > Any message logs over 14 days will be deleted.
> > 
> > man newsyslog.conf
> > 
> > > This could be avoided, perhaps, with a NetBSD-style backup/diff
> > > mechanism, or (incompatibly) with daemontools/multilog-style
> > > 64-bit time stamps in the log files.  It can be worked-around
> > > by forcing faster log-file rotations, now that I know about
> > > the problem.  I can't think of a really good widely-applicable
> > > solution, using the existing framework, though.
> > 
> > I'm not quite sure what you mean. Do you want a way to have the 
> > timestamp record the year as well, so that you can keep the default 
> > setting?
> 
> That'd be one way to do it.  Multilog, in the daemontools
> package gives log messages a timestamp that (implicitly)
> includes the date.  The NetBSD method, of keeping a "yesterday"
> backup of the log files, and diffing against the "now" versions
> avoids the problem by making the search for "stuff that happened
> since the last log e-mail" explicit.  I don't much mind how the
> bug is fixed.  It would be nice, I think, if the bug fix didn't
> amount to a documentation addition along the lines of "in order
> for the nightly security messages to work properly, you must
> tune the log-file rotation period so that log files are rotated
> at least once per year.  See newsyslog.conf(5)."
> 
> A reasonable bug-fix could be to add a when value of $ML to the
> /var/log/messages line of the default /etc/newsyslog.conf.  On
> most machines that will have no effect, because rotation will
> still be triggered by the size field.  It will just make the
> logic in the nightly security script correct.

Maybe it's because I'm such a newb, but I'm wondering which program has
what bug? Is it that the default configuration files for the login logs
doesn't put on age limit on the rotation? Is it that the log lines don't
conain a full 4-digit year in the timestamp? Or is it that the
logscraper doesn't know to check the age of a log file, or doesn't know
to work on the tail of the log?

--
Joel Rees   <rees at ddcom.co.jp>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **