Re: syslog idea

[Fred_Kuhns () npg wustl edu (Fred Kuhns)]

John LaCour writes:
> [The hobbit sez...]
>
> > This brought to mind the idea of a "syslog monitor", or a process that would 
> > just hang out someplace and stat the various log files periodically,
> > using some mechanism to warn of excessive size, mysterious shrinkage, and 
> > maybe some other warning signs.
>
> While you're at it, lets write a program to monitor the syslog monitor.  In case
> any one kills it, sends it signals, its pid changes, etc.
>
> Another idea is to find out how the intruders are getting in (or getting root) 
> and plugging those holes.
 
Perhaps I'm missing something, but isn't this the point?  
Or, maybe my concerns are different since I'm at a University.  
Anyway, if someone does break in then wouldn't log files provide you
with clues as to how and when?  Armed with this info you could then
work at plugging the holes.  So, the question is, what's the best way
to safeguard these log files?  A secure log host, filter log messages
based on space left on disk, forward interesting messages (what ever
this may be) someplace else like to a printer, filter based on who
(host, program) sent the log message.  The goal would be to both get
rid of nonsense messages generated by an attacker, and safeguard the
real messages that show his/her activities.

> If you're really concerned about intruders messing with your files, use tripwire
> or something like that.  Of course, tripwire may not be ideal for dynamic files 
> like pacct and lastlog, but alas your binaries are more important than your 
> logs.

Yes, binaries should be monitored by tripwire ... I also agree that
tripwire is not the best tool for monitoring logfiles.  You would have to
have tripwire check it quite often (checking for monotonically increasing)
to have any sort of confidence in the results.

fred
--