Larry, Let's define rootkit: The name for a kit of hacker utilities placed on a UNIX machine after a successful compromise. A typical rootkit includes: password sniffer log cleaners replacement binaries for common programs on the system (e.g. inetd) backdoor programs replacements to programs like ls and find so that they will not reveal the presence of the rootkit files. Key point: A rootkit contains many trojaned programs. These programs are used to allow the hacker entry back into the system and to hide the presence of the hacker. These legacy rootkit file tools like lsattr, chkrootkit, and rkhunter are no longer that useful. As a practical lab, it would be trivial to obtain and install [say on a Vmware image] one of the packages listed below and run these tools against it. We will find that they simply find false positives. Why? Since it's fairly easy to assemble linux binaries and add additional functions and features, all files are suspect, even those that "look" completely reasonable. The rootkit hunters also seem to provide a false sense of security. The CRC fie check tools like Tripwire and Labrador are still well utilized. They require a base file check right after installation before being placed into production on a network. They take a CRC signature for all systems binaries and report from later scans (scheduled from cron or manually kicked off) if something has changed. While it's not impossible to obtain source code and recompile a binary with the same CRC signature, it's not easy. CRC changes are the most comprehensive signs of hacked binaries or rootkits. A great many other rootkits are actually created as modules: http://alexids.googlecode.com/files/WRITING_A_SIMPLE_ROOTKIT_FOR_LINUX.pdf Some use existing processes (syscall) http://memset.wordpress.com/2010/12/28/syscall-hijacking-simple-rootkit-kernel-2-6-x/ Others infect the MBR of the system: http://linuxpoison.blogspot.com/2008/03/most-dangerous-rootkit.html These are difficult to find - since they require a low level file system analysis. If you use rsync or dd to create images or copy files, you will infect your new systems unknowingly. Other References: http://lida.sourceforge.net/ Disassembler Tool http://www.ossec.net/rootkits/studies/lrk5.txt Linux Rootkit IV 1998 http://www.ussrback.com/UNIX/penetration/rootkits/ Complete source for a list of rootkits On 7/29/11, Joseph Sinclair wrote: > What you see below is false-positives. > The files in /usr/lib are normal files used for things like initialization > control (pymodules) and JDK selection (jvm). > The files in /dev/shm are pulsaudio temporary device files, and like > everything in /dev/shm will disappear on a reboot (/dev/shm is a filesystem > interface to shared memory). > The hidden directories are likewise normal (java, udev, initramfs) elements > of the system. > > That's why these things are warnings; they *might* be a problem, but the > software has no way to be sure (although it really should have exceptions > built-in for things like pulseaudio, udev, and initramfs stuff). > > Then again, it's fundamentally impossible to know if a system is clean from > within that system (since a rootkit could just intercept any call that would > expose it's presence and return a false result). > Usually these tools should be run against a chrooted/mounted filesystem from > a known-good rescue CD. > > On 07/29/2011 08:48 AM, Dazed_75 wrote: >> One of the blogs I read just had an article about finding rootkits in >> Linux. While not worried about it, I thought it would be fun to check it >> out. They talked about 3 commands; lsattr, chkrootkit, and rkhunter. >> >> lsattr didn't find anything of interest the few directories I tried it on >> except that this line showed up for some files (I think they were all >> links): >> >>> lsattr: Operation not supported While reading flags on /bin/bzegrep >>> >> >> chkrootkit found >> >>> ROOTDIR is `/' >>> Searching for suspicious files and dirs, it may take a while... The >>> following suspicious files and directories were found: >>> /usr/lib/xulrunner-1.9.2.18/.autoreg >>> /usr/lib/firefox-3.6.18/.autoreg >>> /usr/lib/pymodules/python2.6/.path >>> /usr/lib/pymodules/python2.6/PyQt4/uic/widget-plugins/.noinit >>> /usr/lib/jvm/.java-6-openjdk.jinfo >>> /usr/lib/thunderbird-3.1.11/.autoreg >>> >> >> those are mainly empty files and the ones that were not seemed reasonable >> to >> an uneducated eye. Problem is that they don't say what it is that is >> considered suspicious >> >> rkhunter -c found >> >>> [08:27:47] Checking /dev for suspicious file types [ Warning ] >>> [08:27:47] Warning: Suspicious file types found in /dev: >>> [08:27:47] /dev/shm/pulse-shm-3633543672: data >>> [08:27:47] /dev/shm/pulse-shm-2330444361: data >>> [08:27:47] /dev/shm/pulse-shm-2759599877: data >>> [08:27:48] /dev/shm/pulse-shm-2688255106: data >>> [08:27:48] /dev/shm/pulse-shm-2964324177: data >>> [08:27:48] /dev/shm/pulse-shm-878858236: data >>> [08:27:48] Checking for hidden files and directories [ Warning ] >>> [08:27:48] Warning: Hidden directory found: /etc/.java >>> [08:27:48] Warning: Hidden directory found: /dev/.udev >>> [08:27:48] Warning: Hidden directory found: /dev/.initramfs >>> >> >> Similar comment. It is difficult to know what to check for. Again I am >> not >> worried, just curious. >> >> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > -- (602) 791-8002 Android (623) 239-3392 Skype (623) 688-3392 Google Voice ** HomeSmartInternational.com --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss