Posted: 2014-07-18. Modified: 2015-04-27. Link.
In an ongoing series of blog entries, I've been talking about 802.1X, from the basics to VLAN override as part of an authorization strategy. In this entry I'm going to cover using downloadable access control lists.
Today I'm going to go through dACLs and compare them to VLANs and how they're a little bit easier (but still not perfect!)
dACLs at their core are access control lists which are applied on a session basis, rather than on an interface. This means that they are specific to a user and their current session. They are also typically managed centrally and pushed to a network device automatically.
Let's take the same example as before:
In this case I can configure my ACLs centrally. Here's an example for a regular user:
deny ip host 10.10.200.1 permit ip host 10.10.210.1 permit ip host 10.10.220.1
Note how the dACL doesn't define the source IP, only the destination? This is automatically populated by the network access device (your switch).
Unlike VLANs, dACLs don't require toplogy changes for new users. You could even mix different users in the same VLANs and provide different security to each of them. This is an increasingly common approach that I'm seeing where developers may need access to specific subnets that regular employees should not. Rather than complicating matters, a simple DACL pushed permitting them this access saves time and makes topology changes far easier.
dACLs are also centrally managed and pushed out by a RADIUS server. This means that they can be updated much quicker and without changing a network devices running configuration.
Unfortunately there are still topology dependencies with dACLs. You still need to know the IP addresses of your servers and managing interaction between identity groups becomes very tricky (how would a dACL stop an HR Director and a Regular User from P2P traffic whilst still allowing access to common resources such as printers?).
dACLs represent a good move away from VLANs and I would always consider them as a preferred starting point. VLANs are a neccessary evil in networking, but they shouldn't be the backbone on which we build network security.