Demystifying 802.1X - Part 4 - Security Group Tagging
Posted: 2014-07-29. Modified: 2022-09-25. Link.
In an ongoing series of blog entries, I've been talking about 802.1X, starting with the basics and moving on to VLAN override and dACLs as part of an authorization strategy.
This time round I'm going to finish off Authorization and cover Security Group Tagging, a neat way that completely separates security from my network topology.
Authorization options
- VLANs
- Downloadable/Dynamic ACLs
- Security Group Tagging
This article will cover the final option, Security Group Tagging.
Security Group Tagging
Security Group Tagging is a means to provide identity within a network entirely topology-free. Unlike VLANs or using dACLs, SGTs are easier to implement, keep up to date and map to the businesses security policy.
This is achieved by tagging each frame with a security group tag. These tags are assigned at layer 2 and transported within an IEEE 802.1AE frame.
The classic example is that a AAA server provides a tag to the network access device (i.e. switch) which identifies that user. Although the tag itself is numerical, the management system (such as ISE) abstracts this in to a canonical name.
Let's take the same example as before:
Corporate Policy
| HR Server | Public Services | Intranet Services | |
|---|---|---|---|
| Regular User | |||
| HR Director | |||
| Guest User |
Note how there is no network topology information above. These users could be in the same subnets or VLANs - their identity is totally separate from my network infrastructure.
Instead, each user is tagged by the network access device. The services are also tagged either using physical infrastructure or a virtual switch such as the Nexus 1000V.
Tag Mapping
The Identity Services Engine allows you to create a full matrix based on those interaction points. For example:
The business policy above is directly mapped in to this matrix. Any empty cells will use my default policy (in this case fully permitted). This way I can blend existing ACLs and Firewalls with the enhanced security of TrustSec.
Building Rules
The rules in the screenshot above (for example "permit_https" from HR_Director to HR_Server) are topology-independent. For example:
ip access-list role-based permit_https permit tcp eq 443 deny ip
A second rule might allow anything:
ip access-list role-based full_access permit ip
These rules are automatically populated on all TrustSec devices and expanded on a per-session basis, allowing both scale and dynamic security.
Manually Defining Rules
Rules can also be manually defined. Assuming the above example where HR_Director is tagged as 2 and HR_Server has the tag of 3 then a rule controlling that interaction would appear as follows:
cts role-based permissions default full_access cts role-based permissions from 2 to 3 permit_https
Of course it's much easier to manage this centrally via ISE or similar, but it's not a requirement and you can implement TrustSec today on almost any Cisco switch, router, firewall or Wireless LAN controller.
Supporting Mixed Environments
In my next (future) blog entry I'll go through using Security Group Exchange Protocol (SXP) to support mixed environments, where TrustSec and/or 802.1AE is not widely supported.
Demystifying 802.1X - Part 3 - Authorization and dACLs
Posted: 2014-07-18. Modified: 2022-09-25. 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.
Authorization options
- VLANs (discussed in a previous blog entry)
- Downloadable/Dynamic ACLs
- Security Group Tagging
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
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:
Corporate Policy
| HR Server 10.10.200.1 | Public Services 10.10.210.1 | Intranet Services 10.10.220.1 | |
|---|---|---|---|
| Regular User | |||
| HR Director | |||
| Guest User |
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).
Scaling with dACLs
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.
Still dependent on Topology
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.
Demystifying 802.1X - Part 2 - Authorization and VLANs
Posted: 2014-07-14. Modified: 2022-09-25. 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.
Your options
At the most basic level there are three generally used options to implement an authorization profile:
- VLANs
- Downloadable/Dynamic ACLs
- Security Group Tagging
This entry I'm going to discuss VLANs
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:
Corporate Policy
| HR Server 10.10.200.1 | Public Services 10.10.210.1 | Intranet Services 10.10.220.1 | |
|---|---|---|---|
| Regular User (VLAN 100) | |||
| HR Director (VLAN 110) | |||
| Guest User (VLAN 120) |
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 10.10.120.0 /24.
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
VLAN Hell
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.
Platform Limitations
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:
- Single host - exactly what it says on the tin - one host is allowed, anything else will be rejected -
authentication host-mode single-host - Multiple Hosts - dangerous! - the first connection gets authenticated and any subsequent sessions are allowed with the same policy as the first -
authentication host-mode multi-host - Multiple Domain - authenticates two devices - an end device and a phone typically -
authentication host-mode multi-domain - Multiple Auth - authenticate each session independently and support a single phone -
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.
Summary
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.
Demystifying 802.1X - Part 1 - The Basics
Posted: 2014-07-10. Modified: 2022-09-25. Link.
A huge interest of mine right now is using IEEE 802.1X to secure access-layer networking. For many this represents a scary challenge as suddenly turning your campus network from something that is inherently open (and insecure) to something that is controlled and closed can cause endless issues.
Securing Networks - AAA Basics
As you may know, the basics of network security revolve around AAA - Authentication, Authorization and Accounting. Let's take each of these:
Authentication
Your identity. For example, do you have a valid certificate or username + password?
Authorization
What you're allowed to do. For example, you can access internal blogs, but not development servers and source code
Accounting
What you're doing. Everything that happens is logged - such as failed/successful authentications. This can be used for troubleshooting and billing amongst other things.
Monitor Mode - or how to make your life easier
The most scary thing about turning on 802.1X is that there will always be something that doesn't work. A forgotten-about printer, a Windows PC that doesn't have the service enabled or a stubborn linux user who doesn't want to play along. All of these exception cases build up in to something that quickly becomes unmanagable and a burden on the networking team.
Monitor Mode is a marketing term of failing over to MAB (which is then whitelisted) with a port configured in open mode. In other words, you see all the 802.1X logs and correctly configured devices will work just fine. Incorrectly configured (and potentially malicious) devices will still work just fine, but you'll see all the failed logs to help pinpoint these issues.
I know organisations that have run in Monitor Mode for years and it works really well for them. Having the logs without the headaches is a good balance for their business needs, whilst having the option at any time to switch to a full 802.1X deployment.
The Authentication-focus problem
I like to call out what I call the Authentication-focus problem as a key failure when assessing network security and the roll-out of 802.1X. All too often the focus is on purely authenticating users and based on this we let them on the network or not.
In a traditional world where a user would have a fixed desktop PC or could be reasonably expected to just have a single laptop this worked OK. If they logged in with their AD credentials then they were authenticated fine, so let's give them full network access! No authentication? No access!
The problem with this approach is that it's all or nothing - exception circumstances happen. If someone brings their own PC in then unless I have a full certificate infrastructure set up, the user can log in with PEAP and gain full access. Likewise, support issues occur when authentication fails due to expired passwords or new PCs that haven't been setup for Active Directory.
Authorization
Building in high quality authorization is the true answer. Using a central policy server such as the Identity Services Engine, additional information can be gathered about a device (time of day, type of device, location of the device and more). This can be added up to create a full Authorization Profile that gives custom access to the network. I will be talking more about Authorization Profiles and how to secure networks in future blog entries.
The key is that authorization can be much more than just security. I can push QoS down to video endpoints, VLAN configuration to devices that belong in a different subnet, web redirects for services that are unavailable (showing an error page rather than a confusing timeout message).
In my next blog entry I talk about how to secure a network and the various authorization options available