CCNP Security (CCIE Sec. written June 2017, one lab attempt so far!), Fire Jumper, Cisco Support Community Hall of Fame and VIP x6. Passionate about solving problems in network security and helping others learn to do the same.
Yes - the "k8" image does not include the strong encryption license by default. "k9" would have it.
You can obtain the free license (assuming you aren't in a prohibited country like North Korea) from software.cisco.com. Once you install it ASDM should work for you.
... View more
I'd highly recommend getting on a call with the TAC for doing this. You may very well encounter issues and the TAC can work through them with you in real time if you open a ticket first.
That said, most use cases would involve upgrading instead of rolling back a patch. 126.96.36.199 is currently the recommended release. It's hard to imagine a condition where you would want to move backwards on an already older release.
... View more
HAve you considered using an ASAv (VM)? You can run it on the free version of ESXi and it does 90% or more of what a physical appliance does.
If you only want to learn and don't need to pass other than test traffic through it, there is a free version that's limited to 100 kbps throughput.
... View more
Functionally there's no difference.
Cisco encodes various part numbers differently. Generally speaking, they have to do with the manufacturer identification and year/date the part was built.
Sometimes there may be minor revisions to the firmware (yes even SFPs have firmware) and that can be reflected in the part number.
... View more
@Leo Laohoo 's suggestion will tell if your IOS-XE is potentially vulnerable.
If you have configured the global command "dot1x system-auth-control" and related interface commands (typically used with ISE or other NAC solution) then the vulnerability is active on your device.
... View more
Use this tool:
It will tell you:
! Unused object-group found; suggest removing it no object-group network obj-google.com ! Unused ACL found; suggest removing it clear config access-list 101 ! Analyzed 375 lines of code.
... View more
In this paper we will document the configuration and operation of an integrated solution that includes identity management, firewall, cloud-based management, and cloud-based logging.
We will use the following Cisco products:
Identity Services Engine (ISE)
2.6 Patch 3
Firepower Threat Defense (FTD)
Cisco Defense Orchestrator (CDO)
Cisco Security Analytics and Logging (SAL)
We will demonstrate the integration steps to configure these products to work together to deliver an end-to-end security solution that meets customer requirements for security and visibility of user identity for all network connections for a 90-day period.
Identity Management - Identity Service Engine (ISE)
ISE is Cisco’s network access control solution. It provides context-based access control for wired, wireless and VPN users. It comes in both a full-featured product variant as well as a lightweight option known as ISE-PIC (Passive Identity Connector).
An ISE deployment can be one server or many servers, depending on the requirements for scale and high availability. ISE servers can be deployed as physical appliances (Cisco SNS-3xxx devices based on the Cisco UCS C-series servers) or virtual machines (VMs). Public cloud-based ISE servers are not currently offered.
For purposes of this paper we are using a single ISE server deployed as VM on a VMware ESXi server.
ISE has the concept of personas or roles. The ISE server personas include Administration, Policy Service, Monitoring, and pxGrid. While a distributed deployment can separate the personas onto different servers, a single node deployment such as we are using has all personas on one server.
There are also varying license types available for ISE. There are Base, Plus, Apex and Device Administration licenses. For the use case we examine here, Base licensing is all that is required.
Our requirement for ISE is simply to gather user identity and publish it to our Firepower device. It can gather identity in several ways. Providers include Microsoft Active Directory (AD, via WMI most often), IPAMs (IP Address Management systems), Secure Web Gateways, LDAP (these via syslog into ISE) and custom integrations (via Application Programming Interface or API). It publishes via pxGrid (Platform Exchange Grid) a Cisco-developed method that allows standardized exchange of information.
The following diagram illustrates the concept:
ISE Identity and pxGrid
(Source: ISE 2.6 Administration Guide)
Firewall - Firepower Threat Defense (FTD)
FTD is Cisco’s Next-Generation Firewall (NGFW). It is a unified image combining the classic Cisco ASA stateful firewall with the Firepower Next-Generation Intrusion Prevention System (NGIPS) technology based on the underlying Snort IPS engine that was part of Cisco’s acquisition of Sourcefire in 2014.
FTD appliances can be deployed on a broad variety of hardware platforms as well as VMs on either on-premise hypervisors (VMware ESXi and KVM) as well as in AWS and Azure public clouds. They can also be deployed in high availability pairs or in scalable clusters
For purposes of this paper we are using a single FTD virtual appliance (FTDv) deployed as a VM on a VMware ESXi server.
FTD also has varying license levels including the base Threat license, URL Filtering and Malware. We will be using both Threat and URL Filtering license features as we can to have visibility into and control over URLs accessed by users.
As shown in the earlier diagram, FTD can integrate with ISE (or ISE-PIC) via pxGrid to ingest user identity information. Specifically, we are using it to associate user identity with observed IP addresses of traffic flows via the firewall. This integration feature is included in the base license.
Management - Cisco Defense Orchestrator (CDO)
FTD devices can be managed fundamentally via two different methods:
A traditional method using Cisco’s Firepower Management Center (FMC) product or
A newer modern architecture method using REST API (Wikipedia reference defining REST) and a combination of on-box Firepower Device Manager (FDM) and the cloud-based Cisco Defense Orchestrator (CDO) Software as a Service (SaaS) offering.
We will be using the second method with a combination of FDM and CDO. FDM is used for initial device configuration as well as a few settings that are not currently supported on CDO (primarily the configuration of the ISE server as an identity source). Once we have done the required bits using FDM, the remainder of day-to-day operations are done via CDO.
Besides the advantages of more scalable and multiple platform support (FTD, ASA, Meraki), another reason we are using CDO is for integration with Cisco’s cloud-based logging solution. CDO is required to use that service.
Logging - Cisco Security Analytics and Logging (SAL)
SAL is a recently introduced (October 2019) SaaS offering from Cisco. It fills an important role for CDO-managed FTD devices as the logging platform that ingests connection and security events from the managed devices securely and retains the events for 90 days in a Cisco-managed cloud-based service.
Prior to SAL, customers using FDM or CDO management could only see a limited set of real time events via FDM. Otherwise they had to send the events to a third-party log management tool or a SIEM for longer term retention and analysis. Customers using FMC could send events to the FMC event viewer. While it includes very rich analysis capabilities, data retention on FMC could be a challenge as even a moderate scale deployment of multiple firewalls can generate many gigabytes per day of connection records. SAL addresses those challenges with a subscription-based service offering whereby Cisco retains all ingested log data for 90 days. It can also correlate firewall logs with Netflow data for customers availing themselves of the Cisco StealthWatch Cloud (SWC) service. Both SAL and SWC use technology based on the Cisco acquisition of Observable Networks in 2017. StealthWatch is further derived from Cisco’s acquisition of Lancope in 2015.
When setting up CDO and SAL, one has the option of using on-premise virtual machines known as the Secure Device Connector (SDC) and Secure Event Connector (SEC) or connecting and sending events directly to the cloud. We will use the latter option as it is generally simpler. The direct connection is a feature that requires FTD version 6.5 or greater.
For purposes of this discussion, we will cover only the parts specific to the features being leveraged for this integration. We will not cover basic product setup as there are numerous other references: Cisco-published product documentation, Cisco Security Community documents and third party training and web-based resources.
ISE-FTD Integration via pxGrid
Note – first we follow this guide for basic setup for pxGrid:
We depart from that document since we are using FDM and not FMC management.
We will need a pxGrid certificate (i.e., one with both client and server usage indicated). For that I create a CSR externally and submit to my CA and specify the pxGrid template. We need to be sure to add the issuing CA as a Trusted CA as it is signing both our own pxGrid certificate as well as those from the ISE server certificates (both MnT and pxGrid). Deploy those certificates prior to adding the ISE identity source or else the test will fail.
Adding ISE Identity Source to FTD
On the ISE side we should see the following:
pxGrid Subscriber Verification in ISE
FTD Identity Policy and Cloud management settings
Once we have a verified pxGrid connection between ISE and the FTD device, we can now add an Identity Policy to use the information published by ISE to inform the FTD logging (and, optionally, user-based policies when combined with realm integration – outside the scope of this document).
The Identity Policy needs to be done via FDM as the ISE Identity Source is not a supported feature in CDO at this time. We need to add the AD realm in order to use the ISE Identity Source.
FTD Identity Policy
Once added via FDM, we can sync with CDO and see the policy in place:
CDO-FTD Sync Verification
We need to ensure that we have enabled FTD to send events to the Cloud and that the Access Control Policy (ACP) is set to Log Connection Events:
FTD Enablement of Cloud Eventing
FTD ACP Logging Setting
Let’s first verify that we have identity information in ISE. In our environment we are gleaning user-IP mapping by virtue of the user having logged in to our secure WLAN and been authenticated via Active Directory (AD). We could have alternatively used any of the other ISE identity providers as mentioned earlier (e.g., syslog- or API-based providers).
WLAN client detail:
WLAN Client Detail
ISE RADIUS Live Log:
ISE RADIUS Live Log
ISE Authentication Detail:
ISE Authentication Detail
Next, confirm that FTD to ISE pxGrid operations are working:
ISE-FTD pxGrid Test Verification
Then ensure that we are using ISE as the source in our FTD Identity Policy:
FTD Identity Policy
Finally, we confirm that user identity is appearing in the CDO-based view of SAL-ingested data.
CDO/SAL Monitoring with User Identity
From the verification section, we can see:
The WLAN authenticated and authorized the user via Central Web Authentication (CWA + ISE)
The WLAN record in ISE, with authorization via Active Directory
pxGrid is active and working between ISE and FTD, allowing FTD to subscribe to ISE’s published “SessionDirectory” topic.
The FTDv-2 firewall is the host reporting the connection to SAL/CDO with the source IP and username matching what was reported in ISE.
Reporting via SAL and display in the CDO interface.
All the component parts are working together to provide an end-to-end security and visibility solution.
As noted, we could have gleaned the user information via other sources supported in ISE (LDAP, syslog, API integrations). Users could have also accessed the network via other methods such as wired connections or remote access VPN. In any of those cases, we would retrieve the user information from ISE (or ISE-PIC) similarly.
There are additional components that can be integrated but are out of scope for this paper. Examples include Cisco Umbrella (for DNS Security), Cisco Stealthwatch (for visibility and security based on Netflow data), Cisco AMP (Advanced Malware Protection) for Endpoints and Cisco Email Security Appliance (ESA).
Most of these can further be consolidated via the Cisco Threat Response (CTR) service.
... View more
Like @balaji.bandi said - the RMA procedure includes the licensing team generating a new license. They will do that for you as part of the case - you don't need to use the self-service portal.
... View more