Compromised Security Zone = Game Over (Or Not?)

Kevin left a pretty valid comment to my Are you ready to change your security paradigm blog post:

I disagree that a compromised security zone is game over. Security is built in layers. Those host in a compromised security zone should be hardened, have complex authentication requirements to get in them, etc. Just because a compromised host in a security zone can get at additional ports on the other hosts doesn't mean an attacker will be more successful.

He’s right from the host-centric perspective (assuming you actually believe those other hosts are hardened), but once you own a server in a security zone you can start having fun with intra-subnet attacks.

Here are just a few ideas (I’m positive decent pen-testers have dozens more):

  • Spoof source IP addresses of other servers in the same security zone and execute denial-of-service attacks;
  • Combine the above with ARP spoofing and you might be able to get where those other servers can go;
  • Impersonate other servers in the same security zone with ARP spoofing to get access to the traffic sent within the security zone;
  • For the ultimate win, ARP spoof the IP address of the first-hop router (most routers might object to that, try to claim back their IP address, and generate all sorts of log messages);
  • Send ICMP redirects and persuade adjacent servers to pass traffic going to more secure zones to your server first;
  • Become a DHCP server and try to force other servers to use your server as DNS server.

All these attacks can be mitigated with proper configuration of layer-2 switches. Would your ToR switches stop them?

Most of these attacks can also be stopped by the hypervisor virtual switches... assuming you bought the proper (more expensive) licenses. Are your vSwitches configured to use them?

However, the ultimate winner is: start sending IPv6 RA messages. Most of the adjacent servers will auto-configure themselves, and if they’re running Linux (and your data center is IPv6-ignorant) they’re probably missing ip6tables configuration, making them wide open. Even if that doesn’t work, you’ll still attract all IPv6 traffic (because you pretend to be a router) and you can push the DNS settings to most of the operating systems with Other Config Flag and DHCPv6.

I’m positive one could use this trick in most IPv6-ignorant environments (particularly the virtualized ones). Would it work in your data center? No, you don’t have to share the answer, if it happens to be “YES”, go and fix the problem.

More information

Now that I mentioned IPv6 – you really can’t ignore IPv6 anymore. IPv6 security webinar has a great overview of IPv6 security implications and gotchas (check also other IPv6 webinars – you get all of them with the yearly subscription).


  1. Failure to configure Baseline IT Security Policies is ultimately a failure in resource demarcation between applications;

    -Developers may compromise the functionality of applications through using features they aught not to (Hey HQDATABASE01 is open, lets send it a daily job to test my report! Oops I used 100% CPU and the execs report is now off),

    -Administrators may make configuration mistakes resulting in a larger outage than they aught to (Lets update this DHCP pool and fatfinger it without realizing the pool is authoritative over the entire domain so in 2 months when a server reboots on the other side of the planet, it gets the wrong IP, or Hey lets inject VLANS into this switchstack from the load balancer and not the TOR Switch about it, or hey lets run all the services under enterprise admin, what could possibly go wrong?).

    -Employee's may find they have access to resources they aught not to but that are useful to them, and end up producing organic undocumented growth until that growth breaks things (Lets plug a switch in, oops we just took hold of the entire STP Tree. Hey HQDATABASE05 has an awesome web utility on it, lets run a massive report and see what happens!!!).

    -Worse of all, when applications and hardware go on the fritz (perhaps they were hacked, perhaps they just went down, maybe they failed in a non-standard way), without proper demarcation and configuration the result can be catastrophic. (Lets give out the domain admin password to the programmers is like giving a firearm to a 5 year old; your guess is as good as mine as to who or what they shoot).

    It's Worse than Failure if you're working your IT Staff to the point they're constantly putting in OT just to keep your systems operating; at that point you're near the hole at the bottom of the toilet in the IT Death Spiral (Lets invest money in fixing problems in a way they recur, not fix them permanently, and not checkup periodically to see if the cost of the permanent fix has gone down).

    A Sysadmin or developer should spend 1-2 hrs per day between studying, building or acquiring utilities to make their job easier, or familiarizing themselves and documenting their systems Thoroughly. If they are not doing this, accounting is not running cost-optimized IT; they are slave-driving themselves out of business (hey this IT Guy has an extra 2 hours he's made for himself, lets spend it instead of giving him some determination on what he should be doing like idiots, because we know better).
    1. I agree wholeheartedly with your last two paragraphs. I always thought I needed 20% of the week to work on things that I thought were important. These are things that allow one to get their head above water and really make a difference. Working smarter is better for the organization and is better for the individual. The organization really must set aside some time for the individual to actually figure out how to work smarter. Individuals can't do that when constantly buried just trying to keep the lights on.
  2. Thanks Ivan! I've been conversing with colleagues today about layer 2 security mechanisms that we need to put in place; such as setting MAC Address Changes and Forged Transmits to Reject in the VMWare Distributed Port Group configuration. (contrary to default settings, hopefully keeps a compromised VM from being used as a platform for ARP spoofing attacks) We're also deploying IPv6 now, so what you provided is good to know. For the most part, everything we host is servers and thus have static IPv4 and IPv6 addresses. (along with gateways) So, I don't think RA messages for IPv6 are a problem, but it is good to be aware of.

    Last week I asked for my company pay for a subscription for me to your webinars. I'm looking forward to your load balancer webinar and you need to get paid for all of this excellent information. :)
    1. Even though you have IPv6 statically configured on the servers, you might still get hurt by RA messages, particularly if not all servers in the subnet have IPv6 configured.

      Also, a host listening to RA messages might decide to use DHCPv6 to get the DNS server address. This behavior is probably OS/distro specific, but do deploy something like RA guard just to be on the safe side.

      .. and no, it's not available in either VMware's vSwitch/vDS or Nexus 1000V.
Add comment