Slashdot Mirror
Detecting Rootkits In GNU/Linux
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."
I think that there is room to mention the well known tools such as AIDA and TripWire and LogCheck.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
... with the Internet Freedom Disk!
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
It's GNU/Linux. Any hacker worth his salt doesn't want to bother with archaic OSes based on Unix. He wants the 1337 stylings of Windows Vista. No sense in rootkitting a *nix box. You can't do anything with a *nix box. But an army of zombie Vista PCs, now THAT is ULTIMATE POWER!
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.
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!
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
That may have been true 30 years ago when a compiler license cost thousands. If a person has write access to your system, they can just copy a compiler binary over.
It's pretty trivial to just deduce what kernel the machine is running and build working binaries wherever you want. In fact it would be preferred, since a sysadmin is far more likely to notice a rogue gcc process sucking up CPU than a file transfer while the rootkit is being loaded.
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.
You have your l33t ninja with his army of zombie Windows boxes... ...but how do they stack up to the *nix pirates, and their FTPs on the seven seas of the intarwebs? It's the classic clashes, modernized. Who has the REAL Ultimate Power?
Fill in your four or five-letter word of wisdom here _ _ _ _ _.
I run Gentoo Linux servers for hosting email and websites, and have wanted a way to really secure the boxes.
/tmp /var/log
/usr/bin on a read-only drive seems like an effective way to protect against many, many different root-kits, worms, etc.
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?
Lose Weight and Feel Great with Isagenix
When the dark suits turn up on my doorstep with an arrest warrant on charges of attempting to crack confidential government sites I can be pretty sure my machine has been rooted.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Does root have access to /proc/kcore? If yes then an attacker with root access can modify the kernel in memory as needed. Heck there's even projects to bring this into the mainstream for carrier grade Linux (no need for those pesky reboots after a kernel upgrade):
http://pannus.sourceforge.net/
Real men and real hackers write their programs in binary code, not in stupid and bloated assembler.
How hard is it to build a basic but worthwhile rootkit detection tool with common tools? Like run `md5 /bin/*` and then ship the output of that to another machine every day for comparison to yesterday's output of that command? (Looking at other directories as well, of course.) My understanding is that many rootkits come with hacked versions of tools like 'ps' to hide themselves.
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. 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")
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
I just eyeball /proc/kcore for anything suspicious every day or so.
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.
It's simple: I demand prosecution for torture.