by Rik Farrow
<rik@spirit.com>

Special Issue Editor

This special edition of ;login: focuses on network issues, particularly intrusion-detection systems (IDSes). The summaries from the First Conference on Network Administration, as well as from the Workshop on Intrusion Detection and Network Monitoring, will perhaps whet your appetite for what follows them.

Steve Romig, a security specialist at The Ohio State University, shares some of the work he and others have been doing with flow accounting. Some Cisco routers use speeded-up mechanisms for routing and access-control lists. By collecting data from this activity, you can, to a large degree, summarize network traffic. With any large network, this is somewhat like drinking from a firehose, so Steve also talks about some of the data- summary tools they have developed to make sense of the logs.

David Brumley, a specialist for the Stanford University Network Security Team, shares some of his experience in cleaning up after incidents by describing rootkits. Rootkits have been around in some form for more than five years, but David has seen some new twists that I certainly hadn't heard of before. Rootkits help to make intruders invisible, but knowing what the kits do and how they work can help you discover these hidden packages.

Paul Brutch, a graduate student at Texas A&M and a USENIX scholar, writes about his experience in a hacking class. Unlike the classes that used to be given in Dutch universities, the purpose of the class was not to break into other organizations' computers, but to penetrate a lab network before the defending group of sysadmins could secure the systems. Guess who won? His story of techniques and tactics will help you understand what you are up against (if you plan on not being hacked).

Mudge, a hacker (in the older sense, and perhaps the newer as well), is best known for revealing various security vulnerabilities in Microsoft protocols. But I was intrigued when I learned that Mudge and some others at L0pht had been writing N-Code modules for Network Flight Recorder, so I asked Mudge if he would mind writing about what had so inspired him. Mudge shares his perspective on the state of ID systems ­ a perspective that is not far from the laments of Vern Paxson and Ed Amoroso in their invited talks during the ID workshop. He also reveals his plans for a next step in ID software.

Tim Bass (a consultant) and Dave Gruber (an Air Force communications squadron commander) discuss their own, forward spin on ID systems. Their article uses several analogies to real-world systems, but the point I came away with is that ID systems will never really work in real-world environments. Tim, of course, will happily argue this point with you, and perhaps, some day, he will be right.

John Sellens completes his series on Reliability with an article about security. Sellens' main point is that you cannot have reliable systems unless they are secure. I'd go further, and say that your systems are not well administered unless they are secure, but that's just my opinion. Sellens provides lots of good advice, including some ideas that you just might have overlooked.

Stationary in St. Louis

I recently spent several days in a train station in St. Louis avoiding talking to IDS vendors. Well, a retired train station, now a Hyatt Hotel and tourist mall. And the site of yet another security conference, the CSI NetSec. I enjoyed the conference but never entered the exhibit floor.

Sometimes vendors recognize me, and that can spell trouble because some of them think I still write for UnixWorld. Most do not recognize me but will happily rope in anyone who comes within range, whether that person needs their product or not. Some of the products are quite good, while others exhibit successful marketing: lots of flash without much substance—but with nontechnical people making the buying decisions, who cares?

And the really funny thing is that I am reminded of something that most of us put in our mouths daily, even though it is poison. Having had a chance to reread the ID workshop summaries and to listen to several presentations on hacking techniques that pass beneath the radar of the current crop of ID products, I find myself comparing ID systems to fluoride toothpaste.

Like toothpaste, ID systems can be very useful. A properly configured system can tell you about what has happened on your network and, in rare circumstances, even do something about some denial-of-service attacks, such as SYN flooding or smurfing. Fluoride toothpaste changes the chemical structure of tooth surfaces, making it more difficult for the acids produced by mouth bacteria to produce caries.

But look closely at the small print the next time you brush your teeth. You will notice the obligatory reference to the Poison Control Center, along with a suggestion that you not swallow the toothpaste, and that more than the amount normally used can be dangerous to children. Fluoride ions, found in most toothpastes, are poisonous, but tolerable in small amounts.

ID systems should also be considered mostly useful, but perhaps dangerous in large amounts. IDSes can tell you a lot about what is happening, or might be happening (the false positives), in your network, the next time you get a chance to look at the IDS. For myself, I do want to log what has been happening, but I am more inclined to follow Peter Neumann's and Ed Amoroso's suggestion: focus first on hardening your systems and infrastructure, and eliminate the targets for attacks.

And don't forget not to swallow.