Report of the Third Workshop on the Usage of NetFlow/IPFIX in Network Management

The Network Management Research Group (NMRG) organized in 2010 the Third Workshop on the Usage of NetFlow/IPFIX in Network Management, as part of the 78th IETF Meeting in Maastricht. Yearly organized since 2007, the workshop is an opportunity for people from both academia and industry to discuss the latest developments of the protocol, possibilities for new applications, and practical experiences. This report summarizes the presentations and the main conclusions of the workshop

No NAT'd User left Behind: Fingerprinting Users behind NAT from NetFlow Records alone

It is generally recognized that the traffic generated by an individual connected to a network acts as his biometric signature. Several tools exploit this fact to fingerprint and monitor users. Often, though, these tools assume to access the entire traffic, including IP addresses and payloads. This is not feasible on the grounds that both performance and privacy would be negatively affected. In reality, most ISPs convert user traffic into NetFlow records for a concise representation that does not include, for instance, any payloads. More importantly, large and distributed networks are usually NAT'd, thus a few IP addresses may be associated to thousands of users. We devised a new fingerprinting framework that overcomes these hurdles. Our system is able to analyze a huge amount of network traffic represented as NetFlows, with the intent to track people. It does so by accurately inferring when users are connected to the network and which IP addresses they are using, even though thousands of users are hidden behind NAT. Our prototype implementation was deployed and tested within an existing large metropolitan WiFi network serving about 200,000 users, with an average load of more than 1,000 users simultaneously connected behind 2 NAT'd IP addresses only. Our solution turned out to be very effective, with an accuracy greater than 90%. We also devised new tools and refined existing ones that may be applied to other contexts related to NetFlow analysis

Using the Pattern-of-Life in Networks to Improve the Effectiveness of Intrusion Detection Systems

The file attached to this record is the author's final peer reviewed version. The Publisher's final version can be found by following the DOI link.As the complexity of cyber-attacks keeps increasing, new and more robust detection mechanisms need to be developed. The next generation of Intrusion Detection Systems (IDSs) should be able to adapt their detection characteristics based not only on the measureable network traffic, but also on the available high- level information related to the protected network to improve their detection results. We make use of the Pattern-of-Life (PoL) of a network as the main source of high-level information, which is correlated with the time of the day and the usage of the network resources. We propose the use of a Fuzzy Cognitive Map (FCM) to incorporate the PoL into the detection process. The main aim of this work is to evidence the improved the detection performance of an IDS using an FCM to leverage on network related contextual information. The results that we present verify that the proposed method improves the effectiveness of our IDS by reducing the total number of false alarms; providing an improvement of 9.68% when all the considered metrics are combined and a peak improvement of up to 35.64%, depending on particular metric combination

FLAIM: A Multi-level Anonymization Framework for Computer and Network Logs

FLAIM (Framework for Log Anonymization and Information Management) addresses two important needs not well addressed by current log anonymizers. First, it is extremely modular and not tied to the specific log being anonymized. Second, it supports multi-level anonymization, allowing system administrators to make fine-grained trade-offs between information loss and privacy/security concerns. In this paper, we examine anonymization solutions to date and note the above limitations in each. We further describe how FLAIM addresses these problems, and we describe FLAIM's architecture and features in detail.Comment: 16 pages, 4 figures, in submission to USENIX Lis