Detecting Rootkits In GNU/Linux 142
An anonymous reader sends note of a blog post on rootkit detection in GNU/Linux. The article mentions only two utilities for ferreting out rootkits — the first comment to the blog post lists three additional ones — but it could be useful for those who haven't thought about the problem much. From the article: "A rootkit... is a collection of tools that a cracker installs on a victim's computer after gaining initial access. It generally consists of log cleaning scripts and trojaned replacements of core system utilities such as ps, top, ifconfig and so on."
ifl (Score:3, Informative)
Re:ifl (Score:5, Informative)
Re:ifl (Score:5, Funny)
Re:ifl (Score:4, Insightful)
You know, one of the things I'd like to do if I had more time and knew how to do it would be to create a bootable "system scan" disk. A rootkit could hide itself from tripwire et al, but it couldn't hide from a bootable CD. I guess you can sort of achieve the same effect with Knoppix with a bit of work, but it would be nice to have something that I could use to scan a machine for vulnerabilities without using the hard drive to boot at all.
Re: (Score:3, Informative)
Re: (Score:2)
. The system could be almost completely restored on an orderly shutdown, leaving nothing detectable but a single hook (hide everything else in swap or unused sectors in filesystem)
. Even without an orderly shutdown, a rootkit could keep stuff in the unused parts of the harddisk all the time, the rootkit would take care of not overwriting it.
. MD5 hashes can be subverted, which means the above mentioned initia
Besides the point! (Score:2, Informative)
Kind of bypasses the point of detection, in a way.
One cane safely ass-u-me that if the storage is disconnected, then , if You look very very close, then You could detect a rootkit. Though IF,
Re: (Score:2, Informative)
The only way to leave a 'hook' on any common setup is to modify the storage medium of the OS or modify the firmware of a piece of hardware. Both can be detected, and there's no way to prevent that.
Re: (Score:2)
But you can prevent it from being easily detected. Especially the theoretical BIOS VM kit I mentioned. If you can place the whole operating system inside a virtual machine, then it is virtually impossible to detect without taking the BIOS chip out and reading it offline. Any attempt to detect the compromise would
Re: (Score:2)
Assuming a sufficiently sophisticated VM based rootkit, it couldn't be done. Any attempt to write back to the firmware would be subverted. Any attempt to verify what was already there would pass as the rootkit would tell the verification utility exactly what it wanted to hear.
The only way to do it would be to physically remove the flash chip from the system and wipe it out of the box.
Re: (Score:2)
This is... (Score:2, Informative)
It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.
It'd be even better if you could make every program execute only (no reading) and hide
Re:This is... (Score:5, Informative)
I'll tell you a little secret: if you know the kernel version number and target architecture, you can build a module on another, totally different machine. Wow! 2007 technology man!
Re: (Score:1, Interesting)
Not on my internet-facing servers. No compilers and hand-compiled monolithic kernel.
Re:This is... (Score:5, Interesting)
Re:This is... (Score:5, Interesting)
Re: (Score:1, Funny)
Re: (Score:1)
Re: (Score:2)
How would an unauthorized person get write access to my kernel or operating system files? I keep them all password protected, and I only allow root login on the console.
I do hope your joking but in case you aren't: Attackers gain access by exploiting bugs in either network daemons or web scripts to gain access to the machine. then if they aren't root already they try and find a local utility that can be used to elevate their privileges.
Just because it's Linux does not mean it's secure. If you have any
Re: (Score:3, Insightful)
Point well taken, but I do wonder how often these kind of exploits actually happen in the wild on linux or on commercial unixen.
Often enough. Exploits will be written for any OS that has a decent return on investment time wise. These days that means both Windows and Linux. You could actually see this in when the better architected OpenSSH became the standard for most Linux distros the move to Linux brought a bunch of new eyes to go over the code and a bunch of exploits got discovered in a really short
Compiler is Irrelevant (Score:4, Informative)
Anyway - if the person has root on the box (which they need to install the rootkit anyway), then they can just ship up THEIR OWN COMPILER if they want to regardless.
Re: (Score:1)
Re: (Score:2)
Re:Compiler is Irrelevant (Score:5, Insightful)
First, let me introduce you to the file command, which can tell me all about your arch. Or failing that, less, or any other program than can read any binary on your system. Your binary executables necessarily include information about their format, including their architecture.
Second, why are you worried about compilers and version numbers if you're so sure people can't load modules anyway? What exactly are you trying to protect? There's something to be said for a minimalistic system, but you've yet to explain how having a compiler installed poses any sort of realistic security threat.
Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel? Even if you disable all the ways to do this without rebooting -- kexec() and /proc/kcore, probably among others -- they could always reboot the machine. Sure, you'd notice the reboot, but would you be able to detect their change after the reboot?
I'd also like to mention that OS-enforced append-only files are a poor substitute to logging to a hardware-enforced WORM drive, particularly if we're talking about rootkits. You're still fundamentally relaying on the OS to provide protection, which isn't reasonable when a rootkit has been installed.
Re: (Score:2)
Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel?
This reminds me of a certain rootkit that would copy its own kernel into your swap partition. On reboot the new kernel knows not to use that portion of the swap partition that is now currently occupied by the kernel.
How the hell are you supposed to detect this afterwords?! Oh yea, it would have to modify your boot configuration.. which is detectable.
Still neat though.
-metric
Re: (Score:2)
Re:This is... (Score:4, Funny)
Bruce Schneier (Score:2)
More on http://geekz.co.uk/schneierfacts/ [geekz.co.uk]
This would have been more appropriate: (Score:2, Insightful)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If any of my clients comes to me telling me someone made root on their system my advice is always to backup the data and reformat. I had a guy once refuse my advice and ran several security scanners only to miss one and have his server shut down again
Ah! No need for rootkit detector... (Score:5, Funny)
Re: (Score:2, Funny)
OSSEC HIDS (Score:2, Informative)
Pish Posh (Score:5, Funny)
Yes, but... (Score:5, Funny)
Re: (Score:1)
Re: (Score:1)
I was rooted by ftp once (Score:2, Interesting)
Root a webserver, capture ALL user data at once (Score:2)
Re: (Score:2)
Re: (Score:1)
Read Only Drives (Score:5, Interesting)
Many hard drives have jumpers that make them read only.
I thought it would be great to have all of the rarely changed portions of the operating system on a separate drive set to read only.
The only time you would move the jumper to read-write would be when you were installing updates.
Things like:
etc
Would have to always be on a read-write drive.
But having things like
What do you think? Feasible or impractical?
Re: (Score:1)
Re: (Score:1)
All the relevant data and
Re: (Score:3, Informative)
Re: (Score:1)
But then, the parent was talking about Gentoo.
Re: (Score:2, Interesting)
This is where about $5.00 worth of parts and a soldering iron will help you out.
Most all chassis have at least ONE empty slot. Buy a simple miniature SPST toggle switch and some thin wire. Take a jumper and split it electricaly, then solder a wire to each jumper socket. Solder each end of the two wires to the pins on the toggle switch. Drill an approprate hole in the slot dust cover and mount the switch, or just feed the wires out and mount the switch on something close to the box. You now have on the
Re: (Score:2)
Re: (Score:2)
Yeah, that's quite easy on a publicly exposed machine where almost weekly some security-concerning bug is found... specially talking about Gentoo as the OS of choice!
Re:Read Only Drives (Score:5, Interesting)
Amazingly enough, I can draw on 25 year old experience on this one, sort of. Back in the early 1980s, I ran a BBS on a dialup TRS-80. The floppy drives, I put toggle switches on the front of so the read-only setting could be changed on the fly. So worst case, it'd be something you might be able to put an external switch for that jumper, outside the drive case. Maybe. Might blow up but at the time it worked great.
Re: (Score:2)
I was going to build a device that allowed me to switch between read-only and read-write remotely over TCP/IP or dial in (for servers in a data center).
This was 4 or 5 years ago and I was using Red Hat and security wasn't nearly as good (in any distribution).
I sleep better at night using hardened Gentoo, but if the read-only method were feasible I'd build it into my next server for sure and sleep even better
Re: (Score:2)
Re: (Score:3, Funny)
Yeah, there's a program you can run to flip them whenever you need to. I had to install it SUID root though.
suid? (Score:2)
i kid, i kid. i'm just an xkcd fanboy with too much time on his hands.
Re: (Score:2)
I've seen CD-based distros that have / as read-only. That certainly is possible, and the Picotux 100 computers are also set up like that on delivery: a read-only / and a read-write /usr filesystem.
You probably want to make at least /tmp, /var, /home, /mnt, the swap space, and parts of /usr read-write. I am quite certain that this is possible.
Re:Read Only Drives (Score:5, Informative)
If you have more than one machine, get a dedicated syslog server and send the logs from the other machines over to it. This way logs aren't on the main machines and it is much harder to compromise the audit trail.
For businesses, get something like a Trigeo appliance [trigeo.com] and keep an eye on the behavior of everything.
Make sure all your permissions/rules are based off the concept of "default deny, explicit allow".
You could also built a monolithic kernel and not allow modules at all. Kind of hard to insert a corrupt module if the kernel isn't modular!
Charles
Re: (Score:2)
A dedicated syslog server is always a good idea if it fits the budget.
Re: (Score:1)
Or maybe by "mount -o remount,rw {partition}" ?
A dedicated syslog server is always a good idea if it fits the budget.
Sure, anything to get the logs off the compromised system is a good idea. Even piping them out to an attached printer, or an RS232 data logger, or WORM drive, or another server, or a workstation, or...
sdb
Re:Read Only Drives (Score:5, Insightful)
# mount -o remount,rw /readonly/partition
So that won't help you...
You could also built a monolithic kernel and not allow modules at all. Kind of hard to insert a corrupt module if the kernel isn't modular!
That won't help either: http://doc.bughunter.net/rootkit-backdoor/kmem-pat ching.html [bughunter.net] Most modern kernel-level rootkits do not depend on the ability to dynamically load modules.
noah
Re: (Score:2)
To help prevent them from getting root, use patches like grsecurity which add address randomization and specifically deals with
If someone has root on your server, you've already lost. You need to go into "containment" and "cleanup" mode.
Re: (Score:2)
Any rootkit that can get root could easily remount it rw.
This sounds like a good idea, but is it possible to build everything in these days? Last time I checked I think there were some things that could only be built as modules...
Re: (Score:2)
Re: (Score:2)
Other things may be compromised, but your core OS would not be. And if other things are compromised, those things are more likely to be backed up and resurface after you restore the server.
Re: (Score:3, Insightful)
Yes - your machine will be "clean" after a reboot, but because you've made it read only it will be vulnerable to whatever attack gave them root in the first place.
Any system - read/write or read only root drive can be reset to a known configuration with litt
Re: (Score:2)
Nothing will prevent all rootkits.
But having files (like
If everyone were doing this and it were built into the distributions, then yes, rootkits would be written around this strategy. But
Re: (Score:2)
Well - one thing will. Not allowing the attacker to get root in the first place.
This is what I'm trying to reinforce. There is no point in considering defenses against an attacker who has root. At that point, you are being grossly negligent if you do anything but forensic analysis and removing the machine from a public network until such time as you can do something to prevent future incursions of the type that went through. Inventing clever tricks to stop root from hac
Re:Read Only Drives = CDROM (Score:2)
Re: (Score:1)
You'd need read-only RAM - and this is what the OS is supposed to provide (process separation).
If it fails, you've lost.
And furthermore there are some things on startup that write temporary data to
So you create this file, make it unchangeable (eg. ext2/3 attribute, or simply 0555), and write malicious data there - mayb
I like to leave this up to the FBI (Score:5, Funny)
Re: (Score:2)
I always root my own boxes so that I can use that as an excuse if I ever get caught.
Is rooting Linux (Score:1)
Tinfoil Hat Time... (Score:1)
A well done rootkit is hard to detect... if you can't find a rootkit on your system then it's probably too late.
Go here now. [openbsd.org]
linuix rootkits? (Score:1, Troll)
trojan the detector (Score:2, Interesting)
Re:trojan the detector (Score:4, Insightful)
They can do that but, if you're like me, chkrootkit runs from a mounted CD-ROM. It's a little harder for them to trojan it that way.
I've always wondered... (Score:4, Interesting)
On the one hand, yeah, let's not reinvent the wheel, but on the other hand, there are advantages to building your own tools:
- you know exactly what they're doing--more complicated pre-existing tools might do more, but if you don't understand their output, they're no good.
- you don't have to trust*/audit someone else's code
- they don't do more than you need
- they don't have features that you don't know about or might misuse
- at the very least, it's a great way to learn
* yes, I know about this. [acm.org] but there are reasonable limits--I do trust that my distro came with a clean copy of gcc. OTOH, I'd rather write my own 20-line script that download someone else's that says it does the same thing as what I would write myself but that I'd have to audit for even the smallest things, like sneaking in an
if ($rooted="no")
instead of
if ($rooted=="no")
Re: (Score:1, Interesting)
Nothing wrong with that, but how do you know md5 hasn't been compromised? The only way to be sure is to boot into something else like a livecd and run md5 from there.
Re: (Score:2)
cp
each night before running the tool? Or, as someone else suggested, leave md5 on with another name? I'm sure most rootkits wouldn't notice if 'zsh' was actually a copy of 'md5.'
I'm not talking about a bulletproof tool for the NSA. I'm just interested in something basic that would do the trick for most people.
Re: (Score:2)
cp
each night before running the tool? Or, as someone else suggested, leave md5 on with another name? I'm sure most rootkits wouldn't notice if 'zsh' was actually a copy of 'md5.'
Yes, it would be trivial. Unfortunately, it wouldn't do you much good these days. Modern rootkits (on Windows, Linux, what have you), are kernel based. It doesn't matter how trusted your md5, ls, ps, and other binaries are if your kernel is not reporting accurate inform
Re: (Score:2)
Re: (Score:2)
Better yet, add a random amount of crap onto your key binaries so that they're non-standard, then get checksums with some theoretically known-good checksummer. Keep an eye on them automatically, and every now and then get th
Meh, I don't trust those tools (Score:5, Funny)
You keep using that word... (Score:2)
...I don't think it means what you think it means.
http://www.answers.com/impervious&r=67 [answers.com]
chkrootkit (Score:3, Informative)
Searching for OBSD rk v1...
Searching for suspicious files and dirs, it may take a while...
so I wouldn't worry too much if you see something that looks iffy before you check it out (I'd have been annoyed if I just reinstalled my OS just to find the same thing happening again). It will also show your ethnet port as being in "sniffer". Anywho, best practices can minimize the risk to pretty much 0... oh, but for God's sake PLEASE switch off remote root access on ssh over default ports, ideally switch it off altogether (If you need it please learn how to use it). Ssh coupled with an easily broken root password is the single biggest cause of rootkits... and a huge
Re: (Score:2)
Which begs^H^H^H^Hdemands the question: why doesn't any distro install one of the many ssh brute-force prevention utilities out of the box? Some of them don't even need to look at logfiles, they're simply common-sense firewall rules.
Re: (Score:2)
Bigger list (Score:1)
Linux rootkits (Score:1)
Bye bye rootkits, viruses, back doors and the like.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
If your system is compromised, nothing is trustable. Not the kernel, not the sync utilities (which on a FreeBSD system would be the first thing to alter), not anything. I did not miss the part about syncing to master. If there's a rootkit it will either make sure your sync still has its changes, or it will simply not install files silently. It could also modify your compiler to produce backdoors in your executables (For more on this one in particular, look at this http://www.acm.org/classics/sep95/ [acm.org]Turing Aw
The tables have turned, Mr. Bond... (Score:2, Funny)
I don't have to worry about this. I use Windows!
Oh wait...
- RG>
Use the hash, Luke! (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1, Insightful)
A rootkit has to be pretty good to return the "correct" response. It needs to retain all previous file attributes, modify md5sum to return the correct hash, fake disk usage statistics, and do it all without causing any glitches on the system.
It is impossible to modify the environment without leaving some sort of trace. A rootkit needs to succeed before it can mask itself. The problem a rootkit faces is it cannot know