On Thu, 2015-09-10 at 22:21 +0000, Phillip Baker wrote: > > Some thoughts have arisen: >
> A: Should rkhunter consider /lib64 as well as /lib for this (and > any?) file based check in /lib? > It should (but doesn't at the moment). > 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. > The check is not so much for ld.so.preload itself, but what is in it. Anything that is not whitelisted should be flagged as a warning. > 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] > I thought it did. > > 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? > Not sure as to why. It may just be historical, but taking a quick look I can see no real reason why it shouldn't be enabled by default. With the test enabled, the absence of unhide should be flagged as 'skipped' and not cause a non-zero return code to the user. That would need to be checked. > > [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! > Hmm, I see what you are saying. Perhaps a more general prereq check at the start of any RKH run to see what is 'missing' for the enabled tests. If this shows red then the user can install the required missing command, or disable the test. It's possible, but would need to look to see what it affects other than unhide. > [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? > As said above, not really sure why. Whilst a very quick initial look sees no real problem with enabling the test by default, I have that nagging feeling that there may well have been a good reason not to do that. It will need a closer look. John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK ------------------------------------------------------------------------------ _______________________________________________ Rkhunter-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rkhunter-users
