[ale] diagnosis

[David Corbin]

On Monday 19 April 2004 15:01, James P. Kinney III wrote:
> If it is a cracked machine, running a statically linked top from a CD
> will gain access to the real top data. Top is a common binary to fiddle
> with with a root kit.

Sounds reasonable.  Can you point me at such, or if not that, anybody got any 
idea where the source to top is and I'll build my own.

>
> It is certainly possible to _add_ a module or _remove_ a module, but
> change out the kernel with out a reboot (unless 2-kernel-monte is
> available, I have not been able to find this :(  ). So the actual data
> stream for top is not tamper-able easily. Thus a known good
> statically-linked top would give access to the running system and show
> the _real_ processes that are running.
>
> If top shows no malicious files, it's time to take some snapshots over
> time to plot which app is failing.
>
> #!/bin/sh
> echo date >> /tmp/top.txt
> top -b -n 1 -c >> /tmp/top.txt
> echo "###############" >>/tmp/top.txt
> echo >>/tmp/top.txt
> echo >>/tmp/top.txt
>
> Run as a cron every minute for an hour.
>
> If you want, you can now mash/mangle the data into a nice plot using
> some perl and gnplot (or a spreadsheet).
>
> On Mon, 2004-04-19 at 11:56, Geoffrey wrote:
> > Dow Hurst wrote:
> > > How can we find the process that is soaking the memory?  How do you
> > > manipulate /proc to find out the originating process that owns the
> > > memory being used?  I know IRIX had tools to look at memory and see
> > > which processes owned what part of memory.  Does Linux?
> > >
> > > Seems if you knew what was leaking you would have a major part of the
> > > battle won.
> >
> > I believe we mentioned top, but he noted that doesn't give him anything.
> >   That's what concerns me.  If it doesn't show, is it being hidden for a
> > reason???