Keep in mind, that Rkhunter does not check for kernel rootkits. Ktraq IDS Tool will detect Kernel rootkits, and if one is present, it will completely disable it. This tool is for the 2.6 kernel running on an x86 processor, and was just released a week ago.


//moderator.note: pruned from http://www.linuxquestions.org/questi...please-612760/

Hello and welcome to LQ, hope you enjoy being part of the LQ Community...

Please note it's customary at LQ to not revive stale threads (more than say four months old).

Can you elaborate on that and provide details in which ways it does not?


Thanks, good to know theres a new tool out.
BTW your vampire v2 tarball can't be downloaded.
BTW[1], Samhain can test for LKMs as well as Skdet and a host of other tools, maybe point out your tools three or four unique selling points?

0) Note that even Samhains kern_check can do System.map-based checking too. And like that all tools it is worth nothing unless compiled, installed and secured after a clean OS installation (something which your README doesn't explicitly say while it should).
1) Next to that your v0.3 Makefile doesn't make the kfix and ktraq LKMs so 'ktraq -d' errors out with "can't read ktraq.ko".
2) Also your "Audit" section of the README includes examples of how to "snapshot" processes without taking into account short-lived processes (and the FPs those will cause, w/o providing the user a means to verify those are FPs).
Finally how trustworthy would a machine be using a tool that alters any information after it got altered in the first place?

There are more in-depth tools in my view compared to RKHunter.
For example, I use chkrootkit often.
There's always the option of using tripwire, which is difficult to hide stuff from.

Please enlighten me. Which "more in-depth" tools are that?


In what way did you test and found Chkrootkit to perform "more in-depth", detect more, be more versatile compared to Rootkit Hunter?


And what in tripwire makes it so special that it is "difficult to hide stuff from"?

tripwire is an integrity checker. The two others are online rk detectors, not at all the same kind of tool.. Compare what is comparable..

Thanks for the feedback. I've seen tools that do System.map checking, namely KSTAT for 2.4, but nothing that actually restores the sys_call_table to the correct (hopefully) addresses in memory. I'm not sure why the Makefile isn't properly compiling the modules, is it possible you are trying to compile this on a 2.4 kernel? As far as the Audit section, that is simply a brief outline--an example-- as to how someone might use ktraq, it is not a complete, and absolute way of doing things.

OK, but why would you want to restore it? How trustworthy would a machine be using a tool that alters any information after it got altered in the first place? Isn't detection (invasive as any detection already is for running and thus tainting memory) enough? How can you ensure and verify it works at all when something (or multiple somethings) work against you even before running the app?And what are you going to do when the "restore" fails? Revert? Leave it that way? Mind you, I'm not at all criticising you for the idea itself (regardless of symbol exports, changed kernel structures, less LKMs for 2.6 we don't have much options on the detection side and Zeppoo folded some time ago) I just would like to see how far you've thought it through...


No, vanilla 2.6.4. Just tell me what you want to see if you need more info. BTW any chance of fixing Vampire D/L while you're at it?

Well, I have indeed thought it all the way through. If there was a root kit installed on my System, and if the System.map file modification time seemed correct, I would risk restoring the sys_call_table. The truth is, that the System.map file is probably not going to be altered. In order for a hacker to alter it properly, meaning to fool something like ktraq, then they must write a module on top of their root kit that shows them where the hacked syscalls reside in memory, then replace those in the System.map file to contain the hacked ones. Another thought, is keeping a copy of your System.map file off of the internet all together, which can be used at a later time, assuming that you have knowledge of ktraq. Using the -r option of ktraq on a tampered system has the potential to be dangerous, you are correct. And I appreciate you suggesting that I should mention that in the README. I will fix the link to Vampire for you, I'm not sure what happened.

Well I guess that's where we differ. In terms of sysadm I don't like *any* changes (legal or illegal, IOW threaths to stability) unless "they" haven proven (in the staging area) that changes aren't detrimental to performance and stability. In terms of forensics I have doubts as well because 0) in forensics allowing change upon change is like trampling "evindence" (and we're running tools in memory already) so it'll make investigation harder, and 1) there's no guarantee it'll work (how about other LKMs being loaded before?) or mess up more, leaving the system possibly completely inaccessable.
* BTW Vampire refuses to compile. Since it's not a benign LKM I'd rather you contact me off-board if you're interested.