Christopher Werny leads the network security team for ERNW and since 2005 he is
involved in numerous IPv6 projects where he is responsible for planning,
implementation and troubleshooting existing projects.
The first topic he approached was “How to build a conference WLAN Network in
General”. The very first suggestion was to put it to the 5GHz channel because
there could be a lot of interferences in the 2.4 GHz channel. The basic idea
here is to disable 802.11b completely if it´s possible in your environment and
no-one is using it anyway. Further you should also consider nearby Wi-Fi signals
and on which channels they reside. His next recommendation was about setting the
inactivity timer to short intervals, this will avoid unnecessary resource
spending from the APs when they try to track down moved or shut down devices.
His last general recommendation from him was regarding a central DHCP Server.
This will enable the roaming from mobile devices without getting a new
IP-Address when bridged mode is enabled for the APs.
At times with many many digitally transmittable diseases, protection might be
more important than ever. When connecting your smartphone to a rogue charger, or
a foreign smartphone to your own laptop, you never now what will happen. You
never know what data crosses the lines. But there is help: A USB condom!
As the
Troopers 16 Badge
was a neat integrated device, we had the challenge to identify something to be
soldered for our attendees. The past has shown, that soldering rocks and all of
our attendees, all of you, really enjoy it! After some looking around and
roaming the Internet, we decided to go for a simple device, which would protect
you and your devices in a hostile world. A slim PCB, which will protect your
phone when having to connect it to some unknown charger or for situations when
“a mate” just wants to connect his/her phone to your laptop for “charging
purposes”.
This is a guest post from Joris van de Vis @jvis,
on his upcoming Troopers
talk.
Additional credits go to: Robin Vleeschhouwer, and Fred van de Langenberg.
As
presented at Troopers
this year, ERP-SEC research has uncovered a set of potential default accounts
related to the use of SAP Solution Manager. These default accounts might pose a
big risk to your SAP supported business as some of them have wide
authorisations. It is therefore important to check if they exist in your
landscape and change the default passwords.
I gave a presentation on Cloud Security, Compliance & Trust the other day. The
basic message was to look beyond the Cloud buzzword and see the actual
technologies which are used, understand which security principles still apply
and which need to be re-thought, giving a rough direction about regulatory
compliance in Cloud environments (which of course is non-binding, as I’m not a
lawyer), and the importance of trust evaluations (especially) when it comes to
Cloud services.
this week I gave a presentation together with
Florian Barth from
Stocard on Docker, DevOps/Microservices, and Security
— a topic and collaboration that I will definitely cover in even more detail in
the future!
I had the pleasure to sit in Mark Townsley
“Addressing Networking Challenges With Latest Innovations in IPv6”
session at Cisco Live yesterday and – somewhat inevitably – there was a mention
of Facebook having implemented an IPv6-only approach in their data centers
(here’s a talk from Paul Saab/FB
laying out details). So, with the
“IPv6 Panel” looming,
I started reflecting on “Why don’t we see this in our customer space?”. This
post quickly summarizes some observations and thoughts.
I’ll be on the
“IPv6 Panel”
at Cisco Live next week and somewhat in
preparation I started thinking about what we currently see when it comes to IPv6
deployment in our customer space. We notably observe a large gap between
“textbook planning & transition strategies” and what’s happening in real-life in
those organizations. I hence decided to write down some of these observations in
a quick series of posts to be published in the upcoming days and, maybe more
importantly, to reflect on the reasoning of this apparent mismatch between
theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.
In this part of the series (for the other parts see
[1],
[2],
[3],
[4],
[5]) we’ll
discuss approaches to implement security measures suited to protect from
IPv6-related threats on the host level.
These can be grouped into the following generic categories each of which will be
described in more detail in the following:
“Minimal machine” approach
Static configuration of IPv6 parameters
Tweaking the behavior of IPv6-related mechanisms/protocols
Local packet filtering
Some of you might recall that we published IPv6 hardening guides for both
Linux
and
Windows a
while ago and we’ll reference those exact documents below, by [Hard_Linux]
and [Hard_Windows] respectively.
In the last few years, attack techniques which fall in the categories of
“Credential Theft” or “Credential Reuse” have grown into one of the biggest
threats to Microsoft Windows environments. Microsoft has stated more than one
time, that nearly almost all of their customers that run Active Directory have
experienced “Pass-the-Hash” (PtH) attacks recently.[1] Once an
attacker gains an initial foothold on a single system in the environment it
takes often less than 48 hours until the entire Active Directory infrastructure
is compromised. To defend against this kind of attacks, a well-planned approach
is required as part of a comprehensive security architecture and operations
program. As breach has to be assumed[2], this includes a
preventative mitigating control strategy, where technical and organizational
controls are implemented, as well as preparations against insider attacks. This
is mainly achieved by partitioning the credential flow in order to firstly limit
their exposure and secondly limit their usefulness if an attacker was able to
get them. Although we spoke last year at Troopers 15 about “How to Efficiently
Protect Active Directory from Credential Theft & Large Scale
Compromise”[3], we would like to summarize exemplary later in this
post Active Directory pentest findings that we classified in four categories in
order to better understand what goes typically wrong and thus has to be
addressed. For a better understanding of the overall security goals, we
classified the findings as to belonging as a security best practice violation of
the following categories:
today I’m going to suspend the
“Developing an Enterprise IPv6 Security Strategy”
series for a moment and discuss some other aspects of IPv6 deployment.
We’ve been involved in a number of IPv6 projects in large organizations in the
past few years and in many of those there was a
planning phase in which several documents were created
(often these include a road map, an address concept/plan and a security
concept).
Point is: at some point it’s getting real ;-), read: IPv6 is actually enabled on
some systems. Pretty much all enterprise customers we know start(ed) their IPv6
deployment “at the perimeter”, enabling IPv6 (usually in dual-stack mode) on
some systems/services facing the Internet and/or external parties.
Unfortunately there’s a number of (seemingly small) things that can go wrong in
this phase and “little errors” made today are probably meant to stay for a long
time (in German we have the nice phrase “Nichts ist so dauerhaft wie ein
Provisorium”, and I’m sure people with an IT operations background will
understand this even without a translator…).
In this post I will hence lay out some things to consider when you enable IPv6
on perimeter elements for the first time.
