How to audit machine?

Haven't heard back on whether my iptables are adequate,
but it occurs to me that there's a less exotic threat.
For some time while I was configuring my new machine,
I had not turned on iptables yet, and I *did* have
ssh daemon running, and I was using recycled passwords.
So a hypothetical opponent who had intercepted one
of those passwords in the past could have seized a
window of opportunity. The user password, at least,
has been sent across the net in cleartext in
the past (to an IMAP server) -- the root password, I
tried to protect better, but I still can't be absolutely sure.

If the consequences of this were bad enough I would
have to assume it had happened and reinstall, but I'm
not developing weapons systems. Naively, my guess
is it's improbable that this has happened (the opening
would have been a matter of hours, not days). But
is there any way to check? What should I look for?

A horsie named Mike Oliver demonstrated surprising intellligence and its
ability to use morse code on Sat, 15 May 2004 16:55:27 -0500, when it
tapped <2gnhufF4r5i8U1@uni-berlin.de> with its hoof:

> [...]
> Naively, my guess is it's improbable that this [rooted system] has
> happened (the opening would have been a matter of hours, not days). But
> is there any way to check? [...]

Use chkrootkit.

Mike Oliver wrote:
> If the consequences of this were bad enough I would
> have to assume it had happened and reinstall, but I'm
> not developing weapons systems. Naively, my guess
> is it's improbable that this has happened (the opening
> would have been a matter of hours, not days). But
> is there any way to check? What should I look for?

Check for rootkits (http://www.chkrootkit.org/), monitor the network
(from another box) for unusual activity.
Compare the installed files to the files provided by the distribution.
Some distributions have tools for this (e.g. debsums). But you will have
to make sure no local md5sums are used (e.g. debsums --generate=all).
The program will have to re-download all files and re-generate all mdsums.

You should do all this from a safe source, e.g. a rescuedisc (knoppix
may be a good choice).

good luck,
Nils

Nils Juergens wrote:
> Mike Oliver wrote:
>
>> If the consequences of this were bad enough I would
>> have to assume it had happened and reinstall, but I'm
>> not developing weapons systems. Naively, my guess
>> is it's improbable that this has happened (the opening
>> would have been a matter of hours, not days). But
>> is there any way to check? What should I look for?
>
>
> Check for rootkits (http://www.chkrootkit.org/),

OK -- so I tried this and it came up clean. For good
measure I decided to audit a box I have at work, and
it found some "suspicious files" that are apparently
false positives (mentioned in the docs), plus it
gave the following message that I don't understand:

Checking `sniffer'... eth0: PF_PACKET(/sbin/dhcpcd)

This was amid a whole bunch of "Checking foo ... not infected"
messages. So it doesn't say sniffer is infected, but it doesn't
say it's not, either. What does it mean?

Mike Oliver wrote:
> false positives (mentioned in the docs), plus it
> gave the following message that I don't understand:
>
> Checking `sniffer'... eth0: PF_PACKET(/sbin/dhcpcd)

It is looking for a process that may be sniffing packets on your
network. This 'sniffing' is usually done by an attacker to intercept
passwords because they are more likely to be sent unenctrypted over a
lan. A lot of people feel safer inside their switched lan which they
shouldn't.

In your case it seems to be your DHCP client which, due to its nature of
having to work even without an IP, has to connect to the interface on a
lower level than normal sockets.

This is, assuming the binary for /sbin/dhcpcd hasn't been tampered with,
nothing to worry about.

hth,
Nils