From the latest RHN alert: ... A read buffer overflow vulnerability exists in the glibc resolver code in versions of glibc up to and including 2.2.5. The vulnerability is triggered by DNS packets larger than 1024 bytes and can cause applications to crash.

This is potentially a bad one. More information on the CERT Vulnerability Note.

Updates can be downloaded from this page [RHN membership probably required].

Michael Bauer, author of Building Secure Servers with Linux, explains some of the reasons why it's both possible and worthwhile to secure Linux for use as an Internet server platform. [an O'Reilly Network Article]

Eugenia Loli-Queru reviews the latest distribution in OS News. [via SlashDot]

Æleen Frisch: Top Five Open Source Packages for System Administrators - Number 5 [in O'Reilly Network's Newsletter].

Thanks to Jon Udell for reminding me what s l a m stands for :-)

He's right of course, I've always been fascinated by outlines, and he's the one responsible for exposing me to Radio Userland and its semi-hidden outliner.

Just when I thought I had got over my addiction - I spent a lot more time without More than Dave has spent without smoke - bam, I relapsed :-)

Well, it's comforting to know that, according to one of the Surgeon General's lesser known warnings, outlining can seriously increase your productivity.

As for logging and monitoring, I'm still and always doing a lot of it, I even use all kind of DHTML, RSS and XSLT tricks for that, but it'll take some time before I'm available to publish anything about it.

I found the August issue of Linux Magazine in my mailbox this morning, and read it over lunch. Interesting interview of Scott McNealy (dubbed as the Capitalist in the Penguin Suit) by Bob McMillan. I usually don't care for this kind of article, but this time, I did learn a few things from Scott McNealy's views towards Java, Open Source, Linux, and (of course) Microsoft. Besides, he has a sense of humor.

Martin Streicher contributed a very readable introductory piece on Web services and SOAP (which he calls a clean, refreshing standard), featuring the Google Web Service API, as well as a step by step tutorial on setting up Apache Axis Web services toolkit on a Linux server.

I cannot link directly to any of these articles, since they are not yet available online on Linux Magazine's Web site, the webmaster of which, I found out, is none other than Jon Udell.

Linux Magazine, in both printed and online form, has put some effort clarifying its layout, and it shows: readability has vastly improved.

Here our some ground rules when using SNMP and client server tools to monitor systems and network devices

1. Do not trust your firewall when using SNMP

   SNMP version 1 transfers all data, including passwords, in the clear. There are a bunch of worms and trojans these days which sole purpose is to penetrate your firewall, then start network sniffers. SNMP monitoring data will be music to crackers ears when it finally reaches them.

   So any SNMP data that travels your firewall protected internal LAN should be encrypted, which is why everyone should be using SNMP version 3 when possible.

2. Beware of client/server schemes

   Most centralized monitors rely on agent modules on on monitored hosts to listen to their requests and respond with relevant information.

   Which means that on every host, the agent will very likely open a TCP or UDP port to listen to requests. This may sound paranoïd again, but every open port is a door a potential cracker might use to access the system. It really depends on the quality of the code that opened the port.

   A more secure way of monitoring a host is having the host send information by itself, on a time or event (trap) driven basis. This avoids the always-open-port potential vulnerability issue.

   Even with SNMP, it is possible to restrict access to the SNMP database to the localhost only, and then have some monitoring code on the host itself send reports and alerts after querying the local MIB.

My laptop's disk let me down yesterday. It's now full of bad blocks. This prevented me from posting for most of yesterday's afternoon. I've managed to keep current bad blocks in check, and restored a working system partition, but this may not hold for long.

Once they have gained a large enough beachhead, it gets difficult to repel a bad blocks invasion.

Anyway, the second part of yesterday's System And Network Monitoring tutorial at the Usenix conference was focused on monitoring packages such as MRTG, Cricket, BigBrother and their ilk, plus what John Sellens call a case study. More on those tools in my upcoming SNMP OPML resources directory.

John is a real SNMP-head. He's written a very simple open source utility, Thresh, to leverage SNMP for system monitoring. I like Thresh because you can see John's experience as a sysadmin through it. It is very 'real world' oriented.

What I think John's presentation lacks is proper focus on security: to my liking, he is not paranoïd enough. More on this subject in my next post.