Infosec Kwoon

Open Source and ClamAV

2007-08-21T08:34:00.000-05:00

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

Use of Language

2007-06-22T11:19:00.001-05:00

I just finished reading a very entertaining post on Ars Technica on "The ten most hated words on the Internet." Though I'm in the field of information security, my undergraduate and graduate days in college were spent in the field of English Literature¹, so I always appreciate posts like the one from Ars Technica. After reading the post, I got to thinking about the various uses (and misuses) of the English language that drive me nuts, so I thought I'd post them here just for fun. I'd enjoy hearing about the words or phrases that drive you nuts. My feeling is that while it isn't necessary for a person to be a superlative writer/speaker, one should at least have a firm grasp of the fundamentals of their own language. Is that too much to ask? So without further ado...

Words and Phrases That Should Be Banned²

ping - As in "I need to ping Bob about that meeting tomorrow." Grrrrrr.
irregardless - This one makes my skin crawl. The word is "regardless."
the misuse of "me" and "I" - Sadly, this one is so common, most people probably aren't even aware of the fact that it is often used incorrectly. Here's an example of misuse I just heard earlier today: "If you have any questions, give John or I a call." **shudder** Here's the trick I learned from my 6th grade teacher. If you aren't sure whether to use "me" or "I," drop the other part (in the above example we would drop "John or") and the answer becomes obvious. You woudn't say "If you have any questions, give I a call," so the correct word in this context is "me."
iAnything - Personally, I thought this got old after iMac.
moot vs. mute - As in "that's a mute point." Fortunately, I don't hear this one as often as I used to, but I still here it with some regularity. The word is "moot." A moot point is a point that needn't be decided as the result of a change in circumstances.
incentivize - There are lots of words like this, where people tack on an "ize" ending and try to make a verb out of a noun. Don't do it. As soon as I hear someone use one of these made up *ize words, my first thought is "Oh, you're one of those."
"blog" as a verb - I don't really care for this word at all, but I can deal with it as a noun, as in "Have you read my blog?" What I can't abide, though, is its use as a verb. "I'll have to blog about this," or "I blogged about that yesterday."

¹Specifically, Medieval English Literature, with secondary foci on Shakespeare and Classical Greek Drama. Not the most useful of skills by today's standards, but if you ever need to conjugate a verb or decline a noun in Middle English, I'm your guy.

²If not outright banned, at a minimum there should be penalty of a heavy fine and 20 hours of community service for each infraction.

The Anti-Mentor

2007-06-20T09:33:00.000-05:00

I just finished reading an interesting article that brushed up against a theory that I've had for a while. In the article, the author refers to the "Anti-Mentor," a manager or boss that provides ample learning opportunities by way of what not to do. Specifically, the author gives reference to the "polished veneer" of his Anti-Mentor. In part, this comes down to integrity, which I discussed in a previous post. Beyond that, though, we move into the area of my theory: that such pathological disingenuous behavior is a form of psychosis. When that thought first occurred to me, it was very much tongue-in-cheek. After years of working in numerous environments, however, the facetiousness of that statement has steadily decreased. Consider the definition of psychosis from the Full American Heritage Stedman's Medical Dictionary : "A severe mental disorder, with or without organic damage, characterized by derangement of personality and loss of contact with reality and causing deterioration of normal social functioning." Speaking for myself, I can't count the number of times I've had one of these Anti-Mentors change personalities right in front of my eyes, or (my personal favorite) be helpful and supportive to me and then turn right around and try to sell me out in an attempt to conceal their own incompetence. It reminds me of a good ol' Southern phrase I heard a long time ago: "What do you expect from a pig, but a grunt?" I realize that a.) I am not a medical professional and am in no way qualified to make a diagnosis such as psychosis; and b.) I am stretching the definition of psychosis to (and probably past) the breaking point. Even so, it does help to cast the situation in a different light. These Anti-Mentors are infuriating to say the very least. However, it is probably worth viewing them with understanding and a touch of pity. When confronted with an Anti-Mentor, know them for what they are and expect that they will fundamentally always be true to their Anti-Mentor nature. Knowing what they are and what to expect from them makes dealing with them a little less painful.

Collaborative Incident Response

2007-06-15T15:45:00.000-05:00

This is an idea I've had in my head for a while now, and in light of the recent DDoS attack against Estonia, I got to thinking about it again: the need for collaborative incident response and investigation. The attack against Estonia (which was significant enough to attract the attention of NATO) was effective and performed by individuals who were at least somewhat more sophisticated than your average script kiddie. Before going any further, let me provide a quick background on the idea of collaborative incident response.

Several years ago, I was in charge of designing, training, and implementing a Computer Security Incident Response Team (hereafter referred to as CSIRT) at one of the local hospitals, at which I was employed at the time. The team was well organized and broken into complimentary (and slightly overlapping) areas of expertise. Once everyone on the team was trained and familiar not only with their role but the roles of the rest of the team members, we began performing firedrills in earnest. Scenarios were devised that the CSIRT would address, first as simply roundtable exercises, and then finally real-time, live drills. The idea of the drills was not only to hone the skills of the team, but to identify areas of weakness that we would then attempt to address before the next drill (or actual incident). All told, the drills were effective, useful, and to be perfectly honest, fun. It was at this point that I was contact by our company's disaster preparedness person who told me that there was actually going to be a city-wide disaster drill, and wanted to know if the CSIRT wanted to be included. Naturally, I said yes. I was given the basic scenario for the city-wide drill (a plane crash at the local airport), and then I devised the CSIRT drill around that. Thinking on a city-wide scale really got the ol' wheels turning. What would we do in the event of a security event massive enough to exceed the resources and abilities of the CSIRT? If this was a city-wide (or larger) event, other organizations would potentially be in the same boat, and perhaps we would be able to assist each other.

The ideal situation would be to have local businesses and other organizations come together in a community CSIRT that could be called upon in the event of a significant security incident. Obviously I'm not talking about giving people from other organizations the keys to the kingdom. Far from it. What I am suggesting is having the community CSIRT function primarily in a research and logistical support capacity. In addition, in most cases it would be possible to do this without divulging too much about your inner workings. Let's consider an example. For the sake of our discussion, let's say that our organization, Company Q, is hit with a massive security incident. Key servers are unreliable, portions of our network infrastructure are up and down, workstations all over the enterprise are crashing in a cascading fashion. An event of this size would push the security of any organization to (and quite probably past) the breaking point. Here's where the community CSIRT could come into play. Folks from our organization would be able to sit down with the community CSIRT and begin to dissect the problem. We're in the heat of the battle, so having the assistance of some people who aren't directly affected could be very useful. The initial Crisis Action Meeting would consist not only of our people but key people from the community CSIRT. This would be particularly helpful in identifying the problem as different people from different organizations will bring with them their own experience which, by definition, will be unique. They'll be able to look at the problem in ways that we might not be able to. And if this is a large enough problem, what about fatigue? On the CSIRT that I put together, we implemented the rule that during an incident, a CSIRT member could only put in 10 to 12 consecutive hours before being required to stand down and get some rest. Don't ever underestimate the impact of fatigue during a prolonged engagement. Having some extra people who could be doing things like parsing logs and the like will allow our people to focus on mitigation and recovery, and, as needed, get some rest.

To be certain, there are a number of key points that would need to be worked out in advance. The idea is that it would be a mutually beneficial relationship for all involved. Company Q has an incident so they engage the community CSIRT which consists of Company R and Company S. A month from now, maybe Company R is the one having the problem, and we (Company Q) and Company S lend a hand. It works sort of like the way villages used to fight fires back in the old days; everyone came out to help, because the next house to catch on fire could be yours. Even if your competitors are part of the community CSIRT, they can still be valuable resources.

Obviously, the members of the CSIRT would have to hold themselves to an extraordinarily high ethical standard. Members would have to be chosen carefully. A good place to start my be the local InfraGard chapter. I am the Vice President of my local chapter, InfraGard Springfield. An advantage to starting with InfraGard is that each InfraGard member is vetted by the FBI. Not to say that only InfraGard members could be on the CSIRT, but it is as good of a place to start as any. With some effort, a community CSIRT could become the de facto hub for local IT security matters.

Remote log injection

2007-06-07T10:22:00.000-05:00

I love a good, clever hack. In the past, I've espoused the virtues of OSSEC, and I use it in more interesting and creative ways on almost a daily basis. Recently, OSSEC author Daniel Cid posted a great paper on remote log injection entitled "Attacking Log Analysis Tools." I just finished reading the paper and found it very interesting and a little disturbing. I've tinkered with one of the vulnerable tools he mentions, DenyHosts, and thought it was actually a fairly handy tool. After reading Daniel's paper, though, I'll have no choice but to make sure that it isn't running on any of my systems until after a patch is released.

Nice paper, Daniel.

Just in case you weren't paranoid enough...

2007-06-01T09:54:00.000-05:00

As I've mentioned previously, I'm a big fan of Richard Bejtlich's TaoSecurity blog. Yesterday, he made a post entitled "I Have Seen the Future, and It Is Monitored." The post is interesting and very, very disturbing. From the perspective of the Infosec professional, it is enlightening and provides ample material for further research. From the perspective of the gearhead, though, it scares me silly. Given the widespread use of National Security Letters, one doesn't have to be a conspiracy theorist or paranoiac with an Orwellian, dystopian view of the future to see where this could lead. The points both for and against the level of access described in Bejtlich's post are numerous and compelling. I certainly can see the need, but I'm also not comfortable with the potential ramifications. One would hope that such access wouldn't be misused, but human nature being what it is, I've got a dollar that says it would start being misused the instant it became available.

Confusing Strategy with Tactics

2007-05-25T15:58:00.000-05:00

This seems to happen all the time. I, personally, encounter it with disturbing frequency. One of the most common mistakes I see made is the mixing of strategy and tactics by managers. I can feel some of you pulling away from me. Before you do that, though, let me explain. It is the job of management to enterprise strategy or "corporate vision," if you prefer cheezy management buzz phrases. With that, I couldn't agree more. Management has the encompassing goals and they are the ones who must solidify these goals and transmit them to the rest of the enterprise. In short, they define the "what" portion of the overall equation, in the sense of "Here is what we are going to do." Where I often see things go awry, though, is when management then goes into micromanagement mode and proceeds to tell the engineers how to meet these goals.

It is important to understand that I'm not saying that management should be completely hands off. It is their job to provide guidance and to set the rules of engagement, so to speak. Once those rules are set, though, they should step back and let the engineers work their mojo. Having been given the strategy ("what"), which includes the rules of engagement, it is the job engineers to determine the tactics ("how") appropriate for accomplishing that strategy. Let me provide an example to illustrate my point.

I once worked for Company X in the capacity of information security analyst. Though the company was fairly large, there were only two of us who were security analysts, so we were stretched pretty thin. We had a monthly enterprise vulnerability assessment that required sifting through a mountain of data. We were using a commercial vulnerability scanner that could only export the data as PDF files or as HTML files, so to do any real work with the data, PDF was out of the question, so we had to dump the data as HTML files. Fine. An inelegant solution, but still workable. Once exported to HTMl files, though, each file had to be opened individually and certain rows of data had to be exported to Excel. From there, we performed some calculations and data normalization (much of which had to be done by hand), and they that data was copied into a Word document, which was, in turn, converted into a PDF file for the final report. When I first encountered this absurd series of events, my first thought was "wow...too much effort. I'll put together a Linux box with Nessus and then I'll write some Perl scripts to parse the Nessus data and create the reports." So with the approval of my manager, I did this and I successfully reduced the amount of time required to collected the data and generate the final report from several weeks to a little more than a day. I showed the end result to my manager and he was pleased, so we were poised to roll out the new solution. As luck would have it, just prior to the roll out, the CIO decided to put forth a new corporate vision: we were to be a 100% Microsoft shop. I assumed that he meant that we were to use Microsoft products except for those cases where there was no Microsoft product, as in the case of the vulnerability scan and the subsequent report. As it turned out, I was wrong. So we had to scrap the whole project just before it was ready to go into production. The situation was explained to the CIO by my manager, at which time the CIO actually became somewhat combative and slammed his fist on his desk saying "I said that we are going to be Microsoft only, and I meant it!"

So there I was, back to having to jump through a comical number of hoops to generate what ended up being a report of less than 10 pages. "Well," I thought, "instead of having to extract this data by hand from these HTML files, I'll put together a perl script to do it for me. That'll speed things up a little bit." It was at this time that I got a call from another of the managers.

"Uh, yeah, you can't do that."

I blinked, stunned. "Can't do what, exactly?"

"Those scripts. Yeah, you can't write those in perl."

"Why not?"

"Perl isn't an approved language here at Company X."

"But they're just for my own use on my own machine. I'm just going to use them to parse some data that I'd otherwise have to parse by hand."

"Yeah, I know, but you still can't write them in perl. If you want to write them in Javascript, which is approved, that'd be ok. But you just can't write them in perl."

So there you have it. What I desperately wanted to say (and rightly did not) was "I have a job to do. If you want me to do it, then get out of my way and let me do it." This is what happens when management confuses strategy with tactics.

Managers: set the strategy, define the goals, set the rules of engagement, and convey that information to the masses. Then kindly step back a little bit and let the engineers do their jobs. Don't micromanage. It is irritating and insulting to the engineers and doesn't speak too well of your management skill.

Engineers: listen carefully and respectfully when you are given strategy, goals, and rules of engagement. Then do everything within your power to achieve those goals as quickly, efficiently, and effectively as possible. Play by the rules and give regular progress reports. And don't be patronizing. It gives us all a bad name. Besides, it never pays to antagonize management.

Clobbering Spam

2007-03-09T10:29:00.000-06:00

Chalk one up for the good guys. Yesterday, the SEC announced that it has suspended trading of 35 companies that have been accused of stock spam. Spam is an enormous problem for everyone. I have an email address that I haven't even told anyone about yet, nor have I actually used it for anything yet, and it is already receiving spam. Hopefully, the actions of the SEC portend the fall of the leviathan that is spam. We can all do our own part, too. If you haven't already, I strongly suggest you join KnujOn. Join SpamCop. Support Spamhaus. If we all take a tiny, incremental chunk out of spammers, it will be to everyone's benefit.

References

Integrity and the lack thereof

2007-03-07T09:59:00.000-06:00

Recently, I ran into a situation that highlights the absolute necessity for integrity among information security professionals. Unfortunately, in this case, I got to see what could happen when someone else demonstrates a significant lack of integrity.

In many regards, security professionals are not unlike attorneys or psychiatrists in the sense that during the course of your duties, you may become privy to certain information that, under no circumstances, can be shared. Obviously there are certain ethical obligations that come into play here. If you become aware of illegal activity or something along those lines, you are duty-bound to report it. However, when the information is clearly sensitive and there is no reason to divulge such information (other than to attempt to display to others how much you are "in the know"), to reveal such information is egregiously unethical. Here's the story that brought this to light. I'll try to keep it brief. All names have been removed from the information below.

I currently work for Company A. Several months ago, Company B, a consulting firm, approached me and asked if I would be interested in looking at a few positions they had open. Let me emphasize that they came to me. I was content with my work at Company A, but in my experience, it always pays to keep your options open. So I agreed to hear about these positions. Here's where an unfortunate series of coincidences comes into play. A person currently working for Company B (whom I have never met, by the way) used to hold my position at Company A. Let's call him Bob. Further, when Bob held my position at Company A, he worked for the same manager that I currently work for. Let's call the manager Tom. So Bob is a security person. His focus in the security field is substantially different from mine, but a security person nonetheless. For reasons I don't entirely understand, Company B asks Bob to take a look at my resume. At this point, Bob, who is ethically obligated to keep company-sensitive information private, promptly gets in touch with my manager (and his former manager, Tom) and says "Hey, Kurt is looking for a new job." So a couple weeks later, Company B makes me an offer that I'd have been a fool to decline, so I took it. I then go to my manager, Tom, and put in my two week notice. Imagine my surprise when it became clear that he already knew about this position. I did a little investigation and quickly discovered the chain of events outlined above. By blind luck, there don't appear to have been any negative ramifications of this. (Or, at least none that I'm aware of at the moment.) But that doesn't excuse the fact that it happened in the first place. If I'd had a different manager (I have a pretty good professional relationship with Tom), this could have gone very bad, very quickly. I could have been fired, it could have besmirched my professional reputation, etc., etc. In this particular case, I appear to have dodged a bullet, but I'm still pretty ticked that I got shot at in the first place. I'm reminded of the line from Shakespeare's Othello: "...he who filches from me my good name, robs me of that which enriches him not and make me poor indeed."

Here's the deal. Those of us who are security people need to hold ourselves to a very high ethical standard. Let's be honest...at some point in the past, we've all probably done things (hopefully very minor things) we shouldn't have or possibly used our position to our advantage. To some degree, that's human nature. (Think of a police officer pulling strings to get out of a speeding ticket, for example.) The key words there, though, are "in the past" and "used our position to our advantage." In this case, Bob had absolutely nothing to gain by releasing this information, other than to attempt to impress his former manager, Tom, with how "wired-in" he is. Were there some sort of governing body for security professionals, I would have reported Bob in a heartbeat. There isn't, though, so Bob gets to go on his merry way, coming into contact with sensitive information and potentially divulging it to others as he sees fit. In short, Bob should be ashamed of himself. It is incumbent upon us as professionals to give careful thought to the potential ramifications of leaking information to which we become privy. The actions of Bob were disgraceful and we, as professionals, must do our best to to stamp out such behavior whenever and wherever we find it.

Linux Service Boot Order

2007-02-02T12:58:00.000-06:00

I'm going to start including little notes and tidbits here for my own reference and hopefully for the reference of others. I'll label these as "notes."

To change the load order of services at boot time, first determine the runlevel ([root@host]# runlevel). Once done, go to the appropriate runlevel directory. I'm using CentOS and I'm running at runlevel 3, thus the directory I want is /etc/rc.d/rc3.d. There are two groups of scripts in this directory: those that start with K (these are the kill scripts) and those that start with S (these are.....SURPRISE! the startup scripts). A representative file listing might look like this:

S01sysstat
S02kudzu
S06cpuspeed
S08iptables

And so on ad infinitum. The number represents the execution order. Most recently, I wanted to move the order in which Shorewall was started. By default it was "S99shorewall." I wanted it to start right after networking (which was S10network), so I renamed the file to "S11shorewall". Simple as that.

An Open Letter to the Open Source Community

2006-12-11T13:41:00.000-06:00

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.

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.)
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.
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.
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.
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

About @#$%ing time...

2006-11-14T09:28:00.000-06:00

Microsoft has finally released a Hotfix for the Windows XP Wireless Client, and all I can say is that it is about friggin' time. Internet Storm Center has a description of the Hotfix HERE. Among other things, this fix addresses one of the most annoying things (from a Windows XP wireless perspective) I've encountered in a long time: the random Windows XP wireless network. If you've ever used Kismet in the vicinity of Windows XP machines, you know what I'm talking about. Not only does XP continue to cycle through its list of preferred wireless networks (leaks far too much information and makes it waaaaaaay too easy to determine whose laptop you're looking at), but you also get the weird random SSID strings. If you just let Kismet run for days or weeks at a time, it isn't at all uncommon to have a list of several hundred or even several thousand probe requests just because of this odd XP behavior. Here's a little piece from the Hotfix page:

In Windows XP with Service Pack 2, Wireless Auto Configuration tries to match preferred wireless networks to wireless networks that broadcast their network name. If no network matches a preferred wireless network, Wireless Auto Configuration sends probe requests to determine whether the preferred networks are nonbroadcast networks. In this manner, a Windows XP wireless client advertises its list of preferred wireless networks. An observer may monitor these probe requests and configure a wireless network by using a name that matches a preferred wireless network. If the wireless network is not secured, this network could enable unauthorized connections to the computer.

I understand Microsoft's intent in designing their wireless client to work this way. Obviously, they are trying to make the connection to wireless networks easy. They've made it easy at the expense of security. And on an OS that is notoriously difficult to protect without extensive 3rd party software.

By strange coincidence, this Hotfix was released almost to the day of the 5th anniversary of the release of Windows XP. This unusual wireless behavior has been a known issue since that time. Why in the world did it take 5 years to release a fix for this? Ok, I grant you that some of the other things that this Hotfix addresses weren't big issues 5 years ago. But that strange "parking" behavior? C'mon. If I'm a Bad Guy, all I have to do is sit in the parking lot with Kismet running and listen for Windows XP machines to start cycling through their list of preferred networks. Depending upon the number and frequency of these probes, I can start making some fairly educated guesses about these wireless clients, and with a little extra effort on my part, I could setup my trusty Linux laptop in AP mode and start trying to trick unsuspecting users into connecting to me, at which time I can start collecting usernames and passwords and whatnot. If I'm so inclined, I can then take this information and compare it to data that I pull down from WiGLE and I can even start making guesses about where these users are located and places they frequent, based solely on this hemorraghing of information from the Windows XP Wireless Client. If you use Windows XP wirelessly, install this Hotfix immediately. In addition, be very careful with who you are talking to wirelessly. You never know who might be listening.

Tools of the Trade, Part III

2006-11-08T20:04:00.000-06:00

A few more "must-have" tools to keep on hand:

3D Traceroute (http://www.d3tr.com). Portable! Gotta have a good traceroute program, and 3D Traceroute is about as good as it gets.
Sam Spade (http://www.samspade.org). Fantastic tool for IP lookups, DNS info, etc., etc. The site appears to be unavailable at the moment, but the Sam Spade tool is available for download at lots of sites around the net.
Wireshark (http://www.wireshark.org). A quality packet sniffer is just something you must have. You can't even hope to dig into what is going on throughout your network if you don't have a good packet sniffer. Formerly known as Ethereal, Wireshark is the cream of the crop.
Cygwin (http://www.cygwin.com). Cygwin provides a Linux-like environment in Windows. If you can afford the disk space, it is probably worth doing a full install. Tons of tools that we know and love from Linux now available in Windows. For me, it makes life much less stressful.

Mapping wireless networks

2006-11-08T19:13:00.000-06:00

I recently had reason to do a little wireless investigation at work. There was some concern that there may be a wireless access point attached to the network that had been setup insecurely. So I grabbed my laptop and my USB GPS device and scampered off like a kid on his way to the candy store. I did some passive investigation from the parking lot with Kismet and NetStumbler. If you aren't familiar with these tools, I can't recommend them strongly enough. When using these tools together, the WiFi data you can collect is amazing, especially if you use them in conjunction with GPS. Ok, so you've got this data....now what? That's where WiGLE comes into play. WiGLE, the Wireless Geographic Logging Engine, is a clearing house for files collected by people all over the world when wardriving, warwalking, wardancing, or warskippingaboutlikealoon. You upload your file to the WiGLE site and it crunches the data and makes the results available for download. Using one of the WiGLE clients (I really like the Java-based client, JiGLE), you can download data for any number of areas and it gives you maps and locations of all of the identified APs. JiGLE allows you to view area polygons, displaying the coverage area of a given AP, as shown here:

With a little bit of effort, you can even import JiGLE data into Google Earth. Now that, friends and neighbors, is cool; simple as that. WiGLE is a great tool to have in your back pocket.

Link

Who says network people aren't funny?

2006-11-06T10:50:00.000-06:00

I was working on a couple ideas for a few new posts and I happened to blindly stumble across this story: Jessica Simpson on Open-Source Routers. With a title like that, I had to investigate. Ahhhhh.....good humor. Don't get me wrong, it won't have you howling with laughter or anything, but it was just the thing to lighten up an otherwise dreary Monday morning.

Nifty tool

2006-11-01T13:34:00.000-06:00

Like any self-respecting techno-geek, I'm always on the lookout for new tools. I love to comb through SourceForge or Freshmeat, looking for new and interesting software. Ever since VMware released VMware Server as a free product earlier this year, I've spent a lot of time messing with it, trying new and interesting ways to use it, etc. I've been doing some really interesting stuff with it recently (I'll make an extensive post on this at some point in the near future), and have downloaded and experimented with dozens of the free Virtual Appliances. Just when I thought that VMware couldn't be any cooler, I found this: VMware Converter. It essentially takes an image of a running Windows machine and creates a virtual machine. They claim that you can image a hot machine without actually disturbing the machine being imaged. And it can all be done over Ethernet. And (this is arguably the best part), it is free. It can also create VMs from older VMware formats, Symantec Bacukp Exec System Recovery, and Microsoft Virtual Server/Virtual PC. I haven't had a chance to extensively test this yet, but assuming it lives up to their claims, this has so much potential, I don't even know where to being.

Kudos to the VMware folks.

Well Said

2006-10-31T08:50:00.000-06:00

Let me begin by saying that I've be a big fan of Richard Bejtlich's TaoSecurity blog for quite a while. If you've never visited his site, go there now. Truly excellent information from a man who clearly knows what he's talking about.

I started this morning as I do every morning: by reading about 2 dozen security related RSS feeds. After glancing at the latest crop of exploits and vulnerabilities, I saw that there was a new post on TaoSecurity. Bejtlich does a fantastic job of responding to a number of posts made on the DailyDave list. In short, he responds to a number of assertions that traditional IDS (particularly Snort) is of no value.

<rant>
My feeling is that if you think it is of no value, it is probably because you aren't using it correctly, aren't using it in the proper manner, and/or aren't using it in the correct location. It reminds me of when I was a kid and used to try to help my dad when he was working on the car or the lawnmower or whatever. I remeber him telling me that "a lot of it boils down to using the right tool for the right job." Can you just throw a Snort sensor any ol' place on your network and expect it to do everything? Of course not. You place them strategically, significantly modifying the rules policy based on where you're placing them and what you intend the primary purpose of the sensor to be. Should you use Snort or Bro or SHADOW exclusively? Again, of course not. The key here is an integrated approach, using a number of different tools that cover a lot of different potential attack vectors and have all of the logs and alerts sent back to a central aggregation point for detailed analysis. Event correlation using something like OSSEC (see my previous post) can go an awfully long way toward providing accurate detection of anomolies.
</rant>

Thanks, Richard, for a great, thought-provoking post on your blog.

Link

Tools of the Trade, Part II

2006-10-28T15:25:00.000-05:00

Since I just posted Part I yesterday, I'll keep this one brief. I just found a great new tool (well....new to me, anyway), so I thought I'd make a quick update.

Keyfinder (http://www.magicaljellybean.com/). Portable! Need to find out the key that was used to register Windows or Office on a particular machine? Keyfinder is the tool to use.
AbiWord (http://www.abisource.com). Portable! A great, cross-platform simple word processor. If you need something more heavy duty, you'll want to use Open Office, but if you just need a relatively simple, solid word processor, look no further.

Before I forget...

2006-10-27T15:40:00.000-05:00

Be sure to check out the blog of a friend of mine, Integrity IT Solutions. His blog is more Windows-centric than mine, but like it or not, we live in a Windows world. (At least for the time being....I patiently await the day when Linux finally rises to slay the great Redmond dragon.) Great stuff and definitely worth a look.

Tools of the Trade, Part I

2006-10-27T15:11:00.000-05:00

Things have been a little slow of late, so I thought I'd start a recurring feature: Tools of the Trade. I'll go over the tools that I use and things that I like to keep on hand. I'm a big fan of squirreling things away for later use. The trick is, of course, to remember what you've squirreled away so you can use it when the time comes. Some of these tools are portable (i.e. you can run them from a USB drive), and of course, some aren't. I'll try to identify which tools are portable, because if you're at all like me, you like to keep a nice supply of heavy-duty tools at the ready. In my experience, it pays to be prepared. During the course of this series, I'll also mention non-software tools and items that you'll want to keep around. Some are obvious (a screwdriver, for example) and some aren't (nail polish, for example......I'll go over that one another time). Also, these tools are in no particular order. That being said, let's dive in.

Nmap (http://insecure.org). This is one of those tools that I simply can't function without. If you aren't familiar with nmap, learn it. If you're already familiar with it, read the docs again. Seriously. I make it a point to re-read the docs fairly regularly, partly because it changes a little bit from version to version, but also because it does so many things, I can't remember them all.
Perl (http://www.perl.com). Ok, technically it doesn't have to be perl. Really any serious scripting language will do. (Ruby, Python, etc., etc.) The point is that you'll want to be very proficient in at least one cross-platform scripting language. It has saved my bacon more times than I can count.
Notepad++ (http://notepad-plus.sourceforge.net). Portable! A very robust text editor. If you're looking for a fancy word processor, you're looking in the wrong place. Notepad++ is a great editor that supports having multiple documents open simultaneously (I curse you, Windows Notepad) and it knows how to handle both Windows and *NIX line endings (again, I curse you, Windows Notepad). It supports syntax highlighting for lots of languages and is easily enhanced by way of plugins.
Subversion (http://subversion.tigris.org). Version control. Why version control, you ask? Personally, I hate ever having to do the same work twice, so any time I have a config file or script or something that I've put some effort into, it goes under version control. That way, if I manage to fubar the file (any SysAdmin or programmer who tells you they've never done that is lying), I can retrieve any previous version with no effort.
WinMerge (http://www.winmerge.org). Portable! Have two text files that you want to compare for differences? WinMerge is the tool for you. In my opinion, the best Windows-based comparison program.

If you have any tools that you think should be added to the list, email me at sifukurt AT yahoo DOT com.

Argus + GraphViz = Very Cool

2006-10-20T09:35:00.000-05:00

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

2006-10-12T16:33:00.000-05:00

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

Gratuitous Self-Promotion

2006-10-06T15:22:00.000-05:00

I've had several occasions over the last couple weeks to refer people to a paper that I wrote that is published at Infosecwriters.com. The paper is entitled "Securing Network Communication with Stunnel, OpenSSH, and OpenVPN." If you have need to secure your communication on a small or even modestly large basis, take a look at it. I included configs that you can copy and paste. The paper is compiled from many hours of tinkering with configs for various purposes. It doesn't take the place of the full docs for these tools, but it'll get you up and running in short order.

The Metasploit Project

2006-10-06T10:32:00.000-05:00

I love Metasploit, and it just keeps getting better and better. If you haven't already done so, head over to Metasploit and check it out.

Top 100 Security Tools

2006-10-06T09:39:00.000-05:00

Not exactly the cutting edge of new information, but I was just combing through this list again today so I thought I'd mention it here. If you haven't already, you really owe it to yourself to check out the Top 100 Security Tools. Great list of tools and well worth your time.

SnortSam, where have you been all my life?

2006-10-04T10:23:00.000-05:00

I have been using Snort for years and years. A couple years ago I started messing with Snort_inline. Great concept, works beautifully. The downside is that Snort only works in inline mode when used in conjunction with iptables. Recently I was tinkering with a Linux box in VMware's Virtual Server and I was trying to get Snort_inline to work, alas to no avail. (Side note: if you haven't played with Virtual Server, you don't know what you're missing. Go get it now and download some of the Virtual Appliances. You won't be disappointed.) So I decided to take a look at SnortSam, a tool that I've had on my list of things to mess with for ages, but I just never got around to it. One word: wow. The possibilities for things you can do with Snort and SnortSam are nearly endless. It took a few minutes to get configured correctly and there were a couple of failed attempts on my part before I finally got it configured the way I wanted. All told about 20 minutes. It affords the opportunity to leverage just about any existing infrastructure and quickly create a full-blown IPS network. SnortSam is now on my short list of invaluable tools.

SecuriTeam.com™

2006-04-26T16:20:00.000-05:00

I love this site. Loads of great vulnerability info.

Brief Rant

2005-08-31T21:40:00.000-05:00

<rant>
Every blog should have a good rant, so I figured it was time for me. In my day job, we've got several application vendors who have these GIANT applications that require telnet and don't support SSH. Personally, I think these people should be ashamed of themselves. One of the applications is a big financial system used by our HR department. The vendor flat-out won't support SSH. Let me repeat that: financial system, supports only telnet, won't support SSH. Am I the only one who has run into this? Not only do they not support SSH, they have no plans to support SSH. How a major vendor can have an application like this that doesn't support SSH is beyond me. Once again, we have a case of people who clearly don't understand the ramifications of their security-related decisions. I mean, their software ain't exactly cheap and they have very specific requirements in terms of the hardware and OS and whatnot. Ok, fine...up to this point, their requirements, though not the requirements that I would use for an application, are not without merit. But they think that it is just fine that the financial information from their system is floating around the local network in clear text. Now our network is switched, so that makes it a little better. But still, it only took about 10 seconds using Ettercap to demonstrate to the folks here how terrifying this fundamental lack of security really is. Everyone was suitably shocked, yet nothing changes.
</rant>

There. I feel much better now. Thank you for allowing me to vent. I'd love to hear if anyone else has run into this sort of problem or something similar.

TrueCrypt

2005-08-31T21:36:00.000-05:00

I recently discovered a particularly cool crypto tool, TrueCrypt. It creates virtual encrypted volumes for Windows. Years ago, back in the Win98 days, I used to use a tool called ScramDisk. As with things of this nature, though, it became unsuported and didn't work on Win2K or newer. A year or so ago, I found CrossCrypt. Good program, I liked it. But when I found TrueCrypt, I dropped CrossCrypt like a hot rock. With TrueCrypt, you create a container file that can be encrypted in a number of ways (AES, Serpent, Blowfish, Twofish, etc.). Plus, it has the extra cool feature of being able to create encrypted volumes inside encrypted volumes. So once created, the volume is mounted to the drive of your choice and you use it just like any other local drive. When you're done, you unmount it, and it is an encrypted file with your files contained safely therein. At this point, people usually ask me, "So you do stuff so important that you need to keep it encrypted?" or sometimes "Why? Do you have stuff that you don't want other people to see?" In both cases, my answer is the same: that ain't the point. The simple fact is that what I do, the files that I make (usually very uninteresting Perl files or sometimes a config file or two) aren't anyone's business other than my own, so I keep them locked up. When I leave my house, I lock my door. When I leave my car, I lock that door, too. As I see it, storing files (usually work-in-progress stuff) in an encrypted format is just a logical extension of that. Take a look at TrueCrypt. For my encryption needs, it works very well.

wipfw

2005-08-30T15:12:00.000-05:00

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.

Welcome!

2005-08-30T14:57:00.000-05:00

Welcome to the InfoSec Kwoon. Before we go any further, for those unfamiliar with the term "Kwoon," it Chinese and essentially means "school" or "place of learning." Think of it as the Chinese equivalent of the Japanese term "Dojo." I'm a life-long pratitioner of Chinese martial arts and die-hard Information Security geek, so the marriage of the two seemed a natural one for me. At any rate, I hope you'll find something useful here. I have a preference for Open Source software, so you'll no doubt find me favoring Open Source over commercial, closed source software whenever possible and appropriate. I do, however, keep an open mind with regard to security products, and I rate things fairly on how well products do what it is that they claim to do.

At any rate, thanks for dropping by. Again, welcome to the InfoSec Kwoon. Kindly don't wear your street shoes onto the practice floor. Should you need me, my office is over there. No, not that one....that's the supply closet. The one on the end. Yeah, that's it. Stop by whenever you like. The door is always open.