[unisog] Cisco netflow and argus (was registering servers)
gerth at stanford.edu
Fri Jul 28 19:46:52 GMT 2006
On 7/28/2006 6:42 AM, Reg Quinton wrote:
> wrt. figuring out where your servers are...
> We have Cisco routers and archive flowdata as many others do with flow-tools
> from splintered.net -- I gather this is similar to the argus system Peter
> mentioned. I had assumed the information about TCP flow direction (to
> identify the server side of a TCP) was already there already ... but it
> isn't obvious to me. I can figure out from the start time information on a
> pair of related flows I can determine who called who but that seems to be an
> awkward way of getting the information.
> Are there any netflow gurus out there who know some better tricks?
I'm no netflow guru, but I did try to use it with our Cisco routers for
about a year and so did get some dirt under my fingernails.
The main difference between Cisco Netflow and Argus is that netflows are
uni-directional while argus is bi-directional. There are sometimes
heated debates in the flow community about which is "better", but IMHO
it depends on what you want to use them for. In my case the the netflows
were being generated by someone else and I was given access to them
for security purposes.
As you point out, in security applications the flow orientation is
often one of the most critical pieces of information so I wrote
code that pieced bi-directional "conversations" together by using
the connnection 5-tuple (src IP, src port, protocol, dst ip, dst prot)
which is a very decent "key" to use since one of the ports is usually
ephemeral. Using it you can often see those two-week long ssh sessions
which people at universities can have. It's also not a bad guess
for aggregating most UDP traffic.
However, I eventually gave up on the netflows when I discovered that
our routers would often drop flows entirely, especially under load,
and that they would also manage to screw up timestamps in some cases
such that the flow would have the wrong orientation (this took a
number of tedious and painful experiments to prove). Unfortunately
I had no authority or standing to pursue these problems very far
so I don't know if they're config or programming errors that might
be fixable. All I can say is that in my case the errors could reach
up to the 20% range which made me give up and switch to using argus
on "span" ports.
I've been very happy with argus. Our hardware setup is just commodity
boxes and not worth writing about as Peter Van Epp's previous posts are
very thorough. Indeed, you can set up an argus client to accept
the netflow UDP records if you want (although they remain uni-dirction)
and argus has lots of great clients to analyze the logs.
This is not to say that argus is perfect. In part, it can't be because
you can't count on totally eliminating packet drops. But even without
drops, an argus flow can end up with the wrong orientation. This
happen even with TCP because argus drops flows from its internal
scoreboard if they're no packets are seen for a long(5 minutes?) time.
Once a flow is dropped, then when it resumes, a new flow is create and
the src will be whoever sent that packet which is not necessarily the right end.
However, the overwhelming majority of flows are over in less than a minute
so numerically this problem is small (but still potentially important)
The networks we monitor are only running about 15-20M flows per day and
since argus provides a nice template for writing your own clients,
I now have a one to create csv input which we load into a mysql
table in real-time with a python script. The relational db is
very handy for doing forensic work. The group which monitors the
border routers here also uses several argus sensors and collects
more than ten times as much data as we do.
John Gerth gerth at stanford.edu (650) 725-3273 fax 723-0033
More information about the unisog