Basic Trustsec – Implementing Manual SGTs and SGACLs

Trustsec is a mature and interesting policy mechanism available in most Cisco gear. The features and capabilities vary depending on device type and class. One of the frustrations I have is that almost every Trustsec reference I find focuses on the use of ISE. While I consider ISE a key component, I think a manual configuration is a better way to understand the components of the solution.

This post is the first in a series that will go through the configuration of Trustsec in various places in the network. I hope to examine classification and tag assignment, propagation techniques and enforcement. Ultimately, I will introduce ISE but it will be the tool that makes this technology dynamic and robust. The goal is to build a better foundation by taking a step by step approach into the world of Trustsec.

In this article, I will simply build a network with a Catalyst 9300 and two devices. One device will be assigned an SGT of 2 and the other will receive an SGT of 3. I understand that many are concerned about the fact that they don’t have this class of switch at the access layer. Future articles will address how Trustsec can be leveraged with varying device types in different places in the network.

To configure this scenario on the Catalyst 9300, I have used the following commends.

SGT Assignment

!
device-tracking policy Default
 no protocol udp
 tracking enable reachable-lifetime 120

!
interface GigabitEthernet1/0/1
 description Host with static assignment for SGT 2
  device-tracking attach-policy Default 
  cts manual
  policy static sgt 2
  no propagate sgt
!
interface GigabitEthernet1/0/24
 description Host with SGT 3 (emulated by connecting an ASA)
 device-tracking attach-policy Default 
 cts manual
  policy static sgt 3
  no propagate sgt

This enables manual SGT assignment to the hosts associated with each of these ports. I am not propagating the SGT because the connected host would not understand the frame format. The host to SGT association can be verified with the following show command.

SGT Confirmation

c9kSW1#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information

IP Address              SGT     Source
============================================
192.168.254.2           3       LOCAL
192.168.254.11          2       LOCAL

IP-SGT Active Bindings Summary
============================================
Total number of LOCAL    bindings = 2
Total number of active   bindings = 2

It is worth noting that this seems to require device tracking to propagate the IP to SGT table as shown above.

The next step is to add a policy to enforce traffic from SGT tag 2 to SGT tag 3. It is worth mentioning that most communication is a two-way process. So it is important to consider the need to address traffic from SGT tag 3 to SGT tag 2. This is, of course, depending on whether the need is to protect hosts with SGT 2 and hosts with SGT 3. In this case, I will allow telnet from SGT 2 to SGT 3 and everything in the opposing direction. This requires the creation of a role-based ACL and applying it as a CTS (Cisco Trustsec) permission.

Policy Enforcement

//create the role based acls
ip access-list role-based DENY
 deny   ip
ip access-list role-based MYLIST
 permit ip
ip access-list role-based TELNET
 permit tcp dst eq telnet
!
//allow only telnet from 2 to 3
cts role-based permissions from 2 to 3 TELNET DENY
//allow anything from 3 to 2 
cts role-based permissions from 3 to 2 MYLIST 

//apply role based enforcement to vlan 1
cts role-based enforcement vlan-list 1
//enable role based enforcement
cts role-based enforcement

Policy Confirmation

//pings fail
PAULS-MAC:~ paulste$ ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C

//telnet works
PAULS-MAC:~ paulste$ telnet 192.168.254.2
Trying 192.168.254.2...


Connected to 192.168.254.2.
Escape character is '^]'.


User Access Verification

Password:
Password:

Conclusion

This is a very simple example of local Trustsec using SGT and policy enforcement. There are many additional topics that I hope to cover in future articles. Overall, I hope to cover the comprehensive list of Trustsec components in a way that is conducive to learning and easy to digest for network and security architects.

 

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.

2 Responses to Basic Trustsec – Implementing Manual SGTs and SGACLs

  1. Shuja says:

    As usual excellent stuff Paul. I have never implemented this. On a large scale is it feasibly to replace the use of normal ACLs with CTS SGT RBAC ? Please share any used cases you have implemented. Looking forward for future articles related to this

Comments are closed.