Thursday, October 18, 2012

Host Segmentation

In my previous post, I talked about the importance of separating your client workstations from your servers in a way that allowed (and monitored) only the necessary communications paths. In addition to locking down unneeded connections to servers, it is also important to limit or best eliminate, connections between hosts. As before, there isn't much need for a host to talk to another host on an enterprise network. Communications between hosts can be indicative of everything from a mis-configured workstation, a user with an unauthorized file share, an attacker on a compromised machine attempting to move laterally or launch internal attacks, or an insider up to no good. Regardless of which of these potential sources is the cause, it is traffic that should not be allowed by default. 

In a recent penetration test I was part of, from a single host compromised via a phish, we were able to laterally move to dozens of other hosts and servers without crossing a single security boundary or raising even a specter of awareness among the network defenders.  This dozens of hosts could have easily been hundreds, had we so desired, because there was nothing to stop or detect our actions.  Think about your network for a moment.  Assume Sally from Finance clicks on a link included in a phishing message and now has malware on her workstation that allows a C2 channel to the attacker.  Now assume that attacker is able to springboard from Sally's machine to other host within your network.  What controls do you have in place to stop or detect this?  I would assume the vast majority will answer "none".  *Maybe*  you will see something if Sally's machine in Richmond starts talking to Ted's machine in Pittsburgh, but until then as a network defender, you are most likely blind.

When hosts are on the same subnet, protecting against this is often difficult because layer 3 controls are not possible. The use of isolated Private VLANs (PVLANs) can provide a layer 2 solution that prevents hosts from being able to communicate with other hosts on the same VLAN without first going to the router. In the isolated PVLAN scenario, all hosts in the isolated PVLAN lack access to other hosts in the same isolated community, but are still able to access a promiscuous port which would normally lead to the layer 3 device. This permits the clients to perform their necessary daily functions, (web, e-mail, *actual* work), while eliminating a huge attack vector.  With PVLANs, intra-host communication is limited to only what you specifically allow and hosts are more segmented and contained. Host to host attacks are eliminated and lateral movement cannot occur without first passing through a layer 3 device that is capable of controlling and monitoring that traffic.  

Private VLANs are an excellent network based approach to isolating hosts because it involves less configuration than other methods such as host based firewall or IPSec rules. Of course, as network architects/engineers, we know how difficult it is to retrofit an enterprise network with something as complicated as PVLANs, so for some, using the Windows firewall might be the best option.  Controlling this with the Windows firewall is pretty simple and can be pushed through a GPO.  Just be sure to consider the IP addressing of servers and printers when writing your rule set.  

Whether host based or network based, it is vital  as network defenders that we constantly seek to narrow the attack vector.  While putting firewalls and IDS at the perimeter protect us from a large number of attacks, we must also consider the attack from inside our network and how to defend against it.

2 comments: