Jasper Bongertz is a Senior Technical Consultant at Airbus Defence and Space CyberSecurity. He is focusing on IT security, Incident Response and Network Forensics.
During the IPv6 summit on Troopers16 he had given a talk on anonymization IPv6 in PCAPs and presented his new tool.
Sometimes you need to share your packet capture files (PCAPs), but distributing them involves a risk of exposing the confidential information. To avoid this, you must sanitize your PCAPs. The goal of sanitization is to remove the critical details but keep enough information for the PCAP to still be useful. The original-to-sanitized ratio is based on your goals.
So we got these shiny new BlackBerry Q10 and Z10 device laying on the desk one morning. It’s my first BlackBerry, I have to admit, but never the less, the hole wushy GUI and touchy glass stuff wasn’t my main concern, instead i took a look at the stuff going on while you connect the phone (do i have to call it blackberry? its a phone, isn’t it?) to your computer.
This is the third (and last) part of the series (parts 1 & 2 here). We’ll provide the results from some additional tests supported by public cloud services, namely AWS (Amazon Web Services).
Lab Setup
The Amazon Elastic Compute Cloud (short: EC2) provides a flexible environment for the on demand provisioning of virtual machines of different performance levels. For our lab setup, a so-called extra large instance was used. According to Amazon, the technical specs are the following:
In the first post I’ve laid out the tools and lab setup, so in this one I’m going to discuss some results.
Description of overall test methodology
To evaluate the performance of the different setups used to analyze capture data, both tcpdump and pcap_extractor (see last post) were used. For the tests, five capture files were created using mergecap. Various sample traffic dumps were merged to five large files with different file sizes. All these files consisted of several capture files containing a variety of protocols (including iSCSI and FCoE packets). Capture files of ∼40, ∼80, ∼200, ∼500, and ∼800 GB size were created and were analyzed with both tools. For all tests the filtering expressions for tcpdump and pcap_extractor were configured to search for a specific source IP and a specific destination IP matching to iSCSI packets contained in the capture file. Additionally pcap_extractor was “instructed” to look for some search string (formatted like a credit card number).To address the performance bottleneck (again, see last post), that is the I/O throughput, two different setups of the testing environment (see above) were implemented, the first one going with a raid0 approach using four SSD hard drives, the second one with four individual SSD hard drives, each of them processing only a fourth of the analyzed capture file. Standard UNIX time command was invoked to measure the time of execution. Additionally the tools analyzing the data were started with the highest possible scheduling priority to ensure execution with the maximum of available resources. This is a sample command line invoking the test:
There is a common misconception that the sheer amount of data coupled with multiplexed channels (e.g. WDM technology) make successful eavesdropping attacks on high speed Ethernet links – like those connecting data centers – highly unlikely. This is mainly based on the assumption that the amount of resources (e.g. RAM, [sufficiently fast] storage or CPU power) needed to process large files of captured data is a limiting factor. However, to the best of our knowledge, no practical evaluation of these assumptions has so far been performed.