Below is a chat session I had with Pearson Vue several months ago as I attempted to schedule a recertification exam. Apparently, I have two accounts with them and that prevents next day test scheduling. To put it mildly, I don’t think they adequately explain how they could possibly guarantee non-disclosure of data with email as a transport. Moreover, this seems to indicate a serious disconnect between security and business operations.
Image Link – for FULL Size View
Since seeing the APIC-EM Path Trace demo for the first time and seeing how it represents CAPWAP, I’ve been curious how well it deals with other types of overlay/underlay networking. This article is a brief synopsis of that testing and provides some visuals around what was produced with this free management tool.
TL;DR–APIC-EM adds value to most network path traces and typically represents what it knows. The single exception is with MPLS VPNv4. If the MPLS PE nodes are pulled into the device inventory, path trace has a total lack of understanding around the recursive lookup into the global vrf that is required for VPNv4 functionality.
CAPWAP Representation — The Gold Standard
I wanted to start out by showing what an ideal representation of an overlay network would be for a tool like this. Path Trace understands AND clearly represents both the underlay and the overlay network for traffic flowing through a CAPWAP tunnel. The image below shows the extent of the tunnel (darker gray) and the physical components that are responsible for delivery (both through the tunnel and outside of the tunnel).
I wanted to take just a moment to share the output of an APIC-EM ACL Trace (option in Path Trace). For this example, I have built out the topology below.
The applicable configuration for CSR1000v-2 is as follows– Continue reading
So I’m sure this is in the documentation somewhere. But for anyone else out there who is getting inconsistent results with FLAT interfaces in VIRL, Promiscuous Mode support in ESXi seems to be a requirement. Definitely something to check…
I’ve been leveraging VIRL for some time to build and test self-contained labs. I’ve always known that there was some ability to connect to the world outside of this environment. Recently, I decided to configure this functionality and I wanted to take just a moment to share what I found.
First and foremost, this isn’t anything difficult or time consuming. So if you have a need to leverage physical devices with your VIRL deployment, don’t hesitate before building it out.
There are two mechanisms for outside connectivity. The first mechanism is called SNAT. This method basically builds static NAT in and out of the environment. I get how this could be beneficial, but I would typically prefer to keep any NAT configuration contained to an environment that I am very familiar with (possibly an ASA or IOS instance outside the lab when an additional NAT layer is required).
The second method, and configuration we will be testing is called FLAT. In this configuration, VIRL connects a L2 broadcast domain between a lab device and an Ethernet interface. In my example I am running the VIRL components in a VM environment on ESXi. So this is a virtual interface that needs to be mapped through the VMWare vSwitch.
To test this functionality, I created the following topology.
From a VIRL perspective, there are a couple of things to be aware of. The default configuration would have VIRL owning the subnet and the external default GW existing at 172.16.1.1. Continue reading
Several years ago I wrote an article about the Woes of Using an ASA as a Default Gateway. I have received a lot of feedback about this post and recently had a request for an update around ASA > 8.3. When building this scenario out with current ASA code, I found that the base NAT configuration (internet only PAT) had no bearing on the hairpin configuration. As expected, I found the same challenge around state bypass. I wanted to share a current post that demonstrates the challenges and solutions when traffic is bounced off the inside interface of the ASA.
The requirements of the configuration are as follows–
- TestHost must be able to Telnet and Ping to Internet and PartnerHost
- The inside interface of asav-1 must be the default gateway for TestHost
- asav-1 is doing PAT for Internet destined traffic
- PartnerRTR and ParnterHost have been preconfigured as shown above
The following are the base configurations for all of the devices. The configuration of asav-1 does not seem to allow communication from TestHost to PartnerHost (188.8.131.52/24 network). Continue reading
Peer to peer applications are a significant challenge for policy enforcement solutions. Any flows that slip through as an undetermined application type may allow the file sharing app to function. The first key to addressing this challenge is simple visibility into which hosts or users may be abusing the AUP with these types of applications. This article shows a quick and easy way to create Peer to Peer dashboard in the Firepower Management Console.
For those that have already attempted this, there are a number of challenges that may have surfaced. First there are no readily available widgets or criteria that will show the desired information. Experimenting with search constraints and the connection table quickly reveals that the desired information can be easily accessed by using the “peer to peer” Application Protocol Category search criteria. Unfortunately, the Connection Table is not readily available to the Dashboard Widgets. The Connection Summary table is available, but it does not have the Application Protocol Category (required for the search constraints).
My goal was to build a few dashboard widgets to give visibility into Peer to Peer activity. For this article I will demonstrate the steps required to build those widgets. The first widget will provide a list of Peer to Peer applications on the network, the second will provide a list of initiating IP addresses of peer to peer connections, and the third widget will sort actions taken on peer to peer traffic. All of these will be sorted based on the connection count.
To overcome the challenge of not having access to the Connection Table from the Dashboard Widgets, it is necessary to create a custom table. To do so, choose Analysis, Custom > Tables, Custom Tables.
The next step is to create a new Custom Table by choosing Create Custom Table. This allows for logical table joins between tables that contain combinable data. For this example, there is really only a need for a handful of fields from Connection Events. However, it is necessary to add at least one field from another table to allow the custom table creation. I have added the following fields from Connection Events: Application Protocol, Application Protocol Category, Initiator IP, and Action. I have also added IP Address from the Hosts table so it contains fields from multiple tables. This isn’t really necessary, but the UI doesn’t allow it to be saved otherwise. Continue reading
The Firepower ecosystem is a powerful NGIPS/NGFW solution. At that heart of the configuration construct is what is known as the Access Control Policy. Comparing this to something familiar is possible by thinking about the much simpler filtering feature in the ASA. For comparison, an ASA’s access-list (ACL) has multiple access-control entries (ACE’s). Each of these entries can refer to object-groups, networks, and protocols and can apply a permit or deny action.
The Access Control Policy in Firepower is a similar concept, but there are many additional facets that are pulled together to provide a more comprehensive policy application mechanism. This article only covers the major areas of this policy control construct. There are items which are beyond the scope including variable sets and manipulating the behavior of http response pages.
Specific to the policy application, there are two main areas of the the Access Control Policy. The first area is what is known as Security Intelligence. In the policy, this is found on the second tab from the left and provides a framework for blacklisting. There are many feeds provided directly from Cisco’s Talos organization and are ready for consumption by the security policy.
The action for each feed that is blacklisted can be set to monitor only or to block. These events will be logged as Security Intelligence Events and may raise an Indication of Compromise. It is also this tab that will allow for the selection of a DNS Policy. Worth noting is that whitelisting is an override for blacklisting. Whitelisting does not preclude processing against the remaining Firepower Access Control Rules.
The second, and most visible, component contains the Access Control Rules. This is located in the left-most tab of the Access Control Policy. The section is a familiar construct in which rules are processed in a top-down manner until a match occurs. In the case that the action is Monitor, further processing occurs. If the action is Trust, Allow or Block, rule processing terminates and the appliance will process the traffic accordingly. A Trust action indicates that the traffic should be fully trusted and not subject to IPS checks (against the Snort signatures). Allowed traffic may be sent to IPS for additional processing.
About six months ago I installed an Energy Efficient water heater. This unit is what is known as a heat pump water heater. For those not familiar with refrigeration, this works by moving heat instead of creating heat. By contrast, traditional electric water heaters use resistance coils to heat the water. This new unit also has traditional coils that can be used for high demand or high temperature settings as well.
I guess by now everyone is wondering what this has to do with the topics we discussed at PacketU. To better understand the relationship, you can see that this Water Heater is also Connected to the Internet. The primary reasons I wanted to connect it to the Internet was to schedule the modes around my family’s usage patterns and control vacation mode from a mobile phone. When purchasing this unit I was quite skeptical and was concerned about transitioning from a simple conventional model to a mode that literally has moving parts. Continue reading
Several days ago I wrote an article about Firepower Sinkhole rules. While I was confirming this in a lab, I temporarily created a custom DNS sinkhole rule. That rule classified requests for temp.packetu.com as Command and Control and returned an IP address of 184.108.40.206. What I later noticed is that this caused my laptop to be classified with an IOC.
Indications of Compromise (IOCs) can be thought of as reasons why Firepower Management Console believes a host cannot be trusted or is otherwise affected by malware. These can be found in multiple places in the UI. I find the Context Explorer to be a good middle ground for most SecOps team members and a good place to notice whether current IOC’s exist.
My network is rather simple and I only currently have one IOC. In any case, I can use the Context Explorer to launch the host information for the impacted host.
Once the Host Profile screen is launched, I can get a little more about information about the activity that causes Firepower to believe that this is a compromised host. Continue reading
Several years ago I wrote an article called The Elusive “access-class out” Command. My primary goal was to help CCNA students understand both the behavior of and placement of this command. My friend Anthony Sequeira done a great job in the video that is also shown in my original post. Today, I want to share another command and expand on there behavior.
For all of the demonstrations in this article, the following topology will be used. The router named iosv-2 will be the primary focus and the only place changes will be made.
Backing up for a moment, there are a couple of messages that might be displayed when an IOS device blocks outbound telnet or ssh sessions from the current exec session. These are demonstrated with a quick configuration of an transport output and access-class restriction.
//the first error is unique depending on
//if ssh or telnet is being used
iosv-2(config)line con 0
iosv-2(config-line)#transport output none
iosv-2(config-line)#do telnet 192.168.0.3
% telnet connections not permitted from this terminal
iosv-2(config-line)#do ssh -l cisco 192.168.0.3
% ssh connections not permitted from this terminal
//now we can re-enable all the protocols
//and demonstrate the other error message
iosv-2(config-line)#transport input all
iosv-2(config-line)#access-list 1 deny 192.168.0.3
iosv-2(config)line con 0
iosv-2(config)#access-class 1 out
iosv-2(config-line)#do telnet 192.168.0.3
Trying 192.168.0.3 ...
% Connections to that host not permitted from this terminal
It is worth noting that in the second example, the error message is agnostic to the protocol being used (ssh or telnet). Continue reading