ICMP Redirects

-

Today I wanted to share my CCIE Security notes on ICMP redirect messages.

ICMP Redirection is used to notify hosts that a better route is available for packets destined for a specific destination. This feature is available and enabled by default on all Cisco IOS releases but it is worth mentioning that there may be cases when ICMP redirection is disabled. Before diving into the details, it is important to note that ICMP redirection is disabled on interfaces that are running HSRP, this is the case for devices running pre-IOS 12.1(3) code. Cisco devices running post 12.1(3) code can still send ICMP redirect messages when HSRP is enabled on an interface.
Certain conditions need to be met in order for ICMP redirection to occur, these are as follows:
  1. The router interface in which the packet arrives must be the same interface that the packet is re-routed out of, we will discuss this further later in this post
  2. The packet is not source-routed, by this we mean the sender has not specified the route of the packet in the IP header
  3. The subnet/network of the source IP is on the same network as the next hop
It is also worth mentioning that ICMP redirect is enabled by default but if you are investigating ICMP redirect on a production network, it may have been disabled with the following command:
(config)#no ip icmp redirect
Below is a topology I created to demonstrate ICMP redirection, all command output for devices will be shown below.
 
Main Network: 172.16.1.0/24
Host2 to R2 Network: 192.168.1.0/24
Before we take a look at the configuration, lets first take a look at the packet flow in more detail by referring to the arrows in the topology below.
  1. When a packet is sent from the HOST with a destination of HOST2, the packet is sent to the default gateway of R1 (Black Arrow) and then when the packet has to be forwarded back out of the same interface to reach the destination, R1 sends an ICMP redirect message to HOST to notify HOST that a better route exists to reach the destination (Red Arrow). The ICMP redirect message tells HOST to use R2 as the next-hop IP address to reach HOST2 destination (Blue Arrow).
Below are the debug messages from R1 when HOST sends packets to HOST2
The redirect message from R1 is sent to HOST (172.16.1.5) when traffic is destined for HOST2 (192.168.1.2), you can also see that R1 tells HOST to use R2 (172.16.1.2) as the gateway.
Depending on your environment and configuration, you may or may not have ICMP redirect enabled, it is important to point out that ICMP redirect can be used by attackers as a man-in-the-middle to change the flow of traffic, which is why this feature is disabled in some environments. This feature often compliments static routing environments over dynamic routing environments where routes can be dynamically determined.

Summary of configurations

HOST(config)#do show run!hostname HOST ! interface FastEthernet0/0 ip address 172.16.1.5 255.255.255.0 duplex full 
! 
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
end
R1(config)#do show run!hostname R1
!
interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.0 duplex full
!
router ospf 1 network 172.16.1.0 0.0.0.255 area 0
!
end R2(config)#do show run ! hostname R2
!
interface FastEthernet0/0 ip address 172.16.1.2 255.255.255.0 duplex full
!
interface FastEthernet1/0 ip address 192.168.1.1 255.255.255.0 duplex full
!
router ospf 1 network 172.16.1.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0
!
end HOST2(config)#do sh run!hostname HOST2
!
interface FastEthernet1/0 ip address 192.168.1.2 255.255.255.0 duplex full
!
interface Ethernet2/0 ip address 192.168.2.1 255.255.255.0 duplex full
!
router ospf 1 network 192.168.1.0 0.0.0.255 area 0 network 192.168.2.0 0.0.0.255 area 0
! 
end
#Cisco #cciesecurity #ICMPRedirect #CCIEICMPRedirect #GNS3Labs #Labs #cciesecurityv5 #GNS3Lab #ICMPRedirection #CiscoLabs #ICMP #HSRP #CCIEICMP #ciscoios #CCIESecurityICMPRedirection
Kelvin Charles - Network and Cyber Security Professional.

Popular Posts

Capturing EAPOL and RADIUS Using Wireshark

-
Image
In this article we are going to take a look at how to capture Extensible Authentication Protocol Over LAN (EAPOL) and Remote Authentication Dial-In User Service (RADIUS) packets using Wireshark. This article can be useful for troubleshooting 802.1x within your environment and can also be used for learning purposes. The following topology has been used to gather the required output for this article. Note: This article will only cover the switch configurations that are required to gather EAPOL and RADIUS configuration. Overview of the Topology The supplicant is configured to perform 802.1x using EAP-TLS as the authentication method The user certificate on the supplicant will be used for authentication The supplicant has Wireshark installed Cisco ISE is used for authentication and authorisation The supplicant is assigned to VLAN 10 upon authentication and all other endpoint ports are assigned to VLAN 99 Sniffer device is running Wireshark in order to capture RADIUS flows via SPAN 802.1x
Read more

Configuring Cisco Smart License Software

-
In this article, I would like to demonstrate how to configure Cisco Smart Licensing on the virtual Cisco Adaptive Security Appliance (ASAv). This post assumes that readers already have access to there own Smart Account and would like to know the process of applying licenses. Step 1: Generate ID Token Sign into your Cisco Software Portal: software.cisco.com and navigate to “Smart Software Licensing” You will now need to create an ID token for your device, this is required for communication between the device and the licensing authority. Follow the steps below to create a new token. Click Inventory >>> General >>> New Token and select your preferred options and enter a description for your token. Once you are happy with your token settings click Create Token . You should now have a token created which can be copied over to the device you wish to license. All commands and output from this point will be related to the ASA so please seek out further advice if you wish
Read more

Cisco :: FXOS Authentication Using TACACS

-
In this article, I will describe how to enable authentication and authorization for Firepower eXtensible Operating System (FXOS) devices. The use case presented in this document illustrates how Cisco Identity Services Engine (ISE) can be utilised with attribute-value pairs (AV-Pairs) to authenticate and authorize users accessing the Firepower Chassis Manager (FCM) or FXOS platforms via TACACS+. At the time of writing this post, I found that limited documentation existed and of that documentation that did exist, the examples given weren’t as straightforward. In an effort to make this process easier for my colleagues and customers to understand I have put together the following instructions based on a previous use case given to me. Extracts of this document have been taken from a wider document I am currently creating. I will update this article with the complete document when it has been finalized. Requirements A ‘Device Administration’ license is required in order to use TACACS+ with
Read more

Configuring Remote Access VPN on Firepower

-
Image
In this article we are going to take a look at how to configure remote access VPN's on Firepower devices. This demonstration is based on the following lab environment: Cisco Virtual Firepower Management Center Cisco Virtual Firepower Threat Defense Cisco ISE 2.6 Windows host with AnyConnect VPN Windows Server 2019 (CA Server) All Firepower devices are running version 6.5 Note: ISE is used for authentication and authorization in the following lab however the configuration elements of ISE are out of scope for this demonstration. Generate a CSR for Remote Access VPN's Those accessing your network remotely need to trust the service you're running. Without the correct trust users could face issues connecting via VPN. With access to the FMC navigate to Objects > Object Management > PKI > Cert Enrollment Assuming you are opting for manual enrollment, select 'Manual' in Enrollment Type and copy the CA Certificate BASE-64 into the field. Now select the 'Certifi
Read more

Kali Linux :: CAM Table Overflow Attack Demonstration

-
Image
As part of my on-going studying for the CCNA Security 210 – 260 certification I have been exploring different types of network attacks, one of which is CAM table overflow attacks. In this article I would like to share what I have learnt and provide a demonstration of the attack carried out in a lab environment. To understand my demonstration, you first need to understand how a CAM table overflow attack works and what happens as a result of the attack.   Switches build Content Addressable Memory (CAM) tables based on mac-addresses and port numbers. When a switch receives a frame it checks the table to see if the source mac-address is already known, if the source mac-address is unknown the switch will add the mac-address to the table along with the port number. The switch then checks the destination layer two frame and if no entry exists the switch broadcasts the frame out of all ports except the port in which the frame was received. Presuming the destination mac-address wants to respond
Read more