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.
! 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.
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.
//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
//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:
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.