LAN Traffic Capture Applications Using the Libtins Library

Abstract

Capturing traffic and processing its contents is a valuable skill that when put in the right hands makes diagnosing and troubleshooting network issues an approachable task. Apart from aiding in fixing common problems, packet capture can also be used for any application that requires getting a deeper understanding of how things work under the hood. Many tools have been developed in order to allow the user to study the flow of data inside of a network. This paper focuses on documenting the process of creating such tools and showcasing their use in different contexts. This is achieved by leveraging the power of the C++ programming language and of the libtins library in order to create custom extensible sniffing tools, which are then used in VoIP (Voice over IP) and IDS (Intrusion Detection System) applications.

A Real-Time Streaming System for Customized Network Traffic Capture

“…Due to its multi-threaded design, our application ensures that processing the captured network packets and forwarding them to the Kafka topic happens in parallel. This, in turn, greatly improves the performance of the application when compared to the sequential approach used during the development of [ 14 ], which required separating packet capture and Kafka ingestion.…”

“…This is important because by going this route, we pave the way to faster execution and packet processing speed, ensuring that our captured packets are processed at pretty much the same rate as they are captured; thus, we are not limited by the packet processing time in the same way as we would be if we decided to process them sequentially. This approach provides us with far better results than the previous one detailed in [ 14 ], where all the captured packets were stored in memory using a C++ vector datatype and later processed individually and in sequence after the capture managed to consume all the desired packets, thus making the packet processing at least linear in time complexity, before considering the actual algorithm applied to each packet.…”

“…Considering all the above, the application strongly aims to provide the smallest time possible between the capture of the data and its storage in the topic, which is a big advantage when talking about the speed of processing and querying the network packets inside Kafka using KSQL queries. We can consider this a vast improvement when comparing it to our previous approach detailed in [ 14 ], where all the captured messages were written on a disk, and later ingested into Kafka in bulk.…”

“…[ 12 ] describes how a Kafka connect agent publishes network flows onto a streaming-flows topic. In our previous papers [ 14 , 15 ], we had a similar sequential approach by separating the capture process from the ingestion into Kafka topics. The paper is an extended version of reference [ 16 ] that was presented at the International Symposium on Electronics and Telecommunications and proposes a multi-threaded architecture where the packet capture and the ingestion processes run in parallel, offering a much better performance and paving the way for future improvement of existing applications.…”

“…We developed the Netlog component that captures network traffic, processes it, and inserts custom fields from each packet into an Apache Kafka topic. A network administrator can run ksqlDB queries against topics in the Kafka database as illustrated in [ 5 , 14 ], and this falls outside the scope of this paper’s objectives.…”