Open Source and ClamAV

I've been a user of ClamAV (and its Windows cousin, ClamWin) for years. Needless to say, I was very pleased to hear about the AntiVirus Fight Club Results. This was, according to the site, an "all-out public test of different anti-virus vendors to see how they really compare." The field was impressive, though there were some players that weren't included that I would like to have seen (specifically FSecure, NOD32, AVG, TrendMicro, and Panda). Having done a fair amount of research on AV solutions a little over a year ago, I wasn't surprised to see Kaspersky at the top of the heap. I was, however, pleasantly surprised to see ClamAV right up there, along with Norton. In some cases, ClamAV was substantially better than some of the other choices. Having only personal experience to go on, I always thought that ClamAV was one of the best, but I have never had the time (or, to be honest, the inclination) to do extensive side-by-side testing. I thought ClamAV was one of the best, and as an advocate for all things Open Source, I actively hoped it was one of the best, but I never had solid proof. Until now. Kudos to the ClamAV folks. Nicely done.

On a related note, ClamAV was recently acquired by Sourcefire, the folks who brought us Snort. As you may recall, Sourcefire went public this last March which was, I think, I good thing. I've used Snort for so long I don't even remember when I first started tinkering with it. Now with the acquisition of ClamAV, the idea of further integration between Snort and ClamAV is certainly appealing. I do have one concern with regard to Sourcefire and Snort, though. Prior to the release of GPL 3.0, the Snort license stated that it was covered by GPL 2.0 or later. Once GPL 3.0 was released, however, the license was quietly changed to state explicitly that Snort was covered by only GPL 2.0. What does this mean? Frankly, I'm not completely sure. I've read a lot of posts from Marty Roesch (Mr. Snort himself) and lots of others. Some claim that the change means nothing. Others are claiming that this is the death knell. Personally, I'm not sure what to think. I haven't stopped using Snort. I still love Snort and don't have any plans to give it up. Not yet, anyway. I have, however, started brushing up on Bro IDS, just in case I need to jump ship.

---

References

• ClamAV
• Kaspersky
• ClamWin
• Snort
• Sourcefire
• Bro IDS
  

An Open Letter to the Open Source Community

Sorry for the delay between posts. Between the whole holiday season thing, having a cold, having a 1st birthday for my younger daughter, etc., time sorta got away from me. So I figure I'll get things restarted with something that has irked me for quite some time, and it came to the surface again this morning.

This morning, I got an IM from a friend of mine. Here it is: "...but I'm NOT using ANYTHING called Ubuntu: Feisty Fawn. What kind of idiot slapped that on?" My friend touched upon something that is, I think, indicative of a significant hurdle that Open Source projects will need to overcome if they ever expect to be taken seriously and to ever have even the tiniest chance of being able to step out of the shadows. Before I dive in, let me state for the record that I am a die-hard member of the Open Source community. I am an ardent supporter of Open Source; if there is an Open Source equivalent for something, I'm using it. That being the case, while the following may come of as a bit vitriolic here and there, it is not to be taken as a slap at the Open Source community in general. It is merely an attempt at a wake-up call to the community members, and, hopefully, a call to action.

In short, I humbly ask the Open Source Community to please, please, please stop giving software (and branches, tags, and sub-versions thereof) stupid names. Seriously. I know that you may think it is funny, but it really isn't. The aforementioned "Feisty Fawn" thing just illustrates the point. There are tons of such names out there, ranging from absurd to, quite frankly, offensive. Every place I've worked, I have been a major advocate for Open Source software. It is very difficult to be taken seriously in meetings with management when you say "I have a potential solution," and then explain that your solution involves the use of Feisty Fawn, Tiny Sofa, Oinkmaster, BitchX, SheepShaver, awffull, lame, moomps, seahorse, smeg, gimp, spit, yoltia, suck, torsmo, valknut, vomit, and/or zile. Naming things, whether we're talking about naming software, children, or pets, can be a difficult process. When giving something a name, though, you have to ask yourself a few simple questions.

1. Am I using this name because I think it is clever or cute? If the answer is "yes," then keep looking. You might think it is cute or particularly clever today, but odds are that you won't always find it so amusing. (Here I cite a person my sister-in-law knows whose first name is Frodo. Yeah, as in Baggins. I'm sure Frodo's parents thought the name was funny and probably even a little cute. I've got a dollar, though, that says if we asked our friend Frodo what he thought of his name, he'd have a somewhat different opinion.)
2. Am I using this name because it is an inside joke? This is really just a slight variation on the previous question. Again, if you answer "yes," do yourself and everyone else a favor and keep looking.
3. Is this a name that I'll be happy with 10 years from now? This one seems pretty obvious, but I'm always shocked at the number of people who don't really think this one all the way through.
4. Is this name something I would be embarrassed to say in front of my grandmother? I like to call this one "the grandma rule." Here I cite such names as "suck" and "vomit." Inherently offensive? Not necessarily. Good names for software? Not even close.
5. And finally, is this a name that I'll get tired of hearing?

While we're still on the subject of what is and isn't good naming style for an Open Source project, let me touch briefly on the subject of acronyms or initials. In general, try to avoid it. Sometimes it works, take PERL and even NATO for example. Most of the time, though, it doesn't. It usually ends up producing some sort of gibberish that is difficult to spell, impossible to pronounce, and equally impossible to remember. Even in cases where you can pronounce and remember the acronym, it still may be a bad idea. The definitive example of this is GIMP (GNU Image Manipulation Program). This acronym is derogatory and offensive. I can hear people already "but it was a joke," (see question #2, above) or "it isn't intended to be insulting." To this I reply that, in general, things operate not on reality but on the perception of reality. It may not have originally been intended to be insulting, but it is. So change it, simple as that. Ethereal successfully changed its name to Wireshark, so if they can do it, so can GIMP. (The Wireshark name change came about for legal reasons so they had no choice but to change, but the name change concept applies equally well to GIMP.) And then, of course, we have the matter of recursive acronyms. Once upon a time, this was a strange tradition and apparently seemed like a good idea at the time. Here are a few examples of recursive acronyms: GNU stands for "GNU's Not Unix." Clever, huh? And PHP stands for "PHP Hypertext Preprocessor." And LAME stands for "LAME Ain't an MP3 Encoder." Please oh please oh please put an end to this. It never was funny or clever and over time, it has only become more and more annoying.

So what conclusions can we draw from all of this? Basically, take care when naming Open Source projects. If Open Source is ever to come into its own, it must be taken seriously by those who develop it. While GIMP and PHP and Oinkmaster may have become serious, production-quality software, their names suggest that at the early stage, they were each named because someone thought it was funny. If we, as members of the Open Source community, want our efforts, our software, and our plight to be taken seriously by the industry at large, we must first take ourselves seriously. This is the root of much of the resistance to Open Source software. Even Microsoft's previous attempts at disinformation about Open Source software hinge upon this. How could we expect others to take us seriously when we (apparently) don't even take ourselves seriously? Am I saying that Open Source software needs to become stuffy and boring? Of course not. But the Weltanschauung of the industry at large stems predominantly from how we perceive ourselves. Times have changed and as Darwin suggests, we must either adapt or die. As such, we must treat our work within the Open Source community with care and humility, and perhaps even a touch of reverence. To do otherwise is a disservice to our work, to ourselves, and to our community.

---

References
Don't Kill the Penguin!
Recursive Acronym
Ubuntu Development Code Names

Argus + GraphViz = Very Cool

Sometimes, it is really handy to be able to get a bird's eye view of your network traffic. I've used (and continue to use) ntop and I love it. It provides great reporting, but sometimes the bird's eye view is necessary. That's where Argus and GraphViz come into play. Here is the description of Argus from the website:

Argus is a fixed-model Real Time Flow Monitor designed to track and report on the status and performance of all network transactions seen in a data network traffic stream. Argus provides a common data format for reporting flow metrics such as connectivity, capacity, demand, loss, delay, and jitter on a per transaction basis. The record format that Argus uses is flexible and extensible, supporting generic flow identifiers and metrics, as well as application/protocol specific information.

The data that it collects on your network traffic (and it can monitor multiple interfaces simultaneously) is impressive. Argus runs as a daemon process and then you can use the client tools to extract the data from the Argus log. You can either dump the entire log or you can use filter the results for a specifc time period, or a specific host, or for a specific type of traffic. This data, then, you can feed to GraphViz to generate your graphs. The image below is generated using a Perl script that I wrote (using the Perl's GraphViz module, available at any CPAN mirror) using Argus data over a 1 hour period.


I color coded the arrows (or "edges" in GraphViz terms). The blue edges are TCP traffic, red is UDP, green is ICMP, and magenta is ARP. For TCP and UDP traffic, I've labeled the edges with the destination port. The only potential downside is that the resulting image can be a little large. Since Argus tracks all of your network traffic, this could be an invaluable tool in the face of some sort of security incident or virus outbreak.

OSSEC Host-based Intrusion Detection

I've used a lot of different file integrity monitoring programs (Samhain, Osiris, and Tripwire just to name a few), and I've messed with a number of different programs for log parsing and event correlation. Then I found OSSEC, which takes all of these things to an entirely new level. Now instead of having to manage multiple different softare packages, I can do it in one. But that's not the coolest thing. OSSEC will allow you to monitor syslog and Windows event logs as well as Apache, IIS, Snort, and numerous other logs from a single location, and it has a very robust set of rules to do event correlation. If you are so inclined, you can even take advantage of the Active Response option and have OSSEC disable accounts, drop in firewall rules, etc., etc. Plus it does file integrity monitoring on top of it all.

The server must be installed on a Linux or UNIX box, but the agent installs on just about anything, including the ubiquitous Windows platform. The agents can be configured to encrypt all of their communication with the server, or for systems that you can't install the agent (networking gear, for example), you can configure syslog on these devices to forward their syslog entries to the OSSEC server. OSSEC then seemlessly integrates all of these and creates a single, cohesive alerts file as well as breaking down alerts into daily files for easy review. Overall, very impressive. My only complaint is the reporting. The alerts file is fairly straight forward, but it is a flat text file. OSSEC comes with a few contrib scripts that will generate some text reports for you, but again, just flat text files. Ideally, I'd like to see a way to generate HTML reports (both summary and detailed reports) that are much better for sending to management and/or those who are less technically inclined. I suspect I'll probably end up writing such a tool myself as I have been unable to find one.

At any rate, OSSEC is very powerful and very cool. It does a lot of stuff very effectively, very thoroughly, and relatively easily. Check it out.

Link

wipfw

Over the last few months, I've been using wipfw as my sole firewall in Windows. It originally started as a test. I was expecting to use wipfw as the only firewall for a week or so, and then go back to using ZoneAlarm Pro. Much to my surprise, I have found no need to go back to ZoneAlarm Pro and have instead found many reasons to stick with wipfw. It is a Windows port of the ipfw firewall. It doesn't have all of the ipfw features yet. For example, you can't do traffic shaping and things along those lines. You can, however, take very tight control of your inbound and outbound network traffic. For example, we all read about the LAND attack back in March. At the time, this was a concern. (I guess Microsoft has patched this? I can't seem to exploit it any longer with hping.) However, with wipfw, I just put in a couple quick firewall rules, and I was well protected. Here was the rule I used:

"$IPFW" add deny log ip from me to me in recv eth0

It worked like a charm. I would take the rule out and would instantly be vulnerable again. Put it back in, and I could go on my merry way. I've also put in rules to have wipfw drop the sorts of traffic that will never normally occur. TCP packets with the FIN and SYN flags set, TCP flags with no flags set, TCP packets with all flags set, etc. Once the developers behind wipfw get the traffic shaping stuff in place (as well as the various other ipfw features not yet ported to wipfw), I see it as being a Windows firewall tool for those of us who like to get our hands dirty. Even in its beta stage, wipfw is a great tool and highly effective at what it does. Check it out.