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.
