In this post, I’m going to be posting my deep-dive notes on ISE device profiling as well as what each probe does and what type of information to expect from the attributes.
Example of a CDP entry seen from a switch
CDP TLV Descriptions:
Address - Contains a list of device network-layer addresses. If a device uses Simple Network Management Protocol (SNMP), the first address is an address at which the device receives SNMP messages. The device may advertise all its addresses and may optionally advertise one or more loopback IP addresses.
Capabilities - Identifies the device type. The device type indicates the functional capability of the device, for example, a switch.
Device-ID - Name of the device
Platform - Describes the hardware platform of the device.
Version - Contains information about the software image version the device is running.
Enable CDP on the Switch
IOS Device Sensor for CDP
device-sensor filter-list cdp list TLV-CDP
tlv name device-name
tlv name address-type
tlv name capabilities-type
tlv name version-type
tlv name platform-type
device-sensor filter-spec cdp include list TLV-CDP
cdpCacheVersion: Cisco IOS Software, C3700 Software (AP3G2-K9W8-M), Version 15.3(3)JA12, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2017 by Cisco Systems, Inc. Compiled Fri 20-Oct-17 20:51 by prod_rel_team
cdpCachePlatform: cisco AIR-CAP3602I-A-K9
cdpCacheVersion: Cisco IOS Software, C3600 Software (AP3G2-K9W8-M), Version 15.3(3)JD17, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2019 by Cisco Systems, Inc. Compiled Fri 12-Apr-19 03:21 by prod_rel_team
cdpCachePlatform: Cisco IP Phone 7961
Example of an LLDP entry seen from a switch
ONE IMPORTANT NOTE: LLDP is turned off by default on most Cisco switches. Enable it globally using the lldp run command and then on the interfaces using lldp receive and lldp transmit commands. Unlike CDP, LLDP is an open standard and many IoT devices use it so I would recommend enabling this on your switches.
LLDP TLVs Descriptions:
Capabilities - Endpoints determine the types of capabilities that a connected device supports and which ones are enabled.
Chassis ID - The Chassis ID is a mandatory TLV which identifies the chassis component
of the endpoint identifier associated with the transmitting LLDP agent. Usually I see this field being populated by either a MAC address or IP address
ManAddress - The Management Address is a mandatory TLV which identifies a network address associated with the local LLDP agent, which can be used to reach the agent on the port identified in the Port ID TLV.
Port Description - Provides a description of the port id in an alpha-numeric format. The value equals the ifDescr object
Port ID - The Port ID is a mandatory TLV which identifies the port component of the endpoint identifier associated with the transmitting LLDP agent.
System Capabilities - Indicates the primary function(s) of the device and whether or not these functions are enabled in the device. The capabilities are indicated by two octects. Bits 0 through 7 indicate Other, Repeater, Bridge, WLAN AP, Router, Telephone, DOCSIS cable device and Station respectively. Bits 8 through 15 are reserved.
System Description - Provides a description of the network entity in an alpha-numeric format. This includes system's name and versions of hardware, operating system and networking software supported in the device. The value equals the sysDescr object, if the LAN device supports RFC 3418.
System Name - Provides the system's assigned name in an alpha-numeric format. The value equals the sysName object
Time To Live - Indicates how long (in seconds) the LAN device's information received in the LLDPDU is to be treated as valid information.
Enable LLDP on Switch
IOS Device Sensor for LLDP
device-sensor filter-list lldp list TLV-LLDP
tlv name port-id
tlv name time-to-live
tlv name port-description
tlv name system-name
tlv name system-description
tlv name system-capabilities
tlv name management-address
tlv name chassis-id
tlv name time-to-live
device-sensor filter-spec lldp include list TLV-LLDP
lldpSystemDescription: Cisco IP Phone 7961G,V1, SCCP41.9-4-2SR1-1S
DHCP Option Descriptions:
boot-file – Option 67 - Bootfile name - This option is used to identify a bootfile when the 'file' field in the DHCP header has been used for DHCP options.
class-identifier – Option 60 - This option is used by DHCP clients to optionally identify the type and configuration of a DHCP client. The information is a string of n octets, interpreted by servers. Vendors and sites may choose to define specific class identifiers to convey particular configuration or other identification information about a client. For example, the identifier may encode the client's hardware configuration. Servers not equipped to interpret the class-specific information sent by a client MUST ignore it (although it may be reported).
client-fqdn – Option 81 - To update the IP-address-to-FQDN mapping, a DHCP server needs to know the FQDN of the client to which the server leases the address. To allow the client to convey its FQDN to the server, this document defines a new DHCP option, called "Client FQDN". The Client FQDN option also contains Flags, which DHCP servers can use to convey information about DNS updates to clients, and two deprecated RCODEs. Clients MAY send the Client FQDN option, setting appropriate Flags values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a client sends the Client FQDN option in its DHCPDISCOVER message, it MUST send the option in subsequent DHCPREQUEST messages though the contents of the option MAY change.
client-identifier – Option 61 - This option is used by DHCP clients to specify their unique identifier. DHCP servers use this value to index their database of address bindings. This value is expected to be unique for all clients in an administrative domain. It is expected that this field will typically contain a hardware type and hardware address, but this is not required. Current legal values for hardware types are defined in https://tools.ietf.org/html/rfc1340
domain-name – Option 15 - This option specifies the domain name that client should use when resolving hostnames via the Domain Name System.
host-name – Option 12 - Hostname for the client – using RFC 1035 character set
parameter-request-list – Option 55 - This option is used by a DHCP client to request values for specified configuration parameters. The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined in this document. The client MAY list the options in order of preference. The DHCP server is not required to return the options in the requested order, but MUST try to insert the requested options in the order requested by the client.
pxe-client-arch – Option 93 - Octet "n" gives the number of octets containing "architecture types" (not including the code and len fields). It MUST be an even number greater than zero. Clients that support more than one architecture type MAY include a list of these types in their initial DHCP and PXE boot server packets. The list of supported architecture types MAY be reduced in any packet exchange between the client and server(s). Octets "n1" and "n2" encode a 16-bit architecture type identifier that describes the pre-boot runtime environment(s) of the client machine.
pxe-client-machine-id – Option 97 - Octet "t" describes the type of the machine identifier in the remaining octets in this option. 0 (zero) is the only value defined for this octet at the present time, and it describes the remaining octets as a 16-octet Globally Unique Identifier (GUID). Octet "n" is 17 for type 0.
pxe-client-network-id – Option 94 - Octet "t" encodes a network interface type. For now the only supported value is 1 for Universal Network Device Interface (UNDI). Octets "M" and "m" describe the interface revision. To encode the UNDI revision of 2.11, "M" would be set to 2, and "m" would be set to 11 (0x0B).
requested-address – Option 50 - This option is used in a client request (DHCPDISCOVER) to allow the client to request that a particular IP address be assigned
server-identifier – Option 54 - This option is used in DHCPOFFER and DHCPREQUEST messages, and may optionally be included in the DHCPACK and DHCPNAK messages. DHCP servers include this option in the DHCPOFFER in order to allow the client to distinguish between lease offers. DHCP clients indicate which of several lease offers is being accepted by including this option in a DHCPREQUEST message. The identifier is the IP address of the selected server.
user-class-id – Option 77 - DHCP administrators may define specific user class identifiers to convey information about a client's software configuration or about its user's preferences. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department.
vendor-class – Option 60 - A DHCP client may use this option to unambiguously identify the vendor that manufactured the hardware on which the client is running, the software in use, or an industry consortium to which the vendor belongs. The information contained in the per-vendor data area of this option is contained in one or more opaque fields that may identify details of the hardware configuration.
IOS Device Sensor for DHCP
device-sensor filter-list dhcp list dhcp-list
option name boot-file
option name class-identifier
option name client-fqdn
option name client-identifier
option name domain-name
option name host-name
option name parameter-request-list
option name pxe-client-arch
option name pxe-client-machine-id
option name pxe-client-network-id
option name requested-address
option name server-identifier
option name user-class-id
option name v-i-vendor-class
device-sensor filter-spec dhcp include list dhcp-list
The SNMP Trap notifies ISE of a linkup/linkdown which let’s ISE know that it should run an SNMP Query. However, the SNMP Trap may not be needed if RADIUS is configured since the RADIUS session will also trigger the SNMP Query.
Options available for SNMP in ISE’s profiler:
cafSessionAuthorizedBy - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the name of the feature which authorizes the authentication session.
cafSessionAuthUserName - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the name of the authenticated user for the authentication session.
cafSessionAuthVlan - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the authorized VLAN applied to the authentication session. Value zero indicates that no authorized VLAN has been applied, or it is not applicable.
cafSessionClientMacAddress - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the MAC address of the device associates with the authentication session.
cafSessionDomain - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the type of domain that the authentication session belongs to. othe: none of the below. data: indicates the data domain. voice: indicates the voice domain. 1-other, 2-data, 3-voice
cafSessionStatus - Part of the CISCO-AUTH-FRAMEWORK-MIB Module - Indicates the current status of the authentication session. 1-idle, 2-running, 3-noMethod, 4-authenticationSuccess, 5-authenticationFailed, 6-authorizationSuccess, 7-authorizationFailed
cLApIfMacAddress - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the Ethernet MAC address of the AP.
cLApName - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the administrative name assigned to the AP by the user. If an AP is not configured, its factory default name will be ap: eg. ap:af:12:be.
cLApNameServerAddress - Part of the CISCO-LWAPP-AP-MIB Module - This represents the IP Address of the name server. This attribute can be configured only if the static IP option is turned on in the AP.
cLApNameServerAddressType - Part of the CISCO-LWAPP-AP-MIB Module - This represents the type of the IP address of the name server, made available through cLApNameServerAddress.
cLApSshEnable - Part of the CISCO-LWAPP-AP-MIB Module - This object specifies whether SSH session can be established to the AP.
cLApSysMacAddress - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the radio MAC address common to the dot11 interfaces of the AP and uniquely identifies an entry in this table.
cLApTelnetEnable - Part of the CISCO-LWAPP-AP-MIB Module - This object specifies whether Telnet session can be established to the AP.
cLApTertiaryControllerAddress - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the address of the tertiary controller that the APs will join.
cLApTertiaryControllerAddressType - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the type of the tertiary controller's address made available through cLApTertiaryControllerAddress.
cLApUpTime - Part of the CISCO-LWAPP-AP-MIB Module - This object represents the time in hundredths of a second since the last time the..
In this video, we’ll be going over the configuration of Security Group ACLs and the Trustsec matrix. After we configure it, I’ll show you how it’s pushed down to the network access devices and enforce them.
1.57 - Trustsec: Configuring the Trustsec Matrix and SGACLs - YouTube
In this video, we’re going to walk through the configuration of SGT Exchange Protocol (SXP). We’ll first configure it between two switches that are separated by a non-Trustsec-capable device and then we’ll configure it between the switches and ISE.
In this video, we’re going to dig into Trustsec a little bit further by discussing some of the different IP-to-SGT bindings are done, how to configure various static bindings, how the network access device prioritizes different SGT binding types and why SXP is so important.
1.54- Digging into SGT Bindings, priority, and SXP - YouTube
Notes from this video:
Different SGT Classification Options:
Dynamic – Usually assigned at the time of the connection by ISE as part of the authorization policy
Best type of SGT assignment
Important: Make sure that IP device tracking is turned on the switch
ISE uses cisco-av-pair=cts:security-group-tag to deliver the tag with RADIUS
To view the bindings, you can use the show cts role-based sgt-map all command for more details
Static – Usually done for servers, topology-based policy, or brownfield sites that you haven’t converted over to use ISE for AAA yet. Best to use with hosts that aren’t changing IP addresses regularly.
Static tags can be assigned by:
Layer 2 interface
Layer 3 interface
Any of the above in their own separate VRFs
Statically defined in ISE and pushed out via SXP
How are bindings done?
VLAN – Snooped ARP packets on a VLAN that has the static sgt mapping configured
This is going to be the start of a small series on Trustsec. We’re going to go over some of the common terminology and components of Trustsec and give an overview of why we would use SGTs.
1.53 - Overview of Trustsec and Terminology - YouTube
Notes from the video:
What is Cisco Trustsec?
Short answer: Initially defined as as architecture comprising of several components but most of the time, people thing of Security Group Tags (SGTs) when they think of Trustsec
Long Answer: Several components including -
Centralized policy management, distributed policy enforcement and microsegmentation using Security Group Tags (SGTs)
Confidentiality and integrity using encryption based on IEEE 802.1AE (AES-GCM 128-bit)
Wire-rate hop-by-hop layer 2 encryption
Key management is based on 802.1n
Authenticated networking environment
Endpoints are authenticated via 802.1x, Easyconnect, MAB, WebAuth, etc
Network devices are authenticated and admitted into the Trustsec environment via 802.1x which creates a trusted networking environment
Security Group - Used for grouping users, endpoints, and resources that should have a similar access control policy
Security Group Tag (SGT) - Unique security group number that’s assigned to the security group
Trustsec-Capable Device - Network access device that’s capable hardware- and software-wise of understanding security group tags
Trustsec Seed Device - Network access device that authenticates directly against ISE and acts as both the authenticator and supplicant for other network access devices
Network Device Admission Control (NDAC) - In a Trustsec cloud, network devices are verified with credentials by the peer device:
Upon authentication and authorization, network devices negotiate for IEEE 802.1AE encryption
Protected Access Credential (PAC) - Unique shared credential used to mutually authenticate client and server
Endpoint Authentication Control - Devices authenticated to the Trustsec cloud via 802.1x, Easyconnect, MAB, Webauth, etc
Security Group Access Control List (SGACL) - Used for access and permissions based on SGTs, not IP addresses or subnets. Simplifies the security policy.
Security Exchange Protocol (SXP) - A service that’s used to propagate IP-to-SGT bindings across network devices that don’t support SGTs. Think of it like BGP propagating routes across a provider’s MPLS.
Environment Data Download - Download from ISE to the Network Access Device when it joins the trusted network. When it does this, it downloads the following:
ISE RADIUS server list it can use for future RADIUS authentications and authorizations
Device SGT - SGT for the network access device itself
Expiry Timeout - How often the network access device should download or refresh the environment data
Identity to port mapping - Switch defining the identity on a port and using this identity to look up a particular SGT value from ISE
In this video, we’re going to walk through the configuring of FQDN ACLs on Firepower 6.3. This was a feature that was just added in this latest release. The goal of this configuration is the block source or destination based on FQDN. In this case, I’m blocking a single host FQDN from accessing another host (my proxy) based on it’s FQDN.
In this video, we’ll be exploring FTD device copy, backup and restore. Device copy is used to easily copy configurations and policies from a pre-configured device to a completely different device while device copy copies the configurations, logs, events, etc and restore them to the same device.