Ouch...

[kungfuramone9]

One of my buddies runs a fairly small time webhosting and mail service out of his basement. Three days ago he discovered that someone had used a sniffed password to get shell access and had then installed a rootkit on his main server, instantly compromising his whole setup. He's spent as much time as he can while still holding down his full-time sysadmin / coder job rebuilding his whole system from scratch...reinstall of Debian, rebuilding the kernels, the works.

Why do I post of this? For two reasons!

1. To remind all of us that even though Linux is the shit, security compromises can still happen and one ought to follow best practices whenever possible (ought one...)

2. For that reason, *use encrypted protocols*! I remember discussing ssh vs. telnet vs. ftp vs. scp a while back with some of the guys on the forums and we were all citing different examples of being too anal retentive about security vs. being right on. I would argue at this point that you should _never_ use unecrypted protocols (ftp and telnet especially) if you can use encrypted ones (ssh and scp.) It takes a few minutes to get used to it but it sure beats the hell out of some knob getting your password.

</soapbox>

[beezlebubsbum]

Thanks for that K9. How did he discover someone installed a root kit? I know that there is software on the web that can check whether or not there is a root kit present on your system. My condolences goes out to your buddy for the trouble that must have caused him.

[kungfuramone9]

Hmmm...I think rootkits generate a lot of errors and introduce performance problems, because in both instances I'm aware of (the infamous breach of the Debian project servers last November and this incident) the admins involved initially thought that there was a hardware failure going on. To be honest, I'm not sure what you look for to know for sure, although I'm sure if I was a little less lazy 10 minutes on google would clear it up.

It's a good thing I'm on vacation; it's been five days now sans my website and main e-mail address.

[beezlebubsbum]

I don't know why people would do that to other people. Makig viruses for windows is bad enough (well...), but now that they are using virus-like root kits means that we are starting to feel the effects of Linux becoming more mainstream.

[jro]

I think that as Linux becomes more mainstream and the more people begin attacking it, the stronger it will become. Most Linux patches take just a couple of days if not hours to be posted, unlike some other OS's that take months.

Of course this still wouldn't have helped your friend kungfu, as a security patches can't really stop a sniffed password.

[ZennouRyuu]

Yeah, how long did it take before that major DDoS issue was fixed way back when? Wanst it like 3 hours or somthing

[beezlebubsbum]

Can you patch linux without having to recompile a new kernel everytime? I don't know much about security updates, so I was just wondering. Also, does "apt-get update" look after security issues?

[maccorin]

if all the patch does is add a module, yes... otherwise no, although you _can_ make binary patches, nobody does, because the source is available

[jro]

Alot of times the security hole isn't even with the kernel itself. It is usually some commonly used program, like SSH. The SSH code gets patched against the security hole, you compile and install the new binary, and the kernel goes on it merry way without ever knowing the difference.

I remember a year or so ago when the security hole in SSH was found and OpenBSD had to change their slogan to "Only one remote hole in the default install, in more than 8 years!" That was about the only security patch I rushed to install just because I use SSH so much and other people use SSH to access my machine.

[kungfuramone9]

Update on the original security breach I posted about: As jro noted, the problem is often program specific rather than kernel specific. It turns out that the problem in this case was with phpix, a really good album / picture-displaying program for apache. So I'm not sure if my original assertion that it started with a sniffed password was true or not -- at this point all I know for sure is that phpix was the problem.

On the same note, the problem with phpix had already been identified and fixed; my buddy just hadn't updated the version on his system yet. Methinks he'll be quite a bit more cautious about security updates from now on...