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.