Building

Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 in some other posts – many practitioners have been waiting for quite some time now, is full support of RFC 6939 (Client Link-Layer Address Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC 6939 support would allow a number of things which large organizations use in their DHCPv4 based networks, incl.

  • reservations (assigning a kind-of fixed DHCP address based on the MAC address of a system which in turn allows for “centralized administration of somewhat static addresses”).
  • correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.
  • (some type) of security enforcement based on the MAC address of a host gathered in the course of a DHCP exchange (see for example slide #29 of this presentation of the IPv6 deployment at CERN, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).

So far it seemed very few components support RFC 6939. When Tim Martin mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).

Continue reading “Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6”

Continue reading
Building

Using Android without Google, Part 1

We’re using our smart phones every day to manage contacts, calendar entries, e-mail, and social communication (please note that we at ERNW still have a strict “no company data on smartphones/tablets” – which includes email). Everything is easy to use and automated syncing provides access to our data from anywhere. Data is stored in most cases on premises of a cloud service provided by the OS vendor of your smart phone – mostly Google, Apple or Microsoft. You don’t need to pay for this service – and the cloud provider could use your data for personalization and service improvements.

But from a security point of view (or just because you don’t want to share your personal information with the cloud provider) one probably wants to use all those features with a service on your own infrastructure.

Continue reading “Using Android without Google, Part 1”

Continue reading
Building

IPv6-related Requirements for the Internet Uplink or MPLS Networks

We’re currently involved in a complex RfP procedure for global network services of a large organization. As part of that we were asked to define a list of IPv6 related requirements as for the  Internet uplink and MPLS circuit connections. The involved service providers/carrier offerings will be checked to comply with those.

Continue reading “IPv6-related Requirements for the Internet Uplink or MPLS Networks”

Continue reading
Building

The Persistent Problem of State in IPv6 (Security)

I’ve discussed the heavy complexity of IPv6 and its negative impact on security architectures relying on state  – you know, “stateful” firewalls and the like 😉 – before (here and here. btw, the widely discussed IPv6-related network outage at MIT last year was a state problem as well: switches keeping track of multicast groups, of which in turn many existed due privacy extensions combined with the unfortunate relationship of MLD and ND).

One of the conclusions I’ve drawn in the past was recommending to minimize the amount of state one might use within security architectures in the IPv6 world. First, this is bad news for quite some well-established security controls that need a certain amount of state to work properly, like IDPS systems – which subsequently have hard times to work properly in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in Andrew Yourtchenko‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.

Continue reading “The Persistent Problem of State in IPv6 (Security)”

Continue reading
Building

Evaluation of IPv6 Capabilities of Commercial IPAM Solutions

Originating from a customer IPv6 deployment project, in early 2014 we defined a number of requirements as for the IPv6 capabilities of IPAM solutions, with a certain focus on security-related requirements (due to the specific environment of the project). We subsequently performed a practical evaluation of several commercial solutions, based on documentation, lab implementation and vendor communication.

Continue reading “Evaluation of IPv6 Capabilities of Commercial IPAM Solutions”

Continue reading
Building

Evaluating Behavior-based Malware Detection

Quite some organizations complemented their traditional AV solutions with a technology that can best be described as behavior-based malware detection. While we all know we are talking about products like Fireeye Email/Network Security, zScaler Web Security/APT Protection, or Cisco WSA, there are a lot of terms around to describe this type of products (such as next generation malware analysis/detection, Secure Web Gateways, or behavior-based malware detection). Those offerings typically promise the detection of malware by analyzing the behavior of ‘samples’ (which are files captured in transit of different types, such as executables or PDF documents). However, beyond the taxonomy challenges, both assessment and consulting work gets us frequently in contact with those solutions. While the main task during assessments is to bypass those solutions, the main question in the consulting context typically is “to what degree are the solutions suited to protect from common targeted attacks in the enterprise context”. Luckily, the experience from assessment work allows us to tackle this question in a structured way (which is our approach for consulting anyways: Benefit from our assessment experiences in order to provide reasonable consulting advice…).

Continue reading “Evaluating Behavior-based Malware Detection”

Continue reading
Building

How To Configure Snort to Stop IPv6 Evasion Attacks

This is a guest post from Antonios Atlasis.

Hi all,

during our BlackHat US 2014 talk titled “Evasion of High-End IPS Devices in the Age of IPv6”, among others we discussed a Snort preprocessor rule (116:456) which, when enabled (not the case by default), triggers an alert when an IPv6 datagram with nine (9) or more IPv6 Extension Headers is used (such a header was used by us to evade Snort). However, we mentioned that:

Continue reading “How To Configure Snort to Stop IPv6 Evasion Attacks”

Continue reading
Building

DHCPv6 Guard: Do It Like RA Guard Evasion

Or: When Cisco ACL Can Count Up to Five 🙂

This is a guest post by Antonios Atlasis.

Hi all,

RA Guard Evasion is well-known in the IPv6 “circles”; there is RFC 7113 Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one here, here, and this excellent write-up here that discuss this issue.
Moreover, as Jim Smalls states in his comprehensive “IPv6 Attacks and Countermeasures” presentation given at the North American IPv6 Summit 2013, DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but (only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at that time there wasn’t any known attack tool in the wild that had the fragmentation evasion built in.

Continue reading “DHCPv6 Guard: Do It Like RA Guard Evasion”

Continue reading
Building

Should IPv6 Packets With Source Address ::1 Be Processed When Received on an External Interface?

This is a guest post from Antonis Atlasis.

Most of you are probably aware of the recently discovered/-closed severe ntpd vulnerabilities (CVE-2014-9293, CVE-2014-9294, CVE-2014-9295, CVE-2014-9296, see also the initial ntp.org security notice). Some days ago the Project Zero team at Google published a blog post “Finding and exploiting ntpd vulnerabilities” with additional details. In this one they mentioned a seemingly minor but quite important detail: on a default OS X installation one of the built-in protection mechanisms of ntpd (that is the restriction to process certain packets only if they are sourced on the local machine) can easily be circumvented by sending IPv6 packets with a spoofed source address of ::1 (the equivalent to 127.0.0.1 in IPv4 which would be discarded by the kernel once received from an external source).

This brought up a number of more generic questions:

a) Should such packets having as source address the IPv6 loopback one be processed at all?
b) Which OSs process such packets?
c) How can we protect our systems from them?

Continue reading “Should IPv6 Packets With Source Address ::1 Be Processed When Received on an External Interface?”

Continue reading