From May 8th to 12th I was able to attend the 74th RIPE meeting in Budapest,
Hungary. Being rather new to the networking community, I enjoyed learning a lot
of different things, not only from the various interesting talks but also from
inspiring conversations with a variety of people from all areas during the
beautiful social events.
As it was the first RIPE meeting for me, I was very thankful for the “Newcomer’s
Introduction” on Monday morning, containing a RIPE and RIPE NCC 101. It was
quite helpful to get into the mindset and understand the structure of the
meeting, like the division into different working groups based on the
participants’ interests. After familiarizing myself with the concept, I chose to
attend several sessions on Address Policy, IPv6, Routing, Open Source, and DNS
working groups besides the general plenary sessions. I’ll be reviewing those
sessions here.
The first talk after the keynote on day 2 of TROOPERS was from Christopher
Truncer about passive intelligence gathering and the analytics of that.
Christopher Truncer (@ChrisTruncer) is a red teamer with Mandiant. He is a
co-founder and current developer of the Veil-Framework, a project aimed to
bridge the gap between advanced red team and penetration testing toolsets.
His talk is mainly about defending a network from different threats by
collecting and analyzing metadata from different sources.
At the second day of the TROOPERS16 conference an interesting talk about
Advanced Persistent Threats took place from Marion Marschalek and Raphaël Vinot.
Marion Marschalek is a Security Researcher, focusing on the analysis of emerging
threats and exploring novel methods of threat detection. Marion started her
career within the anti-virus industry and also worked on advanced threat
protection systems where she built a thorough understanding of how threats and
protection systems work and how both occasionally fail.
Denial of Service (DoS) attacks aim to make services and systems unavailable to
legitimate users . If these attacks are performed by multiple sources at the
same time and for the same target, they are called Distributed Denial of Service
(DDoS) attacks. This talk “Imma Chargin Mah Lazer” describes different types of
(D)DoS attacks that are out in the wild and are seen on a daily basis by
different corporations. Furthermore, a multi-layered strategy to mitigate such
kinds of attacks has been presented within the talk. The speaker is Dr. Oliver
Matula, an IT security researcher at ERNW who holds a PHD degree in physics. He
presented the topic in a simple way which eases the delivery of information to
audience of different technical levels and backgrounds.
Christopher talked already about our WiFi Network during the
IPv6 Security Summit
and mentioned our monitoring system (we like to call “netmon”). As there were
quite some people interested in the detailed setup and configuration, we would
like to share the details with you. This year we used a widely known frontend
called Grafana and as backend components InfluxDB and collectd. During Troopers
the monitoring system was public reachable over IPv6 and provided statistics
about Uplink Bandwidth, IP Protocol Distribution, Clients and Wireless Bands.
Troopers is (unfortunately) over. It was a blast (but I may be biased ;-))!
After things have settled, I want to take the opportunity to reflect my thoughts
and impressions on the IPv6-only WiFi we had deployed during the conference. To
make sure that everybody is on the same page let’s start at the beginning.
In the last couple of years we had provided Dual-Stack connectivity on the main
“Troopers” SSID but also had an additional IPv6-only SSID. This year we decided
to spice things up and made the “Troopers“ SSID IPv6-only (with NAT64) while
providing Dual-Stack connectivity on the “Legacy“ SSID. We wanted to get a
feeling how many clients and applications can work properly in an IPv6-only
environment. We intentionally didn’t announce it vastly beforehand, hoping that
attendees would just connect to the main SSID without noticing anything. We were
aware that some applications might expose issues but, as I said , we wanted to
get a feeling to which degree problems actually occured.
this is a short write up about the Maintenance Operation Protocol (MOP), an
ancient remote management protocol from the
DECnet protocol suite. It’s old, rarely
used and in most cases not needed at all. But as we stumbled across this
protocol in some network assessments, it seems like a lot of network admins and
other users don’t know about it. Even various hardening guides we’ve seen don’t
mention MOP at all.
I recently had the pleasure to join the
64th NANOG (North American Network
Operators’ Group) meeting in San Francisco, which can be understood as one of
the largest Internet engineering conferences at all. It takes place three times
a year at different locations in North America.
What I personally like about NANOG is its strong collaborative and cooperative
character. It is not about single persons and also not too much about
spectacular projects but more about discussing technologies, ideas, challenges
and numbers. Every talk has a comparatively large time slot reserved for
discussion, which is often more than fully used. Discussion is typically
actively focused and is more time-consuming (and even more relevant) than the
talk itself. Which often is intended by the community. The climate of discussion
is almost always impressively polite and constructive, even for controversially
discussed topics.
As we historically have a strong connection to network technologies (not
surprising, given the “NW” in “ERNW” stands for “Networks”), I developed a small
script to create RFC-style ASCII representations of protocol schemes. The
following listing shows an example created for a fictitious protocol: