Sebastian: here at NCSA we are putting final touches on a combination NetFlows converter and NetFlows anonymizer. The NetFlows formats we convert/anonymize are Cisco 5, Cisco 7, Argus, a unified format we here use at NCSA, and maybe NFdump (maybe not NFdump we are not sure about this yet).
We should have a paper describing the tool we call CANINE by May (including the uni<->bidirectional question you ask about below). We will announce to this list when the tool itself is available for download on the a website. We identified this practical tool need about a year ago and our work is just about to come to fruition, I'm glad to hear others will use this tool as soon as we release it. Cheers! - Bill Yurcik/NCSA On Fri, 8 Apr 2005, Sebastian Krieger wrote: > Hi, > > I'm using a few x86 boxes with fprobe and flow-tools installed to > collect flows on our networks without exporting routers. In the last > months I tried a lot of the well known tools for different kinds of > reporting (accounting, incident management, security issues, etc.) based > on the logfiles produced by flow-tools. > > When analysing raw flow data without any post processing (e.g. after a > flow-print -f 5) it is sometimes really hard to interprete "who" was > responsible for bidirectional seen connection, or better which was the > source and which was the destination flow at the end. If you look at > pcap data logged by tcpdump you should always be able to interprete the > client and server role in a connection. If you have bidirectional logs > for analyses it is much easier human readable. > > I already wrote some perl code for this conversion and tried lots of > different ways to get correct bidir. data. I tried this based on ports, > protocol, timestamps and so on, but at the end I had to accept the > failure. For me the only way to get as much as possible good data is to > do a propabilistic evaluation based on ports. For example a port 80 was > more often used in the past then a port 1234 and for this bidir. seen > connection it is more propabilistic that port 80 was the destination > port. Based on this I currently do the determination of source and > destination flow. For me this brings good results in approximately > 90-95%. But this is unclean and you should never forget the possible > failures. > > Does someone know a really good tool to do this kind of conversion? Is > it really possible to determinate source and destination flows based on > netflow data? (I'm using netflow v5). > > Thanks for all info! > > Sebastian > > _______________________________________________ > Flow-tools mailing list > [EMAIL PROTECTED] > http://mailman.splintered.net/mailman/listinfo/flow-tools > _______________________________________________ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
