“A rootkit is a collection of tools a hacker installs on a victim computer after gaining initial access. It generally consists of network sniffers, log-cleaning scripts, and trojaned replacements of core system utilities such as ps, netstat, ifconfig, and killall. I know of two programs which aid in detecting whether a rootkit has been installed on your machine. They are Rootkit Hunter and Chkrootkit.”
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.
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.
In Linux the wheel group is also used.
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.
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.
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
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 [email protected] Tue Dec 26 13:16 244/10722 “pcbsd-6956 security run output”
N 2 [email protected] 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 <blacklist> 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?
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.
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
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?
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
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.
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
“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.
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
“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.