I remember July 19, 2001, fairly well. Yes, it was my birthday, but more profound than that was the Code Red Internet worm (en.wikipedia.org/wiki/Code_Red_worm) that was at its peak infection point. Because I was the network administrator for a school district, the summer was spent upgrading and reinstalling servers to prepare for the next year. The Code Red onslaught was a great reminder that I needed to patch the few Windows servers I administered. Unfortunately, my main Windows machine already was infected, and at that point, we weren't entirely sure how much hidden damage was done to the machines. Because it was summer, I decided formatting the hard drive and starting over would be the easiest way to be sure my server wasn't infected. Because it was summer, the downtime wouldn't really be a problem, and reformatting Windows computers tends to make them work a bit better anyway. So that's what I did.

The problem was that before I even could download the security patch, my Windows server would become infected. I tried the “race” a handful of times, but in the end, I had to put my Windows server behind a Linux firewall/proxy machine that would protect it while it updated. I won't lie; using Linux to protect my Windows server during the upgrade did make me a little smug. I even bragged to my fellow school technology directors (most of whom run Microsoft shops) about how impervious Linux is to attack.

Then, in September, the Nimda worm (en.wikipedia.org/wiki/Nimda) crippled my Linux Web server.

Granted, my server didn't get infected with the worm, because like Code Red, Nimda targeted Microsoft's IIS server. The sheer number of concurrent infection attempts, however, effectively caused my poor little Web server to stop responding. It was then that I really began to realize how security is an active process, not just the result of smart planning. We don't all need to be security experts, but if we're in charge of any computers, we need to be aware of the tactics and tools available to protect them. Here at the Linux Journal office, we decided the perfect way to start the new year would be with an issue devoted to security.

One of the first obstacles to securing your infrastructure effectively can be the sheer size of it. It's true that command-line administration is quick and easy, but if you have hundreds or thousands of servers, even the command line can be overwhelming. Kyle Rankin shows us a few shortcuts he uses to connect to multiple servers via SSH.

Our own local security expert, Mick Bauer, continues his series on securing Samba. Mick shows us that the best offense is a good defense, and starting with a secure configuration is the key to sysadmin bliss. Jeramiah Bowling broadens the scope and details how to test our entire system's security. If you don't test your security for vulnerabilities, you can be sure someone else will.

If you want to get real serious about catching the bad guys, be sure to read Grzegorz Landecki's article on detecting botnets. They tend to be scary, because a large enough botnet can take down even a secure server. Early detection is key—well, that and a geographically diverse network infrastructure. For most of us though, early detection is about the best we can do.

Speaking of bad guys, this issue will make you happy to know that Kyle Rankin hasn't chosen the Dark Side of the Force. This month, he also explains how to attack computers that aren't even powered up. Did you think powering off a computer cleared the RAM? I did, but Kyle gives us a whole new reason to stay up at night worrying. His article is a tutorial on how to exploit the few seconds it takes for RAM to “forget” its contents. I'm sure the article is intended to teach us how to best secure ourselves from malicious attempts to do the same, but it's truly scary how simple the process can be.

This issue of Linux Journal is bound to appeal to everyone on some level. Whether you need to learn about secure authentication with PAM, or you just want to learn about new products, get a few tech tips and catch up on our latest programming column, you'll want to secure this issue under lock and key. Otherwise, someone like Kyle might sneak in and take it.