Hi,
Thanks to the devs for their efforts on rkhunter. This is a new project to me
(the last time I had to do this chkrootkit was about the only choice) so I
apologise if I'm asking questions (or variations of questions) that have been
done to death.
I just had to disinfect (short term solution) a customer's unmanaged dedicated
server that turned out to be infected with a copy of libncom.so.4.0.1 [1]
(stashed in /lib64, and referenced in /etc/ld.so.preload) which was missed by
rkhunter (this rootkit has previously been discussed on here, but only once in
2011!) - I can see a check for /lib/libncom.so.4.0.1, but, of course, that's
not where the file was on this system.
Some thoughts have arisen:
A: Should rkhunter consider /lib64 as well as /lib for this (and any?) file
based check in /lib?
B: Thinking more generally, is the presence of /etc/ld.so.preload worth
flagging (though cleverer rootkits could probably evade attempts to open the
file directly)? Is it really a common occurrence on most people's systems? The
rootkit was apparently evading the check for preloaded libraries.
C: When unhide isn't installed (but rkhunter was called with --enable all),
should rkhunter not output to console that it has skipped the hidden process
check, in the same way that it says it has skipped the check for hidden ports?
[2]
D: OOI (and apologies if this has been discussed elsewhere, I could not see any
immediate references to it), why would the hidden process and port check not be
on by default given it gracefully handles the absence of unhide? Chkrootkit's
chkproc was the thing that confirmed my suspicions in the first place - and I
was a little surprised when I ran rkhunter that it didn't do a process check
"out of the box" [3]
--
Phil
[1] ..in order to conceal a cryptocurrency cpu miner which was niced to 20
which is why I started poking around on the box whilst I was on there fixing an
unrelated issue when I noticed that nice% was sat at 100%
[2] IMHO, it should probably make more noise on the console about missing
dependencies - skipped due to a missing dep should surely be red in the same
way the properties prereq check is!
[3] I'm aware that hidden process checks can produce false positives from
transitory processes (though, IMO, these could be reduced by running two checks
in series a few seconds apart and comparing the results, no?), but rkhunter
says elsewhere when it is up to a user to make a determination for themselves
if something is genuinely suspicious, so why are users "protected" from the
check for hidden processes?
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Rkhunter-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkhunter-users
