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:
Hi,
didn’t find the time so far to post a short blog about HITB Amsterdam so far… but here we go.
Unfortunately I couldn’t arrive in AMS earlier than Thursday evening so I missed the first day (and – from what I heard – some great talks). However we went out for dinner that night with the likes of Andreas (Wiegenstein), Jim (Geovedi), Raoul (Chiesa), Travis (Goodspeed), Claudio (Criscione) and some more guys and I had some quite good conversations, both on technical matters and on Intra-European cultural differences ;-). Btw: thanks again to Martijn for taking care of the restaurant.
A couple of hours ago Christopher (Werny) and I gave this presentation at the Heise IPv6-Kongress, which overall was a quite interesting and well-organized event bringing together a number of practitioners from the field. While yesterday’s talks were dominated by a certain euphoria and optimistic pioneer spirit, the second day featured some security talks which induced slight shadows to the brave new world of IPv6 ;-). I particularly enjoyed meeting Eric Vyncke from Cisco (one of the two authors of this great book) and Marc “van Hauser” Heuse who released a new version of the THC-IPV6 tool set today. We had some fruitful discussions and we took the opportunity to test some of his newly implemented attacks against “RA Guard” running on a 4948E Chris and I had brought for a demo within our talk. Unfortunately – or fortunately in terms of a “from theory to reality” approach – I have to say that Marc found a quite clever way to circumvent RA Guard by putting the actual “RA payload” into a second frame following a first one mostly containing a “long & empty” destination option (after a fragmentation header pointing to the mentioned second one). To get an idea pls see these screenshots from Wireshark.
Hi,
I’ve discussed the concept of evaluating the operational “feasibility” (or “impact”, depending on your point of view) of security controls before. Some people approached me asking “which considerations should we take into account when trying to understand or rate this for $SOME_SECURITY_CONTROL?”. Therefore, in the following I’ll give an unordered list of factors to consider to get an understanding of the “operational feasibility” of a given security control. Two things should be noted in advance:
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.
I can’t help myself. And I fully understand that some of you, dear readers, might get a bit annoyed by always hearing the same tune from our side. This post is, surprise!, about yesterday’s Microsoft Patch Tuesday which – as can be seen here and here – disclosed quite a number of vulnerabilities in various Microsoft components. To make the point evoked in this post’s title I’d like to draw your attention to two particular bulletins, both rated as critical.
Lots of stuff has been written about this blog post from RSA describing the (potential) details of the attack, so I will refrain from detailed comments on this piece that Marsh Ray nicely called “some of the most egregious hyperbole I’ve read in infosec”.
Just one short note. Presumably the attack, in an early stage, used a “spreadsheet [that] contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (CVE-2011-0609)”.
Some of you may have heard of the break-in at RSA and may now be wondering “what does this mean to us?” and “what can be done?”. Not being an expert on RSA SecurID at all – I’ve been involved in some projects, however not on the technical implementation side but on the architecture or overall [risk] management side – I’ll still try to contribute to the debate 😉
Feel free to correct me either by comment or by personal email in case the following contains factual errors.
Reading this advisory I’m quite tempted to emit another rant on the relationship of heavy use of 3rd party components, lack of (security) quality assurance and services running at times where they’re not needed (see second workaround here). I’ll refrain from that for today. Just wanted to let you know that the underlying vulnerability in Struts2 was initially discovered by Meder Kydyraliev who gives this talk at Troopers in two weeks. He’ll certainly describe the inner workings of this one, and others… 😉
