« February 2005 | Main | April 2005 »

March 22, 2005

Lame Journalism 102

Well how about that, two Journalism articles in the same day: with all the news about the unfortunate Terri Schiavo case, it seems that the journalists covering it are not really doing their homework.

There is a lot of coverage of this quack who claims to have received a nomination for the Nobel Prize in Medicine, but with 15 minutes of searching, Kasia was able to find that it's all completely bogus.

The central matter in this case is very sad and painful, and one cannot help but have tremendous sympathy for the family. There are honorable positions on both sides, but when the news media includes such bogus quackery, it makes it much more difficult to reach a valid conclusion.

Good work, Kasia.

Posted by steve at 05:42 PM | Comments (0) | TrackBack

Lame Journalism 101

Well it seems that not everybody at Security Focus should be writing about Security: this article, Linux Kernel Security, Again breathlessly talks about how Linux is "vulnerable" to the venerable fork bomb and takes Linux distributions to tasks for not "doing something" about it.

Said by Jason Miller
It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions.

Background: In *ix of all kinds, new processes are created with the fork() system call (more or less like CreateProcess() in Win32), and a "fork bomb" is a program (shell script or C code) that does nothing but recursively launch copies of itself over and over. Eventually this fills up the process table, and it's long been an effective way to drop a machine because you have to kill all of the forkbomb processes at the same time (they keep respawning themselves).

It's so easy to do that friends do it to friends all the time. Ha ha ha.

This is a local denial-of-service attack, and all systems provide ways of limiting this behavior: max # of overall processes, per-user limits on process creation, and reservation of the last process slot for root, who presumably is going to run the "shutdown" command to make it all go away. "ulimit" is the admin's friend for this.

Jason chastises Linux vendors for shipping with unreasonably high defaults:

Said by article:
Even though a local user should be somewhat trusted, that doesn't mean you should hand them a silver platter with the ability to take down the entire machine.

It's not really a silly argument until one looks at the wider picture: this is just a single example of a local resource-exhaustion attack, of which the fork bomb is just one. There is also the "disk space bomb", a "CPU bomb" or a "memory bomb". I can think of at least three more, and surely others can too.

But only the fork bomb warrants this special attention? By Jason's reasoning, shouldn't disk quotas be enabled by default? After all, how hard could it be to pick a reasonable quota that applies to everybody out of the box?

When a user has the ability to consume a resource, he can abuse that resource, and I challenge anyone to come up with a broad set of default options works for everybody in limiting bad stuff but not the good stuff.

This is the classic "security versus usability" tradeoff, but unlike the Windows-insecure-by-default that many of us have noted, resource-exhaustion attacks are second-level attacks that are achieved by users who are already on the box (and "compromise" doesn't mean that you have to flatten your box).

If valid users are doing this, you RTFM, tune the limits and/or kick them off the system, and move on. If launched by an unauthorized user, then you have security issues a lot deeper than running out of process slots.

But there is no set of limits that works for everybody, and leaving them for the admin of the box seems perfectly reasonably to me. He suggests that BSD has picked some reasonable limits, but if he gives me fifteen minutes on his box with a C compiler, I'll drop it. There are lots of resources to exhaust (syslog bomb, anyone?).

I am dramatically more concerned about what unauthorized users are doing on my boxes than I am about the authorized ones, and "local denial of service attacks" are very low on my list of concerns. In more than 20 years of commercial system administration across a wide range of enterprises, I have yet to come across a customer with a hostile local user that required these ameliorations. Not even one.

Justin put this really well:

the issue is really only of concern to administrators who run multi-user boxes with shell access in tough environments... and they have probably been more than aware of the various resource limits necessary to keep things running safely, for ages.

The author could have written a perfectly useful article that addressed how to deal with local resource tuning - I suspect most *ix users don't even know such things exist - but instead resorted to sensationalism about a legitimate tradeoff that has been made for decades.

It is indeed a sad day: for technology journalism.

Posted by steve at 07:41 AM | Comments (0) | TrackBack

March 15, 2005

Track Traffic With Webalizer

The April 2005 issue of Linux Magazine has my Feature "Track Traffic With Webalizer - A Fast, Free and Feature-rich Log Analyzer", and it provides a decent overview of how to configure Webalizer. I have been using it for years on my own webserver, and after setting it up enough times on different systems, I asked my editor if he thought it would make a good article; he thought it would.

What I have also worked on, but haven't packaged up yet, is a much faster inverse DNS resolver for Webalizer. When processing webserver logs, many of us like to see the DNS names where traffic is coming from, but doing bulk lookups can be slow.

Webazolver spawns some user-given number of child processes to perform lookups one at a time, caching the results in a DB file for later use by webazolver. But this approach still limits the number of outstanding queries, and a few dead resolvers can really hang the process up.

I wrote a program that uses the excellent ADNS asynchronous resolver library, and in a single thread/process it's many, many times faster than the synchronous version.

I've really got to package and post it...

Posted by steve at 04:28 PM | Comments (2) | TrackBack