FMC - Source and Destination SGT Tagging

hello and welcome everyone this is veronica kalcova cisco netsec technica marketing engineer in this demo we are going to showcase configuration steps that are required in order to classify traffic based on source and destination security to group stacks assigned to the flow before we start let's discuss what is sgt security group tag the security group tag is a 16-bit value that may be added to the layer 2 header of the packets that increase into a network through the device that support cisco transect security cts specification this stack is then used to determine security and other policy to be applied to it we can define a firewall rules to apply policy to a flow based on source sgt assigned to the flow says very early five power releases more specifically cisco firepower for defense 6.1 version in order for this feature to work an external device such as discord switch must be installed in the network and configured to tag traffic with hgts before the traffic reaches to the next generation firewall our five power fair defense ftd this feature works with and also without ice integration to fmc without ice integration source sgt's can be configured manually in the object management section or directly through the ac rule creation that we are going to demonstrate in a moment let's jump into the configuration right now we are going to create the rgt name to hgt tag mapping directly through the ac rule creation where we select add security group tag button and enter hg name optionally provide description and tag id under htt ice attributes ac rule tab the existing aged tags can be later modified or fully removed when not used from the object object management fmc configuration section newly created hdt tag can be selected and added to the rule as the criteria that needs to be matched for this rule after entering the rule criteria details we can save the rule and save the whole access control policy setting this is all what it takes in order to recognize inline sgt's or tax source sgt tags that are in layer 2 header of the packets that are passing through the ftd device as you can see under identity sources tab there was initially non-identity source defined which confirms that the source sgt's that we previously created were without ice integration first however science in this demonstration we would like to leverage and test the traffic classification based on both source and destination agents we are going to integrate this fnc with the ice node in the network the ability to create access control policy rules with destination sgt criteria has been added as of cisco 5 power 6.5 release sgts are used in security policies instead of defining network groups or individual user identities fmc and all connected devices learn about this dynamically over pxgrid protocol there is no need to deploy any policies when the sgt's or the mappings changes on the eye side therefore in starting from 6.5 release in fmc integration tab under identity sources we can notice two configuration options such as session directory topic and sxp topic using session directory topic option ice provides to fmc user identities user ip mappings for passive user authentication sxp topic subscription needs to be enabled in order to obtain ip2st mappings from ice to fmc that distribute it further to all connected devices now we are going to review all prerequisites that needs to be enabled or configured on the eyesight in order for source and destination hdt tagging to be working in this particular integration deployment so as a first step we need to make sure that under particularized node pxgrid service is enabled however better this pxgrid service is actually up and running can be confirmed through the icli by leveraging show application status ice command the next thing that we need to configure are sgt tags so for sake of this demo we are going to create two sgt tags one is named user and second is named servers to each of those agit tags we are going to assign specific ip addresses so we are going to create something called static ip to hdt mapping ice can be learning actually about those ip20 mappings dynamically from the switches however for simplicity of this demonstration we are going to configure static ip20 mappings on the eyes that will be published to the fmc which then distributed further to all connected devices so first ip2 hdtv static mapping would be for ip address 50.50.50.101 to which we are going to assign previously created hdtac users the second to hgt static mapping would be for ip address 192 168 25.46 and to this ip address we are going to assign another previously configured sgt tag named servers now since we have created ip2st mappings we need to make sure that eyes will publish them over sxp topic to the fmc this can be reviewed or configured under workcenters trussec settings sxp settings where there is checkbox for publish sxp bindings on px3 so this needs to be enabled just keep in mind when enabling this option the sxp service will restart again we can validate whether the service is up and running through the icli show application status ice command the next step is to configure on the eyes at least one six speed device if it is not present yet the need for the sxp device configuration is required in order for eyes to publish ip2s6p mappings to the fmc this is need required due to the current ice design however this six speed device is just temporary device it is a dummy ip address that doesn't need to exist in the network however this configuration setting will just make sure that the mappings are published from ice to fmc so for configuring of this sxp device we can use any ip address even the one that is not routable in the network we can select any peer role we select the configure psn node the domain and the password type none when after saving this configuration the status for sxp device needs to go from unknown to off this typically fast change however occasionally it can take a couple of minutes so just make sure to refresh the screen in order to see that the status went from unknown to off state now with this we have configured all prerequisites on the i side and we can confirm what ip2 mappings are published from the eyes under works at the trussec sxp all sxp mapping section if this table is empty it means the eyes didn't tried or published the ip to hdt mappings there needs to be the entries displayed that the ice actually published to the connected or integrated devices over sxp topic now with this we can move on into the configuration of fmc and finalize our access control rule set with both source and destination sgt tax so fancy we navigate to access control policy and create access control rule that will be used to test source and destination as it is with the real traffic flows so we can create or edit existing rule we are going to leverage in this particular access control rule the tags that we created previously on the i side so for source hdt we will use user as a sgt tag the destination hdt tag will be servers and we can then optionally enable the logging at the beginning and end of the sessions and provide the name of the access control rule to be hdt rule example we save the access control rule and we save the access control policy and deploy the configuration and wait for the deployment to complete upon which we can validate with the real user traffic whether our configure works and that the sgt tags are present in the connection events table now we are ready to validate our configuration of the access control rule with both source and destination hdts and make sure that we are triggering this rule with real user traffic therefore for one of the user machines we are generating the traffic of our the one of the web servers and as you can see in the screen the website of the server is displayed so the connection was allowed so we supposed to hit the configure the rule that has as a criteria source sgt users and destination hdt servers because we have configure action for such traffic flow as allow so therefore it should be permitted in order to find evidence we can search through the connection events database and filter the events based on the source and destination sgt criteria and here we we can see that both source and destination hdt tax has been detected in our traffic flow that we have generated and that we triggered the sgt example rule that has action alone this concludes our demonstration thank you very much for your attention and see you in the next video you

Channel: Cisco Secure Firewall

Views: 1,038

Keywords:

Id: 2U0q5fMr9fE

Length: 13min 38sec (818 seconds)

Published: Mon Sep 28 2020