Argus vs SiLK

[Chris Inacio]

This is a follow up to a thread some 12 weeks ago.  (Yes, I'm generally running that far behind - actually, I had need of looking something else up and found the thread...)

First, the comparison is probably more appropriately, YAF+SiLK vs. Argus; but that's more a nit.

Biflow versus uniflow:  YAF is actually a biflow meter.  So YAF, in its default state will in fact export biflow IPFIX based records.  SiLK, however, is not biflow.  Part of that is historical, and part of that is related to the fact that the networks we usually deal with are extremely large and show a lot of asymmetry.  So in the end, John's statement that it is uniflow is at least half true.  That said, we have other applications where we store the output of YAF in something other than SiLK, in which case we do have biflows.

Flow labeling:  YAF is getting better in this area, but it has always had the ability for the user to add more, via PCRE based regular expressions.  That said, YAF 1.2 is just about to be released with a new set of DPI tools and more ability for users to expand this capability.  It does come with the caveat that a poorly written regex will kill the system performance.

YAF 1.2 (release any day now,) does have something similar to the Argus socket support based on the Spread toolkit / library.  (http://www.spread.org) (*1) I'll leave all the details as an exercise to the reader.  So admittedly, that is a very recent change - and somewhat against the IPFIX grain.  But that said, YAF has always supported the IPFIX mediator model which allows middlemen in between the meter and the collector.  We have some mediators built, but they are very specific to special needs, and we don't generally release that code.  There is a set of code we keep lying around to easily build new ones though.

As to writing apps directly on top of SiLK records, yes we support that.  It is, in fact, well documented in the SiLK documentation, and yes it does in fact drive us nuts that no one uses the SiLK C API to do that type of thing.  Using rwcut and going to ASCII is a total performance kill.  It is also a reason we built PySiLK, because then you can build quick extensions in Python that add to SiLK.  That capability is getting pretty advanced actually.

As to realtime analysis - if you're interested, stay tuned - something is coming.


So, I can't really do a good job commenting on all the differences, because I don't know Argus.  I know Carter a bit though. :)

<really this isn't bait for Carter>
As to, "why didn't CERT/SEI just use Argus?"  That's a much longer story, if you capture me in a corner sometime you can come ask me.  The shortest version is though, that we believe in open standards, and seeding the market in that regard - and so we believe in IPFIX.  So we built another flow meter that used the open standard.  
</really this isn't bait for Carter>


regards,
Chris Inacio
inacio at cert.org

(*1) Mostly based on my guess about the Argus socket "thing", because actually, I don't know too much about it.