EoS and EoL roll-up for Cisco AirOS Wireless, ASA, and Switching

End of Sale and End of Life dates for AireOS Cisco Wireless LAN Controllers – AIR-CT-3504AIR-CT-5520AIR-CT8540AIR-CTVM 


End of Sale and End of Life dates for ASA 5506, 5512 & 5515, 5508 & 5516, 5525, 5545 & 5555, 5585-X, 5585-X FP

End of Sale and End of Life dates for Cisco Catalyst – 2960X/XR2960L/P3650SUP9E

Mike

Protecting the WFH workforce – Defending against COVID-19 malicious domains

Many organizations have implemented work from home (WFH) strategies due to COVID-19. This measure, although enabling business continuity for many, introduces increased risk to cyber threats and attacks.

Cisco Talos has been proactively hunting COVID related outbreaks, educating the public, and pushing these discoveries to all Cisco Security tools for blocking. I encourage you to read the Talos blog, “Threat Actors attempt to capitalize on coronavirus outbreak” and “Threat Update: COVID-19“.

Talos goes as far as to list ways that you can defend against COVID related attacks. Cisco Umbrella, in particular, can leverage threat intelligence from Cisco Talos, to uncover and block these malicious domains, IPs, URLs, and files that are used in attacks. It’s not just Talos intelligence that Umbrella can leverage, however. You can take advantage of 3rd party threat intelligence platforms (TIP) that you may have and create a completely robust, kickass defense for your work from home workforce.

Here’s how –

Turn on – Newly Seen DomainsAs part of Cisco Umbrella intelligence, some domains may be blocked as Newly Seen Domains (NSD). Newly created domains related to COVID-19 will also be flagged as NSD as long as they fit the criteria.

Third Party Integration: Umbrella support integrations with SIEM, threat intelligence platforms, or homegrown systems. This feature utilizes the ‘Enforcement API‘ in Umbrella.

Here are the default integrations.

In this case, I want to show you how to leverage a homegrown system. We’ll call it “COVID-19-BLOCK”

When you add a new integration, an API key is generated. This API key can be used to make requests to and from Umbrella.

Our homegrown system is nothing more than a simple python script that makes POST requests to Umbrella.

# Custom integration - ADD EVENT URL
import requests

url = "https://s-platform.api.opendns.com/1.0/events?customerKey=c988727a-XXX-XXXX-XXXX-XXXXXXXXX";

payload = "{\n    \"alertTime\": \"2013-02-08T11:14:26.0Z\",\n    \"deviceId\": \"ba6a59f4-e692-4724-ba36-c28132c761de\",\n    \"deviceVersion\": \"13.7a\",\n    \"dstDomain\": \"coronadiseasenews.com\",\n    \"dstUrl\": \"http://coronadiseasenews.com/a-bad-url\",\n    \"eventTime\": \"2020-03-31T09:30:26.0Z\",\n    \"protocolVersion\": \"1.0a\",\n    \"providerName\": \"Security Platform\"\n}"
headers = {
  'Content-Type': 'application/json'
}
response = requests.request("POST", url, headers=headers, data = payload)

print(response.text.encode('utf8'))

After running the script, we can confirm that our request to block the COVID-19 malicious domain was successful.

As you can see, we were successful in adding this malicious domain to our block list.

Now, take a moment to expand on this custom integration that we just made. There are roughly 70,000 COVID-19 malicious domains and growing daily. What if we were able to take all of the published COVID-19 molicous domains and add them to an Umbrella block policy like we did above?

I think that would make any CSO smile.

Mike

DUO MFA

The Challenge and the Solution

Modern enterprises demand agility. Mobile workforce and bring your own device (BYOD) trend has sparked a digital transformation. Organizations have to deal with a diverse set of users such as employees, contractors and partners who work from anywhere at anytime and on any device. The proliferation of user types, devices and access locations increases security risks for the organizations. 

It’s no longer safe to assume that users are who they say they are and their devices are secure. 

Duo’s focus is on securing access for any user connecting to any application from any device.  The new network perimeter is wherever an access decision happens. Duo protects this new perimeter by verifying user trust (confirming a user is who they say they are) using its best-in-class adaptive multi-factor authentication (MFA) solution.

As a result, Duo integrates with any application with ease, provides self-enrollment and an excellent end-user experience.

AnyConnect with DUO

Where’s the proof?
Options Technology
Facebook

WANT TO TRY IT?
Demo DUO

Need to know more? https://duo.com

Mike

Secure Internet Gateway – Cisco Umbrella

As traffic patters change to a decentralized pattern, there needs to be a way to secure traffic to the cloud.

Today we will be talking about the Secure Internet Gateway (SIG), Umbrella formally OpenDNS.

Umbrella is a recursive DNS service, it resolves DNS queries. Almost everything starts out by making a DNS request.

The process of recursive DNS look-ups are pretty straightforward. Lets walk the process.

  1. A user opens web browser and types in Amazon.com
  2. Umbrella, the recursive DNS services queries a root server. The root server only has top level domain IPs for top level domain servers. Eg. (.com, .net). The root server will reply to Umbrella “I’m not sure, but here is the IP for the .com server, ask them”
  3. Umbrella queries the TLD server (.com). The TLD server stores information on the Authoritative Name Servers for domains that end in (.com). The TLD server will reply to Umbrella “I’m not sure, but here is the IP for the Authoritative Name server, ask them”
  4. Umbrella now has the IP address of the Authoritative Name Server for Amazon.com, Umbrella will ask Amazon’s Authoritative Name Server, what is your IP address of your Amazon web site.
  5. Amazon will reply with the IP of their website. Umbrella will return the web page to your browser.Screen Shot 2018-10-08 at 11.28.00 AM

There are three scenarios when resolving DNS with Umbrella.

  • Safe – Determined as a safe DNS request. Returns IP-to-URL mapping.
  • Block – Determined as unsafe/malicious DNS request and your request is blocked. The request is blocked by a block page. A block page is configured by an administrator.
  • Inspect – Determined as a risky DNS request. Sites like peer-2-peer hosting could be considered risky. In this scenario Umbrella returns the IP address of the Umbrella proxy so that the site can be inspected.

The Inspect scenario is where Umbrella gets interesting. Proxys are now involved in the scenario. Instead of just seeing the top level domain of a URL, the proxies now inspect the entire URL and web content. It leverages AV definitions, AMP and Talos to determine the sites reputation and content.

How does Umbrella determine a site to be malicious vs non-molicous?

This recursive process is processed by algorithms known as “models” that monitors request patterns,  malicious traffic, and abnormal behavior. The output from multiple models is how a domain is determined malicious or non malicious.

Some of these models:

  • Co-Occurance model
  • Spike Rank Model
  • Predictive IP space monitoring

Umbrella Investigate is a built in capability that can give you some offensive tools when responding to security incidences.

Screen Shot 2018-09-26 at 3.00.41 PM

Investigate provides real time intelligence on domains and IPs across the Internet to help uncover anomalies and pinpoint malicious domains/IPs. Access to the intelligence is done through web console or api for you to integrate your current security infrastructure with Investigate.

Screen Shot 2018-09-26 at 3.12.20 PM

How do you use Umbrella?

Simply point your DNS to the Umbrella DNS servers. You can do this in several ways.

  • DHCP
  • The ISR 4K version 16.6.1, any traffic passing through the router will use Umbrella
  • Generate an API key through the Meraki Dashboard, integrate it into the Meraki MR
  • Out of the box integration with  Viptal vEdge
  • Cisco Any Connect (Roaming Devices)
    • AnyConnect Umbrella Roaming module
    • If not using AnyConnect, install standalone roaming client

If your clients are using the AnyConnect Umbrella module, the DNS is intercepted by the kernal driver that is sitting at the network adapter. This is the same process that AnyConnect uses when using VPN.

Screen Shot 2018-09-26 at 3.41.16 PM

If your clients are using the roaming client, all DNS requests from any running application are pointed to 127.0.0.1 and then handled by the roaming client.

Where are the Umbrella DNS servers located?

The Umbrella Data Centers are Co-Located at Major IXPs, this enables best path selections throughout the Internet via BGP. Anycast routing  is used for reliability to the DNS resolvers with no additional latency. Anycast routing improves functionality by sending your traffic to the closest data center and provides redundancy.

You can view the location of the Data Centers and the status of Cisco Umbrella systems through this link.

Data Center Locations

For more information see the documentation page Umbrella Documentation

Mike

 

 

ISE Posture Troubleshooting

Welcome to the first blog of the new year, sorry for the late start. I’ve been stuck in the trenches trying to figure out the application flow for the posturing module used in the AnyConnect client.

A client of mine is having mixed results when an endpoint authenticates and then attempts to posture to their network. Some of the symptoms that are experienced are as followed:

  • Device and user authenticates, AnyConnect reports incorrect policy server
  • User reports intermittent network interrupts during their working day
  • User receives “Untrusted server blocked!” (certificate issue)

I’ve invested a lot of time absorbing and digesting Cisco’s documentation for Cisco ISE and AnyConnect and believe at this point I have a good understanding of it.

Here is what I found and how you can perform the same troubleshooting steps to help resolve your issues.

We are focusing on Posturing. So after Authentication and Authorization is successful, posturing begins. Posturing is just a way to ensure that your endpoints are complying to your companies network policies before gaining network access.

The AnyConnect Posture Module begins by initiating policy server detection. This is accomplished through a series of probes which are known as discovery probes.

There are three probes in total, and I will show you how they look.

Probe 1 – AnyConnect sends first discovery probe to the clients default gateway. This discovery probe along with the next two are HTTP GET requests to /auth/discovery.

1discovery

This request will be intercepted by the switch that the client is connected to and present a redirect-url to the client. This redirect is that of your policy node. If your AC is unsuccessful it will attempt a second probe.

Reminder: this is all done in the background and is not known to the user

Probe 2 – AC sends second probe. A HTTP GET /auth/discovery to enroll.cisco.com. This FQDN needs to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com has to be routed through the tunnel.

2enroll

3cisco

Expected result for the probe is redirect-url to your policy nodes.

Probe 3 – HTTP GET /auth/discovery to discovery host. Discovery host value is returned from ISE during installation in AC posture profile. Expected result for the probe is redirect-url

Your AC posture profile lives here.

C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\ISEPosture.xml

Unfortunately none of these probes were successful for my client.

Posture would sometime succeed but not always. When it was successful the client was pointing to an old policy server in their old ISE 1.3 environment yet their clients were Authenticating to their new ISE 2.2 environment.  hmm..

That turned out to be a key part in resolving their issue. My client had recently migrated from ISE 1.3 to ISE 2.2. ISE 2.2 changes the way posturing works.

Posturing in ISE 2.2 assumes that redirects are not needed but does support backwards compatibility for environment that use redirects.

 

I won’t be going into detail on how posture work in ISE 2.2. But do know that there are two stages.

Stage 1 uses the same traditional discovery probes that we listed above for backwards compatibility.

Stage 2 uses two discovery probes.

Probe 1 – Attempts to discover your PSN through IP/FQDN from the “CallHome list” that are defined in your posture profile located in

C:\ProgramData\Cisco\CiscoAnyConnect Secure Mobility Client\ISE Posture\ISEPostureCFG.xml

Probe 2 – AC tries the PSN FQDNs. It generates what should be a dynamically created file (ConnectionData.xml) upon first posture attempt. That file is located here.

C:\Users\<currentuser>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\

The goal of both probes is to get FQDN. They are both there in the case where you don’t have your “CallHome List” defined for the first probe to succeed.

So after knowing this. I reference ConnectionData.xml. The .xml file had current ISE 2.3 and Old ISE 1.0 FQDNs.

I could delete and modify this file to exclude old ISE 1.0 FQDNs but it would reappear upon the next posture. I continued my troubleshooting.

I deleted ConnectionData.xml. I uninstalled the posture module from the client. I had the client re-posture so that I would receive the installation of the posture module.

I then referenced my newly dynamically generated ConnectionData.xml and bam! The .xml file only had ISE 2.3 FQDNs. It had no knowledge of old ise. Come to find out, the customer had a off line deployment package that included the ConnectionData.xml file and placed it in C:\Users\<currentuser>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\…..When AnyConnect is deployed off-line and  includes the .xml file, it creates a static entry in the file even though that file is rebuilt at each posture.

After fixing the discovery probes which was to enable http server on the default gateway where the hosts live and correcting the .xml file to exclude old ISE FQDNs. Clients were posturing to new ISE.

It’s been a long journey in this discovery but things are looking up.

 

Mike

 

CCNA 210-255 SECOPS

I recently concluded my Cisco CyberOps Scholarship program on October 20, 2017. With the conclusion came the second (210-255) of the two test to achieve your CCNA CyberOps certification.

I am sitting to write this post after several weeks of having already sat for the exam. I want to cut to the chase and report that I failed. Not once, but twice. Yes twice. I went into the the test having taken the same steps for studying for all my tests.

  1. Familiarize myself with the material
  2. Note taking
  3. Labs
  4. Walk the blue print

Walking the blue print is probably the most important part, I know that if I can answer the material found on the blue print I would be able to answer the questions on the test. It was no different in this case. I was familiar, overly familiar. and.. I failed my first attempt. After posting a fail I immediately scheduled for a second attempt.

My second attempt was ten days away. I was still a bit down on myself from posting a fail but I went to take my test with assurance that I would pass my second attempt. Question 60, the last question of the test. I’m feeling good at this point, I used reasoning from my first failed attempt to justify my answers on the second attempt, I click finish… My heart sank. On the results screen read..

“We have regret to inform you…”

I was beside my self. I was upset and didn’t understand what had just happened. I called my fiance to tell her the results. She replied with comforting words, she assured me that I was still a great engineer despite failing the test. I felt embarrassed. An NP level engineer can’t pass an NA level test? I was broken for a day after posting my second fail.

I sat to compare my results from the two attempts. I posted a 792 on both attempts. Missing the mark of 820 by one or two questions. When comparing question categories, my results from my first attempt to my second showed that I had  increased in some areas and decreased in others. Based on these results, I realized that my failure wasn’t a fact of not understanding the technical material but perhaps it was the state of mind I was in when I had taken the tests.

It would have been nice to walk out the scholarship program with a new certification, but what really matters is that I have a much better understanding of security. This understanding will help with my daily operation as well as my career development. I will continue to learn as much as I can in all realms of IT. For now, I will wait before deciding to attempt the test again. For those of you studying for your certifications; keep going, work hard.

Mike