[Aide] Reporting log files

Marc Haber mh+aide at zugschlus.de
Sun Mar 18 23:39:01 EET 2007


On Tue, Feb 06, 2007 at 10:39:38AM +0000, Rick van Rein wrote:
> The /var/log issue is a good one -- I'm also hesitant what to do with it.
> Daily reports about changes in /var/log do not really help me stay
> focussed on everything that goes on in there.  Especially because Aide
> only summarises the changes.  Any normal changes that can be suppressed
> from Aide's output are quite welcome.

I have not yet found an idea to do it any better.

> > I am currently unsure about how to solve this; any more relaxed rule
> > would allow an attacker to place her root kit into the log directory.
> 
> This wouldn't be pleasant, but as stated elsewhere, it's virtually
> impossible to track /tmp either.

My systems have /tmp under aide control. Works actually pretty good if
you have a system in place that allows you to add package-based aide
rules.

>   Does that mean that we would not be able, in general, to track root
>   kit installations, and that we needn't worry about root-writeable
>   /var/log any more than we do about anybody- writeable /tmp ?  (Of
>   course I know there are many ways of getting content into log files
>   from network interfaces, but this hardly seems exploitable.)

I am not sure about that, but I am not an expert.

> > And it is kind of beyond aide's scope to notice that mainlog.1 is the
> > same file with its contents compressed to mainlog.2.gz.
> 
> But why?  I can imagine Aide to unpack certain files before testing them.
> A simple name pattern match with /var/log/*.gz could suffice to trigger
> this behaviour.

Nice idea. This is now wishlist request 1683253 in the aide feature
request tracker. If you have things to add to my report, please do so.

> Finally, log files are not tested for their contents, but only for
> growing size.  It sounds like childs play to install a root kit under
> that little scrutiny -- just make a file large enough and overwrite
> the logs that are in place.  (This'd assume the logs aren't monitored.)
> 
> Would it not be possible for Aide, since it records the previous
> log file size, to verify checksums over the initial part of the
> file comprising of the old size?  So the options for a growing
> logfile could include S+md5+sha1 and the hashes would know, as a
> result of the S option, that the old size is to be used to record
> the previous bits.

Nice idea. wishlist request 1683255 in the aide feature request
tracker. Again, if I omitted something, please add there.

> Am I correct in understanding that...?
>  - this is not currently possible with Aide
>  - there are no current other semantics for S+md5 c.s.

As far as I know, you are correct.

> The only thing that would be counter-intuitive about this approach
> would be that it is meaningful to update the recorded Aide Database even
> if the check reveals no changes -- because there are unnoticed changes
> to the log files that might be processed to tighten the next check.

Debian solves this issue by always running aide --update, and copying
the new database to the old one if no changes were detected. This
behavior can be selected in the cron job configuration file. As soon
as one difference is found, the database is left alone, and thus the
next days, the aide report gets longer quickly.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


More information about the Aide mailing list