http://www.osnews.com/story/16816/Various_Ways_of_Detecting_Rootkits_in_GNU_Linux Exploring the Future of Computing en-us Copyright 2001-2010, David Adams adam+nospam@osnews.com Sat, 20 Mar 2010 08:05:20 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread?196246 http://osnews.com/thread?196246 I have used Rootkit Hunter in the past, but to be quite honest I have never detected a rootkit.
However running Rootkit Hunter is a good thing because it will check some of your default security settings, and believe me, not all distros have a tight security policy. Tue, 26 Dec 2006 17:10:00 GMT donotreply@osnews.com (Anonymous Penguin) Comments http://osnews.com/thread?196260 http://osnews.com/thread?196260 First of all, I have to admit that I don't use Linux (except for toying around), so maybe I got something wrong. I have a question:

Maybe you have a user "bob" installed, and "bob" does know the root password, can he su root?

bob@myserver:~$ su -
Password:
root@myserver:/# _

Maybe it's not related to the topic directly, but I'd like to mention the following thing: In FreeBSD (as in other BSDs, too), users need to be in a special group to su root. This is the "wheel" group. Users usually are in the "staff" group or any other group or subgroup for determining access controls.

So let's assume "bob" is in "staff", and he tries:

bob@myserver:~% su -
su: Sorry
bob@myserver:~% _

Even if "bob" knows the correct root password, he will not be able to su root until someone places him into "wheel" which requires rw access to /etc/group which is -rw-r--r--, so only root:wheel can change it. "bob" even won't know if his root password really is correct. Tue, 26 Dec 2006 18:24:00 GMT donotreply@osnews.com (Doc Pain) Comments http://osnews.com/thread?196289 http://osnews.com/thread?196289 In Linux the wheel group is also used. Tue, 26 Dec 2006 19:17:00 GMT donotreply@osnews.com (siride) Comments http://osnews.com/thread?196310 http://osnews.com/thread?196310 In FreeBSD security tools send me every day messages about what's going on:

# mail
Mail version 8.1 6/6/93. Type ? for help.
"/var/mail/root": 2 messages 2 new
>N 1 root@localhost.local Tue Dec 26 13:16 244/10722 "pcbsd-6956 security run output"
N 2 root@localhost.local Tue Dec 26 13:16 73/2677 "pcbsd-6956 daily run output"
&

Checking setuid files and devices:

pcbsd-6956 changes in mounted filesystems:
--- /var/log/mount.today Mon Dec 25 01:38:53 2006
+++ /tmp/security.cxgru6i5 Tue Dec 26 13:15:54 2006
@@ -3,5 +3,3 @@
/dev/ad0s2e /usr ufs rw 1 1
/dev/md0 /tmp ufs rw 2 2
linprocfs /usr/compat/linux/proc linprocfs rw 0 0
-/dev/ad0s1 /media/disk ntfs rw,noexec,nosuid 0 0
-/dev/ad0s3 /mnt/backup msdosfs rw 0 0

Checking for uids of 0:
root 0
toor 0

Checking for passwordless accounts:
Checking for passwordless accounts:

pcbsd-6956 pf denied packets:
+++ /tmp/security.BaS1as55 Tue Dec 26 13:15:55 2006
+block return in log all [ Evaluations: 422 Packets: 61 Bytes: 7412 States: 0 ]
+block drop in quick on ! lo0 inet from 127.0.0.0/8 to any [ Evaluations: 64 Packets: 0 Bytes: 0 States: 0 ]
+block return in from no-route to any [ Evaluations: 64 Packets: 3 Bytes: 1728 States: 0 ]
+block return on nve0 from to any [ Evaluations: 422 Packets: 0 Bytes: 0 States: 0 ]

..........
..........
pcbsd-6956 login failures:

pcbsd-6956 refused connections:

Checking for a current audit database:

Downloading fresh database.
auditfile.tbz 40 kB 21 kBps
New database installed.
Database created: Tue Dec 26 13:10:11 EET 2006

Checking for packages with security vulnerabilities:

0 problem(s) in your installed packages found.

-- End of security output --



There is no similar features on GNU/Linux? Tue, 26 Dec 2006 19:47:00 GMT donotreply@osnews.com (antik) Comments http://osnews.com/thread?196340 http://osnews.com/thread?196340 The upside of the BSD approach is that the audits get done.

The downside is that the output is noisy when there are no problems so it becomes easy to miss a problem when it shows up.

This is pretty much the trade off between automatic check ing versus manual checking.

But manual checking can also have the problem of too much noise so the signal can be missed.

Meanwhile, the article missed pointing out a key rule for using any rootkit checker: You have to install it each time you run it, unless it's self checking, because it could be a target of the rootkit.

Self checkers should verify themselves against a signed checksum. Do these? Tue, 26 Dec 2006 21:26:00 GMT donotreply@osnews.com (Cloudy) Comments http://osnews.com/thread?196366 http://osnews.com/thread?196366 Reading some of the comments on the article's site really shows how ineffectual running rootkitunter etc are.

I guarantee that if you've been rooted, neither rootkithunter or chkrootkit will detect anything, because they'll be maliciously manipulated to show nothing by the rootkit itself.

As someone pointing out, loading a read only cdrom with the root kit detectors on it won't work either. The best way would be to have a bootable cdrom with the rootkit detector on it that loads everything into RAM and runs it from there. You then mount your partitions as read only, and scan, using known good commands that are based ON the read-only cdrom. That's the only safe way to be sure.

I'm VERY surprised that no one seems to have created a live distro that specifically does this (at least to my knowledge).

For most people, as long as they don't run as root, they should be fine. Always run trusted binaries and src code. Always check the md5sums etc.

Thom, might be a good idea to put a blurb about running something like tripwire in the article intro on osnews.com. Of course, like with the rootkit hunters, you'd have to put the tripwire dbase onto a bootable Linux distro somehow to ensure that it's entirely safe and not using altered commands.

Dave Tue, 26 Dec 2006 22:58:00 GMT donotreply@osnews.com (melkor) Comments http://osnews.com/thread?196381 http://osnews.com/thread?196381 The devices most likely to have rootkits (servers) are the last thing you want to reboot regularly to check out with your live-cd rootkit detection test. Most of us cannot afford any downtime.

The only real "solution" to rootkits is to never contract them. Keeping current with security patches/bugfixes, having fine-grained access policies, proper firewall design, etc - it's all part of the equation.

Network monitoring policies are best to detect possible problems with servers, if you see outside access that shouldn't be there - the box is probably compromised. Restricting access with network policies is also one of the most effective ways of stopping such problems in the first place. Go figure. Wed, 27 Dec 2006 00:29:00 GMT donotreply@osnews.com (ormandj) Comments http://osnews.com/thread?196435 http://osnews.com/thread?196435 Logwatch comes enabled with RedHat systems (and CentOS). As far as I can tell it does more or less the same thing.

It's modular, easy to configure/extend to your needs. And if you consolidate your logs files by using a remote syslog server, you'll have a much useful output (overview of all your servers coming as a daily mail report).

Ok, to make is similar here's how the report looks:

################### LogWatch 5.2.2 (06/23/04) ####################
Processing Initiated: Mon Nov 13 04:02:03 2006
Date Range Processed: yesterday
Detail Level of Output: 0
Logfiles for Host:
################################################################

--------------------- pam_unix Begin ------------------------

crond:
Unknown Entries:
session closed for user root: 5 Time(s)
session opened for user root by (uid=0): 5 Time(s)


---------------------- pam_unix End -------------------------


--------------------- sendmail Begin ------------------------



Bytes Transferred: 1488
Messages Sent: 2
Total recipients: 2
---------------------- sendmail End -------------------------



------------------ Disk Space --------------------

/dev/mapper/Server-Root
7.9G 4.6G 3.0G 62% /
/dev/sda1 99M 44M 51M 47% /boot
/dev/mapper/
4.0G 41M 3.7G 2% /home
...

###################### LogWatch End #########################

It's from a backend server (so there are little logins, no attacks and almost no mail processed), I removed some parts, and many modules are not enabled for this system (e.g: no httpd), but it gives a general idea on the capabilities. Wed, 27 Dec 2006 03:46:00 GMT donotreply@osnews.com (sukru) Comments http://osnews.com/thread?196563 http://osnews.com/thread?196563 There probably is in some distros, although the ones I've used don't have anything like that by default.Edited 2006-12-27 15:19 Wed, 27 Dec 2006 15:18:00 GMT donotreply@osnews.com (Gullible Jones) Comments http://osnews.com/thread?196564 http://osnews.com/thread?196564 But I never added myself to wheel and I can su to root on my Mandriva systems. I think there is a way you can make it work that way, but I never checked into it because I'm the only user on my systems. This is probably the case for a large number of GNU/Linux systems. Wed, 27 Dec 2006 15:20:00 GMT donotreply@osnews.com (KenJackson) Comments http://osnews.com/thread?196587 http://osnews.com/thread?196587 GNU su has to be patched to support the "wheel" group for political reasons.

Type "info su" into a console or visit:

http://www.fifi.org/cgi-bin/info2www?(sh-utils)su+invocation

IMHO Stallman is mad. Wed, 27 Dec 2006 16:55:00 GMT donotreply@osnews.com (r3m0t) Comments http://osnews.com/thread?196599 http://osnews.com/thread?196599 Interesting. Your link has a section titled Why GNU `su' does not support the `wheel' group, but it's not there when I type "info su". I wonder what else Mandriva deletes.

BTW, while the issue is totally moot for single-user systems, I appreciate Stallman's position.
Edit: I guess 'mute' should be 'moot'.Edited 2006-12-27 18:17 Wed, 27 Dec 2006 18:11:00 GMT donotreply@osnews.com (KenJackson) Comments http://osnews.com/thread?196609 http://osnews.com/thread?196609 To go totally undetected, a rootkit would also have to replace the rpm command. Otherwise the following command will reveal any binary that is modified. (Legitimate conflicts also show up, but that's helpful too.)

rpm -Va | grep bin Wed, 27 Dec 2006 18:34:00 GMT donotreply@osnews.com (KenJackson) Comments http://osnews.com/thread?196686 http://osnews.com/thread?196686 I agree, but sadly, rootkits don't just affect servers, they can, and do affect ordinary users of GNU/Linux, hence my suggestion.

I know that as an IT guy, you don't want server downtime, quite simply, sometimes it's unavoidable. True, do everything possible to minimise the risk of ever getting rooted is a sound policy, the old saying "prevention is better than the cure" rings very true.

Dave Thu, 28 Dec 2006 01:30:00 GMT donotreply@osnews.com (melkor) Comments http://osnews.com/thread?196696 http://osnews.com/thread?196696 "To go totally undetected, a rootkit would also have to replace the rpm command."

Not at all, it just have to make rpm think that there are no modified files. Modifying the rpm database isn't hard once you have root. Thu, 28 Dec 2006 02:39:00 GMT donotreply@osnews.com (Soulbender) Comments http://osnews.com/thread?196697 http://osnews.com/thread?196697 "Most of us cannot afford any downtime. "

If it's that critical that you don't have any downtime you already have redundant systems in place. Then bringing individual systems offline for checking isn't a problem. Thu, 28 Dec 2006 02:42:00 GMT donotreply@osnews.com (Soulbender) Comments