[Aide] aide 0.11 is generating a VERY large database.

[Bob Hutchinson]

On Wednesday 07 February 2007 15:32, Marc Haber wrote:
> On Mon, Feb 05, 2007 at 09:26:21PM +0000, Bob Hutchinson wrote:
> > On Monday 05 February 2007 16:02, Marc Haber wrote:
> > > On Mon, Feb 05, 2007 at 03:34:54PM +0000, Bob Hutchinson wrote:
> > > > !/var/log/messages(.[0-9])?(.gz)?
> > > > !/var/log/mail.(log|error|info|warn)(.[0-9])?(.gz)?
> > > > !/var/log/kern.log(.[0-9])?(.gz)?
> > >
> > > So your attacker places her root kit in
> > > /var/log/messages.9999999999999 and you won't notice.
> >
> > you got me bang to rights guvnor!
> >
> > did (as root)
> > touch /var/log/messages.9999999999999
> > /etc/cron.hourly/aide
> >
> > nada ;-(
> >
> > mind you, I would not be able to create a file in /var/log as anybody
> > other than root.
>
> Yes. A root kit is a kit to stay root after becoming root. When you
> are looking for a place to dump a root kit, you are usually root
> already.
>
> > In practice I have found that setting wget and curl to chmod 700 has
> > stopped several attempts,
>
> I tend to uninstall unneeded tools in their entirety. But, that's only
> going to stop lazy or clueless attackers.
>
> On Debian systems, debfoster is a big helper.
>
> >  reported in logcheck and I have been able to identify which
> >  customer's leaky script was responsible for the unsuccessful attempt
> >  to wget something into /tmp. This could also be done in iptables by
> >  denying http fetch,
>
> Yes, firewalling outgoing connections is generally a good idea.
>
> >  but I do (as root) fetch stuff such as clamav and there is apt-get to
> >  consider as well.
>
> clamav and apt-get are only fetching from a rather short list of
> known systems, so it could be allowed to make http connections only to
> a system on that list. If you want to be really secure, have a script
> that opens the packet filter, does the update and closes the filter
> again. And think about having the packet filter on a different system.
>
> > Ideally /tmp should have it's own partition and be set to noexec in
> > /etc/fstab and *BSD boxes are, but in practice most of the boxes I
> > tend were not set up by me and I have to work with what I find.
>
> When I tried last, noexec was trivially to dodge.
>
> Greetings
> Marc

Thanks for your most interesting comments, it's all grist for the mill.

-- 
-----------------
Bob Hutchinson
Midwales dot com
-----------------