In this post I’ll discuss configuration approaches for systems which usually have been configured with “static” IP parameters in the IPv4 age/context (like servers in data centers). When it comes to IPv6 there are more options and we’ll have a look at their implications and potential advantages/disadvantages.
This is the 3rd part of this loose series on considerations of (operating) DMZs in 2016 (part 1 on the role of a DMZ is can be found here, part 2 on reverse proxies here).
Again, I dare to deviate a bit from the plan & order I initially had in mind – today I will cover one process whose maturity may significantly influence the overall security posture of a DMZ environment: firewall rule management.
How to provide updates to IoT devices – yes, I’m aware this might be a overly broad generalization for many different devices – has been the topic of many discussions in the last years (for those interested the papers from the “Internet of Things Software Update Workshop (IoTSU)” might be a good starting point).
Given Matthias and I will moderate the respective session at tomorrow’s IoT Insight Summit I started writing down some points that we consider relevant in this context.
As we all know an IPv6 enabled host can have multiple addresses. In order to select a source address for a to-be established outbound connection, operating systems implement a source address selection mechanism that evaluates multiple source address candidates and selects the (potentially) best candidate. Criteria for this selection are defined in RFC6724 (which obsoletes RFC 3484).
Some years ago I discussed the meaning of the term “control” in this post, but at the time I was mainly referring to the noun “control”. Given I’ll extensively use the term “control” as a verb in the next parts of “the DMZseries” and some upcomingtalks I reflected a bit on its meaning (as a verb). In the following I’ll lay out the definition/understanding to be employed at those occasions.
This is the second part of a series with considerations on DMZ networks in 2016 (part 1 can be found here). Beforehand I had planned to cover classification & segmentation approaches in this one, but after my little rant on how “the business” might approach & think about reverse proxies in the first part, I felt tempted to elaborate a bit further on this particular topic. I kindly ask for your patience 😉 and will digress a bit for the moment.
I’m currently involved in a “DMZ Redesign” effort in a sufficiently large enterprise (800+ hosts in “the DMZ”) and I thought this might be an opportunity to reflect on some aspects of “DMZ networks” in a series of posts.
After seeing Christopher’s post I decided to create a proof using GNS3 and Virtualbox.
The aim is to perform the exact attacking using Antonios Atlasis’ Chiron tools and run a Wireshark packet capture to prove the hop limit drops below 255.
I won’t be in Vegas for Black Hat this year as there’s a direct conflict with one of my kids’ birthdays, but I thought one or another reader might find it helpful to get some inspiration as for selecting the talks to catch (not least as there’s so many interesting ones). I hence decided to quickly write this post.