Posted: 2014-07-14. Modified: 2015-04-27. Link.
In my previous blog entry I talked about 802.1X and Authorization. In this entry I'm going to expand on that and talk about some of the options you have available.
At the most basic level there are three generally used options to implement an authorization profile:
This entry I'm going to discuss VLANs
VLANs are the most common (and most basic) method of providing access-layer security. The idea is that I build up different security zones and deliminate them by VLANs. At each 'crossover' point I provide security (firewalls, access lists etc) and keep my network simple to manage.
Let's take this simple example:
By mapping a VLAN to each of these users and then having a subnet for each I can then create a simple policy. For example, I can give a regular user an IP in the range of
10.10.100.0 /24, an HR Director an IP in the range
10.10.110.0 /24 and a guest user
When any user connects to the network, I look up in my authorization policies what group the user is (perhaps from Active Directory) and push down a dynamic VLAN assignment. That user is then tied to that IP address and VLAN assignment and I can build my security from there.
For example for VLAN 100 I might apply the following Access Control List:
ip access-list extended REGULAR_USER deny ip 10.10.100.0 0.0.0.255 host 10.10.200.1 permit ip 10.10.100.0 0.0.0.255 host 10.10.210.1 permit ip 10.10.100.0 0.0.0.255 host 10.10.220.1
This works well as I can control exactly what's allowed between my inflection points. However, my security is tied to my topology. Any new VLANs, users or services mean that I will need to update all my ACL entries across my network
The challenge with VLANs is that they are notoriously difficult to keep in check. Although the above example is feasible, moves, adds and changes quickly make VLANs hard to scale. IP address pools can become exhausted and any topology change directly impacts my security architecture.
I work with organisations that have teams of people updating ACLs, Firewall rules and so on because they're caught in VLAN Hell.
VLANs also need to be spanned everywhere a user could conceivably go. If someone moves to a new office or starts hot desking, I have to rebuild a whole load of infrastructure to support that. Security policy becomes network policy and things become static on both sides for fear of breaking things.
NAT is also a tricky area here - I need to ensure that any changes or address translation respects my original security intentions.
The best way to run 802.1X on a switch is to use multi-auth. To rewind a little bit, there are four main ways to configure port security on a Cisco switch:
authentication host-mode single-host
authentication host-mode multi-host
authentication host-mode multi-domain
authentication host-mode multi-auth
The trick here is that multi-auth is clearly the best mechanism as it treats each session independently allowing for flexible deployment options. This comes at the cost though on all current IOS releases and hardware platforms of not supporting VLAN override!
The 3850, 3650 will both support this capability in a future release of code (I believe 3.7.0), meaning different users on the same access port can have completely different VLAN assignments.
VLANs are often seen as an easy way to start network security and are certainly the easiest when the network is simple and well-defined. However, it becomes quickly unmanagable and complex as time progresses and things change.
Is there a better way? In my next blog entry I'll discuss dACLs and how they can make things a lot simpler.