rkhunter

[Swazi]

Hi

On my one machine i get 7 bad md5sum checks with rkhunter. chkrootkit shows up ok. Here are some of the results.

/sbin/depmod [ BAD ]
/sbin/insmod [ BAD ]
/sbin/modinfo [ BAD ]
/sbin/sysctl [ OK ]
/sbin/syslogd [ BAD ]
/sbin/init [ OK ]
/sbin/runlevel [ OK ]
/usr/bin/groups [ OK ]
/sbin/ip [ BAD ]

All the other checks show up allright.

Is this something to worry about ?

Swazi

[TheCotMan]

Hi

On my one machine i get 7 bad md5sum checks with rkhunter. chkrootkit shows up ok. Here are some of the results.

/sbin/depmod [ BAD ]
/sbin/insmod [ BAD ]
/sbin/modinfo [ BAD ]
/sbin/sysctl [ OK ]
/sbin/syslogd [ BAD ]
/sbin/init [ OK ]
/sbin/runlevel [ OK ]
/usr/bin/groups [ OK ]
/sbin/ip [ BAD ]

All the other checks show up allright.

Is this something to worry about ?

Swazi

Never used the tool you describe, but here is what it means:

A "fingerprint" (md5sum) that is known by your utility (rkhunter) for each of those applications does not match the fingerprint it computes for each file.

This can mean that the files with [BAD] are not the original files, or that they are not the files that rkhunter is configured to know about (even though they were part of your distro, just updated) or that they are files that are trojaned, or these files may be in some way designed to do something that you may not want them to do.

What does this mean? It means you should investigate these files and your tool. See if these files were updated, and your tool was not updated to include the md5sum (fingerprints) for the new files [for which] it is providing false positive with [BAD] or investigate these files reported as [BAD] to see if they are not what you want installed.

Tools like this are designed to inform you of things that are unexpected, but have a high rate of false positive or reports for problems that are not "bad problems"-- just issues of misconfiguration.

However, the apps that are reported as bad could suggest that you have a "stealth root-kit module" running on this (assuming) Linux system in kernel space... then again, an update of modprobe would likely mean and update of depmod too, and could lead to the the behavior you see.

[Added Content below this point]
After entering a google search, I found the freshmeat site which lead me to the project home, and then a search of their articles shows an article on false positives.
At the top of this page you can see a description of how they use the md5sum.

It appears that this is a kind of tool that falls into a sub-classification of IDS like AIDE, tripwire, samhain, etc, but is not as advanced-- Maybe more like "logcheck". It seems to act more like a simple AV Scanner or "Spyware/Adware scanner" than an IDS.

[Dang! My grammar sucks. Many fixes included above]

[dYn4mic]

Start with... lets worry about it... until you can prove otherwise.
As TheCotMan said.. you should checkout if these files were recently purposfully changed...
I'd also recommend looking at the dates of these changes...(all the same time? at 1am? around the same time you upgraded something?) and then compare that to any logs/info.
(( Best would be on another box. Hopefully the time/date on the boxes are the same too! (but i'd look at running openNTP, not the reg. ntpd..anyways))) BUT you said "on my one machine" so thats a possible problem. You should be aware that its possible your logs may be compromised because of the line: /sbin/syslogd [ BAD ] ....

Is it possible that you could've had an intrusion since your last run of rkhunter? How is the overall security of your machine??

I really would recommend Samhain over tripwireish Host integredy checking stuff... You should look into running it... http://la-samhna.de/samhain/ or
At least you could also look into some kind of secure log setup (ie. secure exportation)
And if your into crypto http://www.schneier.com/paper-secure-logs.pdf
Good luck!
------------------------------------------------------------------
Sticking feathers up your butt does not make you a chicken.

[TheCotMan]

I'd also recommend looking at the dates of these changes...(all the same time? at 1am? around the same time you upgraded something?) and then compare that to any logs/info.

This is a good advice. There are usually 3 times available with files: (How many are available depands partly on the filesystem that houses the files.)

Creation, Modification, Access (see "man ls" for how to list each time.)
Access Time is pretty much useless for this kind of thing, and it can be changed
Modification Time can be changed on the running system too by any user that can write to the file (see man touch to modify modification time on files)
Creation Time is often quite useful, but even this can be altered-- most obvious method is to change the system time before file creation, but that generates log data, for which there are other countermeasures...)

Dates are usually good clues, but should not be considered cornerstones in your investigation.

Is it possible that you could've had an intrusion since your last run of rkhunter? How is the overall security of your machine??

Good questions to ask. Good idea with syslog suggestion.

If you determine there was a break-in, to this degree (root/kernel access), it is best practice to copy all your text files, and config files to another disk [after booting from another system like an emergency boot CD), review all config options in your config files and sanitize config files by hand. Then format the non-backup system disks and re-install from scratch, and then copy back your text files and config files. (The usefulness of most host based IDS is severely diminished if they are installed on previously trojaned/compromised system.)

I really would recommend Samhain over tripwireish Host integredy checking stuff.

I have used both, as well as AIDE and others as well. Tripwire has *many* *many* options available and is quite mature, but has a steep learning curve before you can get any kind of useful data after lots of fine tuning its reports.
Samhain has a lot of active development, but still has a number of bugs that appear from time to time-- more than you might expect from such a product.
(I have used it in a mixed Solaris/Linux environment, and get many false positives, some config file options mentioned in the man pages are obselete, or do not work, some mentioned on their site are not mentioned in their man pages-- or at least this was the case 3 months ago... documentation is lacking, but it has many good features and we still use it in many places.)
AIDE is bonehead simple, but is also feature-less and does not scale well and lacks many advanced IDS features.

At least you could also look into some kind of secure log setup (ie. secure exportation)

Though samhain offers some support for security of passing logging information from samhain to yule, you can also check out syslogng which allows passing of syslog with TCP instead of the default/standard UDP which can result in loss of data.

[Swazi]

ping

The datestamp seems fine:

ls -alR /bin/netstat
-rwxr-xr-x 1 root root 94860 Mar 15 2004 /bin/netstat*

ls -alR /sbin/syslogd
-rwxr-xr-x 1 root root 27832 Apr 22 2004 /sbin/syslogd*

One thing that worries me about this machine is that it has long pings when i ping from other machines in the network, compared to the others, ssh also takes a second or two to kick in whereas the others are quick. But like i said the datestamp looks fine, so it's a bit of a tricky one and a real mission to install from scratch.

[TheCotMan]

The datestamp seems fine:

ls -alR /bin/netstat
-rwxr-xr-x 1 root root 94860 Mar 15 2004 /bin/netstat*

ls -alR /sbin/syslogd
-rwxr-xr-x 1 root root 27832 Apr 22 2004 /sbin/syslogd*

Again, modification time can be easily altered by any user with write access to the file with the touch command.

At a minimum, check out the creation time:
$ ls -l --time=ctime /bin/syslogd

It is also possible to alter ctime through other methods, it is a little bit more tricky, and is often overlooked. If the ctime is not from a time of the original install, or an update you conducted, then that is a good indication something is fishy with the file(s).
However, just because the time seems right does not mean the file is the original, unmodified file.

Again, date stamps are data points, but not guaranteed to be accurate.

(Also, some backup software will run as root and even alter the ctime of a file to be the time the file was backed-up.)

One thing that worries me about this machine is that it has long pings when i ping from other machines in the network, compared to the others, ssh also takes a second or two to kick in whereas the others are quick. But like i said the datestamp looks fine, so it's a bit of a tricky one and a real mission to install from scratch.

Do you have a spare machine? Can you create extra space on a partition of this machine for a minimal install of the same distribution/version and update it to the same patch-state of the machine in question? (If you are only checking syslogd, modprobe and the other 5, they should exist in even a minimal install.)

If so, then you can perform your own md5sum on each file on the clean system, and then boot from an emergency boot cd and mount the dirty system and run md5sum from the booted CD on the files from the dirty system and compare the checksums to the clean system.

If they are the same checksum, and the files are the same length, you have a very strong indicatotion that the files are identical and the one on the dirty system is the original file. (If you want to be sure, use of the command "cmp" will help, but you will need copies of both files on the same non-dirty system.)

You probably do not want to assume that md5sum itself is clean on the potentially dirty system. It could be trojaned to report false information. (Always assume that all files could be trojaned on a system that is assumed dirty.) Booting from a trusted Emergency Boot CD allows you to run applications that you trust are working properly and will give truthful results.