Capturing EAPOL and RADIUS Using Wireshark

-

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 Overview


When a supplicant sends an authentication request, the supplicant will send layer 2 EAPOL frames to the authenticator (access switch) and then the switch will repackage that into RADIUS and forward the packets at layer 3 to the authentication server.



If we further break it down we can see what happens at an high-level with the EAPOL frames and EAP packets. The below diagram is referenced from cisco.com and shows the EAPOL and EAP flows, the only difference is that we will be using EAP-TLS rather than EAP-PEAP. Nevertheless if you would like to read more about deploying 802.1x you can visit the following link where the diagram below is taken from: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html


Demonstration


In order to capture the full flow of an authentication request, we need to make sure we have the following set up.

Supplicant

  • Supplicant must be configured with for EAP-TLS
  • Supplicant must have Wireshark installed
Authenticator
  • Authenticator configured with AAA so that authentication requests are sent to the authentication server
  • Authenticator configured with SPAN for the sniffer
Sniffer
  • Configued with Wireshark to capture RADIUS flows
  • Connected to a SPAN port in the Authenticator

Authenticator SPAN Configuration


The following configuration is required to enable the SPAN port on the authenticator switch as shown in the lab topology.

conf t
monitor session 1 source interface vlan 10 both
monitor session 1 destination interface vlan 99 encapsulation replicate


Wireshark Captures


With all the other configuration elements in place, open Wireshark on both the supplicant and Sniffer device and attempt to authenticate the supplicant device. We will need to filter the Wireshark logs to just EAPOL and RADIUS.

As the supplicant is only performing EAPOL, lets start by filtering for those on the supplicants Wireshark first. You can enter one of the two following filters:

  • eapol
  • eapol && eth.addr == 48:0f:cf:dc:cb:90 && eth.addr == 64:f6:9d:01:f7:17 (Replacing the mac addresses to match your supplicant and authentication server)
Both of the filters should work however you may want to use one over the other based on results. I noticed that when the 'eapol' filter is used I can see more information and this is because the supplicant sending EAPOL frames will send the frames to the nearest destination rather than specifying a destination mac-address.

You should see the following results within the packet capture from the supplicant.

EAPOL Filter

EAPOL Filter with mac addresses defined

Now we need to filter for RADIUS on the sniffer device. To do this you can enter one of the following filters
  • radius
  • radius && ip.addr == 172.16.0.9 && ip.addr == 172.16.0.254 (Replacing the IP addresses with your authenticator IP address and authentication server IP address)



You should now have been able to capture a full authentication flow for 802.1x.

Update 20/11/19


One of my readers reached out to me on Twitter a few days ago and asked why I decided to capture the flows on different devices rather than just using the span port. This was a very good question and one that I didn't put too much thought into while producing the lab so I wanted to add some additional information that could help you in the future.

So, when exactly would one use the above demonstration to troubleshoot their environment? Let's explain some use cases below!

Use Cases


Using the above demonstration, you may decide you want to use this method of troubleshooting in your environment if you have access to the supplicant and also access to the switch.

But what happens when you don't have access to the supplicant but you need to troubleshoot the flows?

What if you still have access to the supplicant but don't want to run captures on both devices?

Well you could use the same method as I've discussed above but without the supplicant device. To do this you would simply configure the authenticator span port to send the supplicant source information too. To break it down some more, lets say you had the supplicant in VLAN 10 and the source for RADIUS requests in VLAN 99, you could use the following configuration to ensure that the span port receives the desired frames and packets.

monitor session 1 source vlan 99
monitor session 1 source vlan 10
monitor session 1 destination interface Gi1/0/21 encapsulation replicate

When issuing a the show command, you should see the following output:

show monitor session 1
Session 1
---------
Type : Local Session
Source VLANs :
Both : 10,99
Destination Ports : Gi1/0/21
Encapsulation : Replicate
Ingress : Disabled

Note that you would still need somebody on site to physically plug a device into the span port that is capable of sniffing the traffic but once that's done all you need to do is play with your Wireshark filters in order to get the same information you would from the supplicant.

Your filter could be something as simple as:

radius or eapol

Which would output similar information as shown below:







Kelvin Charles - Network and Cyber Security Professional.

Popular Posts

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