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
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… 😉