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?
For starters, why you do NOT keep any sort of compiler on your machine.
/proc through something like NSASecurity setup. What they dont know, they cant do much with. Obfuscation, THEN security. Keep em guessing.
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
... with the Internet Freedom Disk!
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
I PREFFER OSSEC HIDS to do this. look www.ossec.net i think this is the most powerfull agent ever :)
Marcus Maciel(ScOrP|On) System/Network Administrator/Security Officer www.underlinux.com.br
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 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
Wouldn't the first step for a rootkit developer be to add rkhunter and chkrootkit to their list of trojaned programs so that they give a "no rootkit" output? Maybe there's some protection from this, but I don't see it in the article.
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.
chkrootkit is good, I like it anyway, you can get it in Fedora Core 6 through yum (although you don't seem to be able to get rkhunter through yum any more). you have to run it as root, maybe its something about what it needs to access... anywho, you can get issues with false possitives, I just ran it and got;
/usr/lib/security
/usr/lib/security/classpath.security
....
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/.pack list
/var/log/secure!
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
*''I can't believe it's not a hyperlink.''
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.
52 65 61 6C 20 6D 65 6E 20 61 6E 64 20 72 65 61 6C 20 68 61 63 6B 65 72 73 20 77 72 69 74 65 20 74 68 65 69 72 20 70 72 6F 67 72 61 6D 73 20 69 6E 20 62 69 6E 61 72 79 20 63 6F 64 65 2C 20 6E 6F 74 20 69 6E 20 73 74 75 70 69 64 20 61 6E 64 20 62 6C 6F 61 74 65 64 20 61 73 73 65 6D 62 6C 65 72 2E
Joke's on you, Linux boys (and girls?)!
I don't have to worry about this. I use Windows!
Oh wait...
- RG>
Hey pal, this isn't a pleasantforest, so don't waste my time with pleasantries!
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,
Then even an offline inspection can be bypassed.
Besides, I'm sure a lot of businesses will take the risk of running potentially compromised server, than incur downtime.
Now, the Challenge is: What to do, to lock down system so that it is possible to verify the kernel and some userspace against a known good state and the system always gives veritable results? I think that SELinux already does a lot of that - limits root's access. You can setup its policy so, that it will only allow executing binaries and load modules from from read-only partition. The point, is to lock down the box to such state, where only physical access allows security sensitive part modification. I know this is inconvenient,but if some Good Practices [tm] are followed, then a machine once-setup can run with config unchanged for a Year or so. Have some sort of Patch Tuesday or rely on trusted and secured binaries that allow package updated only if their strong crypto signatures validate.
On an end note, securing and maintaining a system like this with existing tools (that I am aware of) is timeconsuming and hence - expensive. So, the cost-benefit ratio might be nearing the "Let's just re-roll the system on suspected cracks" scenraio. For SMB at least.
Lone Gunmen crew.
That was a couple of days after openning a port in my router for ftp. I thought it was cool to be able to transfer files to and from work. I set it up so that only users could sign in and the user would be locked into their home folder. I saw a couple of attempts to get in in the log. I was watching the monitor of my internet traffic when someone got in and instantly data was going both ways. That's when I turned the DSL router off, closed all ports on the router behind it and disabled ftp on the box. I won't be openning up ports again. When I turned the DSL router back on, I made sure that it got a new address. I need to learn a lot more before I try to run a server again. I also changed the permissions on the other partitions because they had different UID's making them available to the distro I'm currently running. Bad habits will bite you. If you leave a port open, you will get rooted.
Ops, I shuld have usd the prevuwe but in.