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."
Re:This is... (Score:5, Interesting)
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:This is... (Score:1, Interesting)
Not on my internet-facing servers. No compilers and hand-compiled monolithic kernel.
Re:This is... (Score:5, Interesting)
trojan the detector (Score:2, Interesting)
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:I've always wondered... (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: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:Read Only Drives (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 fly flipping from r/w to r/o, provided the SCSI or SATA or SAS or whatever drive interface you are using doesn't freak out when its flipped.
Not only is this simple but its also hacker proof unless they have physical access to your server, and even then they have to know what that little toggle switch does!
I was rooted by ftp once (Score:2, Interesting)