cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
33740
Views
60
Helpful
9
Comments
jeaves@cisco.com
Cisco Employee
Cisco Employee

 

 

Description

 

When the Cisco Digital Network Architecture Center (Cisco DNAC) provisions the SDA fabric, the Fabric Edge (FE) devices have enforcement enabled automatically ('cts role-based enforcement' and 'cts role-based enforcement vlan-list <vlans>').

However, enforcement is not enabled on the Border. Flows between the FE devices and devices outside the fabric which traverse the Border are not enforced by default.

Depending on the Border device type, the best place to enforce Fabric to non-Fabric flows may well be in the Fusion device. Device type, function, load, scale required etc. all need to be taken into account when deciding where best to enforce.

 

Enforcement on the Border is possible by using the configuration described below.

 

 

Diagram

 

Screen Shot 2018-12-18 at 10.27.20.png

 

 

Summary of Operation

 

The Building Access Control system is provisioned into the Campus VN called BuildingSecurity and has been assigned the Scalable Group Tag (SGT) of Bldg_Acc_Ctrl (SGT 23).

The aim is to deny the Building Access Control systems access to the Production Servers (one of which has an IP address of 10.1.140.2 which is in the company network outside the fabric). The Production Server will be placed into the Production_Servers scalable group (SGT 11). Restricting access to production servers from the likes of control systems is best practice to provide protection contingency in the event of control system compromise.

 

 

 

Configuration

 

Verify Initial Communications

Firstly, is there connectivity from the Building Access Control system to the server before we start?

For this to occur you may need to redistribute routes between routing protocols and leak routes between the BuildingSecurity VN/VRF and the Global Routing Table (GRT). This is manual configuration on the Fusion device.

Route Redistribution and Leaking are the topics of another discussion, but once in place, the Building Access Control system can initially ping the Server:

 

To enforce on the Border, the Border device needs to understand the destination group mapping for the production server. That IP:SGT mapping is 10.1.140.2:11. The source mapping for the Building Access Control system will be learned on the Border via packets received from the endpoint via VXLAN.

 

 

The destination mapping for the server can be learned on the Border by a number of mechanisms:

  1. Statically/manually added to the Border via CLI.
  2. Manually added to the IP:SGT mapping table in ISE and use SXP to send the mapping to the Border.
  3. Statically adding to any device (like DC access switch outside the fabric) and propagating to the Border via SXP.

 

We cannot use SSH from ISE to push the mapping because that ISE function is not VRF aware.

 

 

Adding Policy

 

Whichever method is best for the customer, a policy must be added to satisfy the security needs (deny traffic from Bldg_Acc_Ctrl SGT to Production_Servers SGT in this case).

 

 

This policy is added into Cisco DNA Center:

 

Once the policy has been added, it can be displayed within Cisco DNA Center:

 

 

When created, Cisco DNA Center pushes this policy into ISE. Navigate to Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrix in ISE to display the policy:

 

 

When the Border learns of a Scalable Group mapping, it will request policies from ISE that are protecting that group (the matrix column for that group). It will only do this however, if enforcement is enabled on the Border. Cisco DNA Center does not enable this enforcement so this needs to be added manually:

 

Kernow-ASR1kx#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Kernow-ASR1kx(config)#cts role-based enforcement

 

Note: In my case the Border is a router (ASR1kx) so enforcement is enabled globally using the above command. If your border is a switch then enforcement would also be needed on the VLAN using 'cts role-based enforcement vlan-list <vlan>'

 

 

Mechanism 1) Statically/manually added to the Border via CLI.

 

Add the server mapping statically on the Border using CLI (remember the mapping has to be provisioned into the VN/VRF):

Kernow-ASR1kx#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Kernow-ASR1kx(config)#cts role-based sgt-map vrf BuildingSecurity 10.1.140.2 sgt 11

 

Kernow-ASR1kx#show cts role-based sgt-map vrf BuildingSecurity all

%IPv6 protocol is not enabled in VRF BuildingSecurity

Active IPv4-SGT Bindings Information

 

IP Address              SGT     Source

============================================

10.1.140.2              11      CLI

10.3.16.5               2       INTERNAL

10.4.1.254              2       INTERNAL

 

IP-SGT Active Bindings Summary

============================================

Total number of CLI      bindings = 1

Total number of INTERNAL bindings = 2

Total number of active   bindings = 3

 

Once the mapping is known to the Border, it requests policy from ISE that is protecting that group:

Kernow-ASR1kx#show cts role permissions

IPv4 Role-based permissions default:

        Permit IP-00

IPv4 Role-based permissions from group 23:Bldg_Acc_Ctrl to group 11:Production_Servers:

        Deny IP-00

RBACL Monitor All for Dynamic Policies : FALSE

RBACL Monitor All for Configured Policies : FALSE

 

 

This results in the Building Access Control system to Production Server traffic successfully being enforced and denied:

 

Enforcement is happening on the Border device:

 

 

Mechanism 2) Manually added to the IP:SGT mapping table in ISE and use SXP to send the mapping to the Border.

 

Cisco DNA Center should have enabled SXP in ISE. You can check whether it is enabled via Administration > System > Deployment > (Hostname) >

 

Navigate to Work Centers > TrustSec > Settings > SXP Settings and enter a Global Password to be matched when adding the other end of the SXP connection on the Border device.

 

 

To just send specific mappings to the Border via SXP, create an SXP Domain in ISE. Navigate to Work Centers > TrustSec > SXP > SXP Devices and select 'Assign SXP Domain' at the top of the table:

 

Under the Assign page, there is a link to create a new Domain:

Click to 'Create New SXP Domain'.

In the following pop-up, enter a name for the domain (I have entered 'border-mappings') and click 'Create'

 

Before we add the SXP Device/Connection, the IP address of the Border has to be reachable from ISE and it has to be in the VN/VRF that the Building Access Control system has been provisioned into. In my case, that is VN BuildingSecurity.

There are two IP addresses which could be used on the Border within that VN. One is the IP on the interface towards the Fusion (can be seen to be 10.3.16.5 in the diagram) and the other is the Anycast IP that Cisco DNA Center provisions into the VN.

Either IP can be used as long as Route Leaking and Redistribution has been configured such that ISE can communicate with that IP.

I will use the Anycast IP address that Cisco DNA Center provisioned on the Border in the VN:

Kernow-ASR1kx#sh run int Lo1021

Building configuration...

 

Current configuration : 146 bytes

!

interface Loopback1021

description Loopback Border

vrf forwarding BuildingSecurity

ip address 10.4.1.254 255.255.255.255

dhcp-border-relay

end

Now, under Work Centers > TrustSec > SXP > SXP Devices, we can add a new Device/Connection to the Border using the newly created domain:

We now need to go to the Border and add SXP configuration there (remember to add it in the BuildingSecurity VN/VRF):

Kernow-ASR1kx#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Kernow-ASR1kx(config)#cts sxp enable

Kernow-ASR1kx(config)#cts sxp default password <password to match the global SXP password set in ISE>

Kernow-ASR1kx(config)#cts sxp connection peer 10.1.101.60 source 10.4.1.254 password default mode local listener vrf BuildingSecurity

Kernow-ASR1kx#show cts sxp connections vrf BuildingSecurity brief

SXP              : Enabled

Highest Version Supported: 4

Default Password : Set

Default Source IP: Not Set

Connection retry open period: 120 secs

Reconcile period: 120 secs

Retry open timer is running

Peer-Sequence traverse limit for export: Not Set

Peer-Sequence traverse limit for import: Not Set

 

----------------------------------------------------------------------------------------------------------------------------------

Peer_IP          Source_IP        Conn Status                                          Duration

----------------------------------------------------------------------------------------------------------------------------------

10.1.101.60      10.4.1.254       On                                                   0:00:00:35 (dd:hr:mm:sec)

 

Total num of SXP Connections = 1

 

Navigating back to ISE Work Centers > TrustSec > SXP > SXP Devices, we can also see the connection is ON/up:

 

 

Now we can add a mapping in ISE for the Production Server and send it to the SXP domain:

Navigate to Work Centers > TrustSec > Components > IP SGT Static Mapping. We will add a static mapping for the production server and send it to the SXP Domain to be sent to the Border. In ISE, click the Add button and complete the details for the IP address (of the production server), SGT (of the production server) and send to the 'border-mappings' SXP Domain; then Save:

 

 

You should see that mapping in the SXP database in ISE if you navigate to Work Centers > TrustSec > SXP > All SXP Mappings:

 

 

As there is an active SXP connection from that ISE Domain to the Border BuidlingSecurity VN, we should see that mapping in the Border VN learned via SXP:

Kernow-ASR1kx#show cts role-based sgt-map vrf BuildingSecurity all

%IPv6 protocol is not enabled in VRF BuildingSecurity

Active IPv4-SGT Bindings Information

 

IP Address              SGT     Source

============================================

10.1.140.2              11      SXP

10.3.16.5               2       INTERNAL

10.4.1.254              2       INTERNAL

 

IP-SGT Active Bindings Summary

============================================

Total number of SXP      bindings = 1

Total number of INTERNAL bindings = 2

Total number of active   bindings = 3

 

Once the Border device learns of that group mapping, it requests policy from ISE protecting that group:

Kernow-ASR1kx#show cts role-based permissions

IPv4 Role-based permissions default:

        Permit IP-00

IPv4 Role-based permissions from group 23:Bldg_Acc_Ctrl to group 11:Production_Servers:

        Deny IP-00

RBACL Monitor All for Dynamic Policies : FALSE

 

RBACL Monitor All for Configured Policies : FALSE

 

The Building Access Control system traffic is now successfully enforced, it cannot contact the production server:

 

 

Enforcement is happening on the Border device:

 

 

Mechanism 3) Statically adding to any device (like DC access switch outside the fabric) and propagating to the Border via SXP.

 

This is a just a combination of the other mechanisms already discussed.

 

Comments
Shawn Wargo
Cisco Employee
Cisco Employee

Short and concise. Only the details needed. Screen caps and sample configs add visuals, and clarify the text. Well done!

My only improvement would be to add a 'Table of Contents', for easier navigation.

jeaves@cisco.com
Cisco Employee
Cisco Employee

Thanks a lot Shawn, 'Table of Contents' added as suggested.

Best regards, Joff

ammahend
VIP
VIP
I am using 9300 as border, in my case I am seeing a little different result, inspite of the correct IP-SGT mapping and policy being pushed on Border, Border does not block traffic, when the traffic returned back to Edge then it gets blocked, I am able to achieve what I want but I am really curious why it did not get blocked on border, not sure this is a bug on 9300. I have sent you en email with few screen shots.
jeaves@cisco.com
Cisco Employee
Cisco Employee

Communicated with Ambuj over email, worked ok after adding 'cts role-based enforcement vlan-list x' where x is the vlan egressing the fabric towards the non-fabric environment.

ammahend
VIP
VIP
Thanks for your reply.
mazhar mahadik
Level 1
Level 1

 Hi Jof,

 Excellent Document, It was very helpful,  

was wondering if we can use Static IP based SGT Policy Tab in DNAC & use IP-based access control within DNAC in any extent to achieve this?

jeaves@cisco.com
Cisco Employee
Cisco Employee

Under Policy in Cisco DNA Center there is the 'IP Based Access Control' menu. This is not SGT based, it's purely IP based.

The micro-segmentation techniques are group-based and as such IP based controls would not provide the same dynamic policies required.

mhaleem1985
Level 1
Level 1
it is very helpful information thanks alot but can we apply the SGT mapping for the servers outside the fabric at the Edge switches not the border or fusion i think if this achieved it will be better as we will block traffic at the source and preserve the bandwidth inside the fabric by denying traffic to reach to the border to block it
jeaves@cisco.com
Cisco Employee
Cisco Employee

Sorry mhaleem1985, I've just seen this question.

No, we would not want to send destination mappings back to the Edge for ingress enforcement. Group-based policies are downloaded dynamically and are only downloaded when needed. If we send destination mappings back to the source Edge then that platform would need to download policy for all those mappings and there are potentially thousands of destination mappings and hence policies.

To handle scale, we create mappings near the destination so that only a small subset of the enforcement matrix is downloaded for the SGTs that need protecting.

Remember that if the transport is TCP then the 3-way handshake will not be passed so there will not be traffic traversing the fabric anyway.

Hope that helps.

Regards, Jonothan.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: