Paul Stewart, CCIE 26009 (Security)
Author Archives: Paul Stewart, CCIE 26009 (Security)
- Home → Author's archive:
Paul Stewart, CCIE 26009 (Security)
Redirecting DNS Requests to Umbrella with FTD
A few days ago I shared an article that described redirecting DNS requests with ASA. A good use case for this might be if an organization is using Cisco Umbrella but there is no way to get every host is pointed toward the correct DNS server(s) in a timely manner. In that case, a configuration of destination NAT in the ASA can force those misconfigured clients to use one of the OpenDNS addresses.
This article is very similar, but we will share a method for doing this with Firepower Threat Defence. The concept is the same but all configuration is done in Firepower Management Console. Before starting on the NAT configuration, it is important to configure the following network objects (Objects, Object Management, Network).
- obj_any – 0.0.0.0/0
- Umbrella1 – 208.67.220.220
- Umbrella2 – 208.67.222.222
It is also important to confirm the existence of two port objects (Objects, Object Management, Network).
- DNS_over_TCP – TCP Port 53
- DNS_over_UDP – UDP Port 53
Most of the configuration will be done on the NAT policy for the device we are managing (Device, NAT, select edit for the appropriate NAT policy).
We will need four rules that Continue reading
When Firepower Management Center Goes Offline
A typical Firepower deployment consists of a management component and a managed device. The management component is known as Firepower Management Center (FMC). The managed device is the NGIPS or NGFW itself and would be leveraging the Firepower or the Firepower Threat Defense (FTD) operating system. Both layers of the topology include provisions for redundant deployments. Firepower Management Center is available in a two-node HA configuration. Firepower Threat Defense, the NGFW managed device, can be either HA or clustered.
One question that often comes up is, “What happens when FMC goes offline?” The general response is traffic continues to flow but the managed device cannot be managed. While this is not a good position to be in, it does provide an opportunity to assess the impact of waiting for a maintenance window (or a replacement).
TL;DR
- Firepower continues to pass traffic when FMC is offline
- Events captured on the Firepower device will be passed to the FMC when it is available
- Event Storage on the managed device is finite, events may be lost during an extended outage
- Malware Cloud Lookups/Block functionality depends on FMC, plan HA and File Policy accordingly
- Firepower managed device cannot be managed until FMC is available
When Firepower Management Center Goes Offline
A typical Firepower deployment consists of a management component and a managed device. The management component is known as Firepower Management Center (FMC). The managed device is the NGIPS or NGFW itself and would be leveraging the Firepower or the Firepower Threat Defense (FTD) operating system. Both layers of the topology include provisions for redundant deployments. Firepower Management Center is available in a two-node HA configuration. Firepower Threat Defense, the NGFW managed device, can be either HA or clustered.
One question that often comes up is, “What happens when FMC goes offline?” The general response is traffic continues to flow but the managed device cannot be managed. While this is not a good position to be in, it does provide an opportunity to assess the impact of waiting for a maintenance window (or a replacement).
TL;DR
- Firepower continues to pass traffic when FMC is offline
- Events captured on the Firepower device will be passed to the FMC when it is available
- Event Storage on the managed device is finite, events may be lost during an extended outage
- Malware Cloud Lookups/Block functionality depends on FMC, plan HA and File Policy accordingly
- Firepower managed device cannot be managed until FMC is available
Where to Use a VRF
Very early in our careers, we learn about physical and logical network segmentation. Generally speaking, that understanding comes in the form represented by the diagrams below.
Depending on the work environment of an individual, it may take some time before they are exposed to the methods that provide segmentation to routed parts of the network. Looking at the diagram above, let’s think about what is being accomplished in each example. The physical segmentation provides full isolation between the two hosts. This article examines the construct used to extend segmentation into a routed network. We will not get into the configuration details but will share some links to additional content that can provide practical guidance on the configuration.
VLANs only provide segmentation at layer 2. This would provide isolation for things like ARP and other broadcasts. VLANs would also provide full segmentation if a router didn’t exist for a given VLAN. However, it is often necessary to extend this into the routed portions of our networks. In the above example, I would expect properly configured routers and switches to allow the two hosts on the right to communicate with one another. What if that is not the goal? We might consider Continue reading
What’s in a Mutable Field? — We Can’t Tell You
In conversations I often hear people using the word “mutable”. Typically it would be something similar to the following.
The IP TTL is a mutable field and decreases as it traverses a router.
If we look up the word “mutable” we find that it is something that is likely to change.
So the IP TTL is a great example of a mutable field. That value is expected to decrease at each hop throughout the network.
By contrast, IP Source Address, Destination Address, and Protocol would be immutable because it is not normal for those to change. They should stay constant from source to destination.
I know someone might consider something like NAT or PAT to change some of these attributes. While that is true, I still would not consider those mutable fields.
Packet Size, It Matters
As I mentioned in a previous post, I have been studying the materials for the Cisco CCDE. One thing that has come up only a time or two is that of MTU. MTU, or maximum transmission unit, is the maximum size a chunk of data can be for a given interface. In this article, we are speaking specifically of IP MTU and this is an important distinction that I will clarify later. Network design should incorporate a clear understanding of MTU challenges and operators need to understand what to look for when it is not properly built and configured.
A simplistic example of a problematic design is when there is a link with a smaller MTU somewhere between two endpoints capable of creating larger packets (see the image below). While this environment may work fine, understanding the interaction required between the hosts and the network devices is very important to network design.
A few years ago I wrote an article that outlined some of the behavior that can be witnessed when there are MTU discovery issues. Let’s quickly recount what path MTU discovery (PMTU-D) is, how it works, how it fails and some logic around appropriate design.
General Facts Around Continue reading
Routing Loop, Failure by Design
I have spent some time studying the CCDE materials. One broken design example that has come up involves route reflector clients that don’t align with the physical topology. This article examines that example and some solutions to the problem.
To illustrate this example we have built the topology below. I used loopback addresses 1.1.1.1 through 6.6.6.6 (based on csr1000v-x). The router on the top is a eBGP neighbor with csr1000v-1 and csr1000v-2. The four routers forming a square in the center have an initial configuration of OSFP and BGP (iBGP as shown). Both Route Reflectors are peered with both clients.
Route Reflector Initial Configuration
//csr1000v-2 shown, csr1000v-3 similar router ospf 1 router-id 2.2.2.2 passive-interface GigabitEthernet2 network 2.2.2.2 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 router bgp 64513 bgp router-id 2.2.2.2 bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 64513 neighbor 3.3.3.3 update-source Loopback0 neighbor 4.4.4.4 remote-as 64513 neighbor 4.4.4.4 update-source Loopback0 neighbor 4.4.4.4 route-reflector-client neighbor 5.5.5.5 remote-as 64513 Continue reading
Routing Loop, Failure by Design
I have spent some time studying the CCDE materials. One broken design example that has come up involves route reflector clients that don’t align with the physical topology. This article examines that example and some solutions to the problem.
To illustrate this example we have built the topology below. I used loopback addresses 1.1.1.1 through 6.6.6.6 (based on csr1000v-x). The router on the top is a eBGP neighbor with csr1000v-1 and csr1000v-2. The four routers forming a square in the center have an initial configuration of OSFP and BGP (iBGP as shown). Both Route Reflectors are peered with both clients.
Route Reflector Initial Configuration
//csr1000v-2 shown, csr1000v-3 similar router ospf 1 router-id 2.2.2.2 passive-interface GigabitEthernet2 network 2.2.2.2 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 router bgp 64513 bgp router-id 2.2.2.2 bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 64513 neighbor 3.3.3.3 update-source Loopback0 neighbor 4.4.4.4 remote-as 64513 neighbor 4.4.4.4 update-source Loopback0 neighbor 4.4.4.4 route-reflector-client neighbor 5.5.5.5 remote-as 64513 Continue reading
Routing Loop, Failure by Design
I have spent some time studying the CCDE materials. One broken design example that has come up involves route reflector clients that don’t align with the physical topology. This article examines that example and some solutions to the problem.
To illustrate this example we have built the topology below. I used loopback addresses 1.1.1.1 through 6.6.6.6 (based on csr1000v-x). The router on the top is a eBGP neighbor with csr1000v-1 and csr1000v-2. The four routers forming a square in the center have an initial configuration of OSFP and BGP (iBGP as shown). Both Route Reflectors are peered with both clients.
Route Reflector Initial Configuration
//csr1000v-2 shown, csr1000v-3 similar router ospf 1 router-id 2.2.2.2 passive-interface GigabitEthernet2 network 2.2.2.2 0.0.0.0 area 0 network 10.0.0.0 0.255.255.255 area 0 router bgp 64513 bgp router-id 2.2.2.2 bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 64513 neighbor 3.3.3.3 update-source Loopback0 neighbor 4.4.4.4 remote-as 64513 neighbor 4.4.4.4 update-source Loopback0 neighbor 4.4.4.4 route-reflector-client neighbor 5.5.5.5 remote-as 64513 Continue reading
Validating SGT Inline with Netflow and Embedded Packet Capture
In the last article, Learning TrustSec, An Introduction to Inline Tagging, we took a quick look at manual configuration of SGT Inline Tagging in a manual configuration. We also performed some validation with show commands and proved the operation by enabling enforcement.
In today’s article, we will perform slightly deeper validation of the inline imposition itself. For this process, we will use Netflow and Embedded Packet Capture. I happen to know that there is already EIGRP traversing the link that will help produce some output. Let’s just jump right in with a very basic Netflow configuration.
Netflow Configuration
//you could additionally configure and exporter //if there is a proper netflow collector flow record my_record_output match flow cts source group-tag match flow cts destination group-tag match ipv4 source address match ipv4 destination address match ipv4 protocol match transport source-port match transport destination-port flow monitor my_monitor_output record my_record_output ! interface GigabitEthernet1/0/1 description trunk to c9kSW2 switchport mode trunk ip flow monitor my_monitor_output output cts manual policy static sgt 100 trusted
Verification Using Netflow
c9kSW1#show flow monitor my_monitor_output cache
Cache type: Normal (Platform cache)
Cache size: 10000
Current entries: 1
Flows added: 9
Flows aged: 8
- Active timeout ( 1800 secs) 2
- Continue reading
Validating SGT Inline with Netflow and Embedded Packet Capture
In the last article, Learning TrustSec, An Introduction to Inline Tagging, we took a quick look at manual configuration of SGT Inline Tagging in a manual configuration. We also performed some validation with show commands and proved the operation by enabling enforcement.
In today’s article, we will perform slightly deeper validation of the inline imposition itself. For this process, we will use Netflow and Embedded Packet Capture. I happen to know that there is already EIGRP traversing the link that will help produce some output. Let’s just jump right in with a very basic Netflow configuration.
Netflow Configuration
//you could additionally configure and exporter //if there is a proper netflow collector flow record my_record_output match flow cts source group-tag match flow cts destination group-tag match ipv4 source address match ipv4 destination address match ipv4 protocol match transport source-port match transport destination-port flow monitor my_monitor_output record my_record_output ! interface GigabitEthernet1/0/1 description trunk to c9kSW2 switchport mode trunk ip flow monitor my_monitor_output output cts manual policy static sgt 100 trusted
Verification Using Netflow
c9kSW1#show flow monitor my_monitor_output cache
Cache type: Normal (Platform cache)
Cache size: 10000
Current entries: 1
Flows added: 9
Flows aged: 8
- Active timeout ( 1800 secs) 2
- Continue reading
Validating SGT Inline with Netflow and Embedded Packet Capture
In the last article, Learning TrustSec, An Introduction to Inline Tagging, we took a quick look at manual configuration of SGT Inline Tagging in a manual configuration. We also performed some validation with show commands and proved the operation by enabling enforcement.
In today’s article, we will perform slightly deeper validation of the inline imposition itself. For this process, we will use Netflow and Embedded Packet Capture. I happen to know that there is already EIGRP traversing the link that will help produce some output. Let’s just jump right in with a very basic Netflow configuration.
Netflow Configuration
//you could additionally configure and exporter //if there is a proper netflow collector flow record my_record_output match flow cts source group-tag match flow cts destination group-tag match ipv4 source address match ipv4 destination address match ipv4 protocol match transport source-port match transport destination-port flow monitor my_monitor_output record my_record_output ! interface GigabitEthernet1/0/1 description trunk to c9kSW2 switchport mode trunk ip flow monitor my_monitor_output output cts manual policy static sgt 100 trusted
Verification Using Netflow
c9kSW1#show flow monitor my_monitor_output cache
Cache type: Normal (Platform cache)
Cache size: 10000
Current entries: 1
Flows added: 9
Flows aged: 8
- Active timeout ( 1800 secs) 2
- Continue reading
Learning TrustSec – An Introduction to Inline Tagging
In my last article, Basic TrustSec – Implementing Manual SGTs and SGACLs,
we talked about a basic TrustSec configuration. In that example, we shared the understanding of having two devices connected to a single switch and enforcing traffic policies via SGACL. We know that there are more scalable and automated ways to configure TrustSec enabled networks, but our goal is to work toward understanding the building blocks.
In today’s article, we will expand our knowledge and connect the two devices to different switches. The trunks between these switches will be configured to carry the associated source SGT’s (Security Group Tags). The topology used for this discussion is as follows.
Topology
To demonstrate the topic of inline SGT, we will need to accomplish the following.
- Configure and Confirm that 192.168.254.11 (connected to c9kSW1) is recognized by its switch with an SGT of 2.
- Configure and Confirm that 192.168.254.100 (connected to c9kSW2) is recognized by its switch with an SGT of 3.
- Configure the trunk between the switches to carry SGTs
- Configure an enforcement policy to demonstrate overall functionality
Configuration Steps
c9kSW1 configuration/confirmation for host port
//We are using static SGT and need to do IP Device Continue reading
Learning TrustSec – An Introduction to Inline Tagging
In my last article, Basic TrustSec – Implementing Manual SGTs and SGACLs,
we talked about a basic TrustSec configuration. In that example, we shared the understanding of having two devices connected to a single switch and enforcing traffic policies via SGACL. We know that there are more scalable and automated ways to configure TrustSec enabled networks, but our goal is to work toward understanding the building blocks.
In today’s article, we will expand our knowledge and connect the two devices to different switches. The trunks between these switches will be configured to carry the associated source SGT’s (Security Group Tags). The topology used for this discussion is as follows.
Topology
To demonstrate the topic of inline SGT, we will need to accomplish the following.
- Configure and Confirm that 192.168.254.11 (connected to c9kSW1) is recognized by its switch with an SGT of 2.
- Configure and Confirm that 192.168.254.100 (connected to c9kSW2) is recognized by its switch with an SGT of 3.
- Configure the trunk between the switches to carry SGTs
- Configure an enforcement policy to demonstrate overall functionality
Configuration Steps
c9kSW1 configuration/confirmation for host port
//We are using static SGT and need to do IP Device Continue reading
Learning TrustSec – An Introduction to Inline Tagging
In my last article, Basic TrustSec – Implementing Manual SGTs and SGACLs,
we talked about a basic TrustSec configuration. In that example, we shared the understanding of having two devices connected to a single switch and enforcing traffic policies via SGACL. We know that there are more scalable and automated ways to configure TrustSec enabled networks, but our goal is to work toward understanding the building blocks.
In today’s article, we will expand our knowledge and connect the two devices to different switches. The trunks between these switches will be configured to carry the associated source SGT’s (Security Group Tags). The topology used for this discussion is as follows.
Topology
To demonstrate the topic of inline SGT, we will need to accomplish the following.
- Configure and Confirm that 192.168.254.11 (connected to c9kSW1) is recognized by its switch with an SGT of 2.
- Configure and Confirm that 192.168.254.100 (connected to c9kSW2) is recognized by its switch with an SGT of 3.
- Configure the trunk between the switches to carry SGTs
- Configure an enforcement policy to demonstrate overall functionality
Configuration Steps
c9kSW1 configuration/confirmation for host port
//We are using static SGT and need to do IP Device Continue reading
Basic Trustsec – Implementing Manual SGTs and SGACLs
Trustsec is a mature and interesting policy mechanism available in most Cisco gear. The features and capabilities vary depending on device type and class. One of the frustrations I have is that almost every Trustsec reference I find focuses on the use of ISE. While I consider ISE a key component, I think a manual configuration is a better way to understand the components of the solution.
This post is the first in a series that will go through the configuration of Trustsec in various places in the network. I hope to examine classification and tag assignment, propagation techniques and enforcement. Ultimately, I will introduce ISE but it will be the tool that makes this technology dynamic and robust. The goal is to build a better foundation by taking a step by step approach into the world of Trustsec.
In this article, I will simply build a network with a Catalyst 9300 and two devices. One device will be assigned an SGT of 2 and the other will receive an SGT of 3. I understand that many are concerned about the fact that they don’t have this class of switch at the access layer. Future articles will address how Trustsec Continue reading
Basic Trustsec – Implementing Manual SGTs and SGACLs
Trustsec is a mature and interesting policy mechanism available in most Cisco gear. The features and capabilities vary depending on device type and class. One of the frustrations I have is that almost every Trustsec reference I find focuses on the use of ISE. While I consider ISE a key component, I think a manual configuration is a better way to understand the components of the solution.
This post is the first in a series that will go through the configuration of Trustsec in various places in the network. I hope to examine classification and tag assignment, propagation techniques and enforcement. Ultimately, I will introduce ISE but it will be the tool that makes this technology dynamic and robust. The goal is to build a better foundation by taking a step by step approach into the world of Trustsec.
In this article, I will simply build a network with a Catalyst 9300 and two devices. One device will be assigned an SGT of 2 and the other will receive an SGT of 3. I understand that many are concerned about the fact that they don’t have this class of switch at the access layer. Future articles will address how Trustsec Continue reading
Basic Trustsec – Implementing Manual SGTs and SGACLs
Trustsec is a mature and interesting policy mechanism available in most Cisco gear. The features and capabilities vary depending on device type and class. One of the frustrations I have is that almost every Trustsec reference I find focuses on the use of ISE. While I consider ISE a key component, I think a manual configuration is a better way to understand the components of the solution.
This post is the first in a series that will go through the configuration of Trustsec in various places in the network. I hope to examine classification and tag assignment, propagation techniques and enforcement. Ultimately, I will introduce ISE but it will be the tool that makes this technology dynamic and robust. The goal is to build a better foundation by taking a step by step approach into the world of Trustsec.
In this article, I will simply build a network with a Catalyst 9300 and two devices. One device will be assigned an SGT of 2 and the other will receive an SGT of 3. I understand that many are concerned about the fact that they don’t have this class of switch at the access layer. Future articles will address how Trustsec Continue reading
How Does Your Organization Value Technology?
Just a quick thought here today. Thinking about the organization you work for or the organizations you work with, how would you say they view technology?
- Key to Success – Technology is an enabler AND a primary differentiator
- Important – The core business requires a commitment to technology to succeed
- Just Another Budget Item – Technology is a necessary evil
It is important to realize how valuable technology is to your organization or organizations we work with. If the business views our skills as key differentiators, work will be much more rewarding. If technology is just a necessary evil, it will be cut with everyone else’s budget.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.
How Does Your Organization Value Technology?
Just a quick thought here today. Thinking about the organization you work for or the organizations you work with, how would you say they view technology?
- Key to Success – Technology is an enabler AND a primary differentiator
- Important – The core business requires a commitment to technology to succeed
- Just Another Budget Item – Technology is a necessary evil
It is important to realize how valuable technology is to your organization or organizations we work with. If the business views our skills as key differentiators, work will be much more rewarding. If technology is just a necessary evil, it will be cut with everyone else’s budget.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.