Re: Iptables firewall
On 21 Jul 2004, jmm wrote:
> I won't be able to do this until later in the day but this antivirus does
> not detect anything in /proc/kcore anymore. It is strange that a scan
> with f-prot (up to date) did not detect anything (done after vexira
> detected the signature in /proc/kcore).
I admin, I have reasonable faith in f-prot and ClamAV, and don't know
this vexira package, but that could just be my background or
geographic location causing it.
> I also thought that the antivirus scanner is seeing a copy of it's own
> definition in kcore. I emailed vexira and support staff said that they
> don't think so and that it does not happen for them.
OK. It sounds like it may be a transient fault to me, but it is hard to
say. If the people who wrote the software don't think so, they know much
better than I do. :)
> Just for curiosity, I ran an exhaustive scan all over and vexira dound a
> signature in a tcpdump.log (a code Red--AFAIK, this is a windows worm).
> Of course, I deleted this file.
Sounds like a packet capture picked it up at some point...
> In summary,:
> a) vexira does not detect anything in /proc/kcore (before and after
> deleting that tcpdump.log) except on one ocassion and it dissapeared after
> reboot.
Sounds like a transient bug - a race condition with the kernel buffers -
that caused this to me. OTOH, the developers say it shouldn't happen,
and they should have some idea at least...
[...]
> I am curious to know how booting with a different kernel (from a cd
> install, for example) will determine if it is an error?
> What is the rationale, if you wish to share?
Sure. The answer is pretty simple:
*If* your system has been taken over, *and* that code is running in
kernel mode, two things are likely:
1. It is impossible for anything running under the infected kernel to be
trustworthy in detecting the presence of the infection.
2. It is likely that the rootkit will be loaded early in the picture,
resulting in point 1 being (possibly more) relevant after the reboot.
So, the way to be sure is to *remove* the power of the infected code:
You need to boot from a kernel that you *know* is not infected with any
hostile code.
The kernel that you (or whoever) burned as part of the install image for
a Linux distribution is a pretty safe bet here, and also something that
most people have on hand.
Second, you need to run only trusted code -- so *nothing* off the hard
disk that had the infection.
A distribution install CD usually has enough tools to be able to get to
a console, reinstall the anti-virus or rootkit software, and then run it
safely.
Basically, once you can't trust the kernel on a machine you can't trust
*anything* on it, since the kernel can make it look right, but be wrong.
Daniel
--
Newsgroup volume is a measure of discontent.
-- Erik Naggum, _comp.lang.lisp_
Reply to: