[unisog] Cisco netflow and argus (was registering servers)

John Gerth 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 mailing list