Guest

Cisco Catalyst 6500 Series Switches

DHCP Consumption Attack and Mitigation Techniques White Paper

  • Viewing Options

  • PDF (5.9 MB)
  • Feedback

DHCP Consumption Attack and Mitigation Techniques

Authors:
Kevin Lauerman, CCSP, CISSP 80877
Jeff King, CCIE 11873, CCSP, CISSP 80875

Abstract

Security is at the forefront of most networks and many companies implement a comprehensive security policy encompassing many of the OSI layers, from application layer all the way down to IP security. However, one area that is often left untouched is hardening layer 2 and this can open the network to a variety of attacks and compromises.

This document has a focus on understanding and preventing Layer 2 attacks on the Cisco® Catalyst® 6500 switching platform. Denial-of-Service (DoS) attacks are always a major concern as they can come from both internal and external sources. The focal point of this white paper is to understand how a DHCP Consumption Attack (DoS Attack) works and what techniques can be used on the Cisco Catalyst 6500 switch running Cisco IOS Software to mitigate this type of attack. An attack tool called Yersina was used to invoke this attack.

A MacBook Pro laptop running VMware and Ubuntu (a Linux-based operating system) was used in the test.

Note that the attack performed in this document was done in a controlled lab environment. We do not recommend that you perform this attack on your enterprise network.

Test Equipment

A Cisco Catalyst 6509E switch with a Supervisor 720-3B running Cisco IOS Software 12.2(33)SXI1 with an Advanced Enterprise Feature Set and a WS-X6748-GE-TX (10/100/1000) Ethernet line card was used to provision the network under attack. The MacBook Pro ran Mac OS X version 10.5.7 along with VMware Fusion (2.0.5) and an Ubuntu 9.04 Virtual Machine running inside VMware. A Linksys USB300M (USB-to-10/100 Ethernet) NIC was used by the laptop for network connectivity. By using this particular NIC, it did not have to perform any Bridging or NAT functions in VMware. The Ubuntu 9.04 Virtual Machine recognizes the USB-to-Ethernet NIC, so the Virtual Machines network connection was independent of the host Operating Systems (Mac OS X).

WireShark was used as the packet analyzer in addition to using a series of debug commands on the Cisco Catalyst 6509E switch to show how the attack was initiated and the response/actions that the switch used.

DHCP Consumption Attack

The intent of the DHCP Consumption Attack is for the Attacker to prevent hosts from gaining access to the network by denying them an IP address by consuming all of the available IP address in the DHCP Pool.

All Cisco Catalyst switch models use a CAM table for Layer 2 switching. As frames arrive on switch ports, the source MAC addresses are learned and recorded in the CAM table. The port of arrival and the VLAN are both recorded in the table, along with a time stamp. If a MAC address learned on one switch port has moved to a different port, the MAC address and time stamp are recorded for the most recent arrival port. Then, the previous entry is deleted. If a MAC address is found already present in the table for the correct arrival port, only its time stamp is updated.

Each scenario is run twice; once with the IP address coming from the DHCP server and once using a static IP address from the same subnet as the IP address in the DHCP server's pool. Since the outcome of the DHCP Consumption attack will be the same no matter if an IP address is used from the DHCP Server or a static IP address is used, this document will only show each scenario being performed once.

We will be going through two DHCP Consumption scenarios:

Scenario 1: Cisco Catalyst 6509E is acting as the DHCP Server

Scenario 2: Cisco 881 Router is acting as the external DHCP Server

Scenario 1: Cisco Catalyst 6509E as the DHCP Server

The following hardware/software was used for this test:

Victim:

Hardware: Cisco Catalyst 6509E with a Supervisor 720-3B

Software: Cisco IOS Software 12.2(33)SXI1

IP Address: 10.1.0.1/24 (Interface VLAN 7)

MAC Address: 00d0.0139.dc00

Line Card: WS-X6748-GE-TX (10/100/1000 Ethernet)

Attacker:

Hardware: Apple MacBook Pro

Software: Parent OS is OS X 10.5.7. Running Ubuntu 9.04 OS (Virtual Machine) in VMware Fusion

Attack Tool: Yersinia version 0.7.1

IP Address: See *** Note *** below

MAC Address: 0023.6948.b89c

NIC: Linksys USB300M (USB-to-Ethernet 10/100 Network Adapter)

Cisco Catalyst 6509E Port: GE 1/2

Note: For the Attacker machine, the DHCP Consumption attack was run with the following IP addressing:

1. DHCP from Cisco Catalyst 6509E (DHCP Server)

2. 10.1.0.60/24 (Static IP, excluded from DHCP Server Pool of IP Addresses)

The network diagram (Figure 1) below depicts the setup for scenario 1 of our DHCP Consumption attack.

Figure 1. DHCP Consumption Attack—Scenario #1

Steps for the DHCP Consumption Attack:

1. Start VMware Fusion and the Ubuntu 9.04 Virtual Machine

2. IP Addressing on Attacker machine

a. Get an IP address from DHCP Server [Cisco Catalyst 6509E] (1st run of attack)

b. Use static IP address in same subnet as DHCP Server Pool (2nd run of the attack)

3. Verify that you can ping the switch (Interface VLAN 7 = 10.1.0.1)

4. Verify that the DHCP Server is properly configured on the Cisco Catalyst 6509E switch

5. Enable DHCP debugs on the Cisco Catalyst 6509E switch

6. Verify that there are available DHCP addresses in the Pool

7. Open the Yersinia attack tool (GUI) inside the Ubuntu OS Virtual Machine

a. Select “OK” under the warning message

b. Select “Edit Interfaces” and choose the Ethernet interface to use

c. Select the “DHCP” tab

d. Select “Launch attack” to bring up attack choices

e. Select the “DHCP” tab within the “Choose attack” window

f. Select “sending DISCOVER packet” to the left of the “DoS” check mark

g. Select “OK

8. View outgoing DHCP DISCOVER packets being sent by Yersinia

9. View debug output on the Cisco Catalyst 6509E switch

10. Configure mitigation for the DHCP Consumption Attack

11. Perform step 6 again with mitigation in place on the Cisco Catalyst 6509E switch

12. Scenario 1 complete

With VMware Fusion running on the MacBook Pro, the Ubuntu 9.04 Virtual Machine was started.

Figure 2.

Using the Network Tools GUI in Ubuntu 9.04, it was verified that the switch could be pinged successfully (10.1.0.1 = Interface VLAN 7 on the Cisco Catalyst 6509E).

Figure 3.


Here is the section of the Cisco Catalyst 6509E configuration for the DHCP Server.

Figure 4.

Now we will enable the appropriate DHCP debugs on the Cisco Catalyst 6509E switch.

Figure 5.

Looking at the status of our DHCP Server, we can see that there have been no DHCP Requests and no Leases, so our DHCP Pool is currently free and unused (Figures 5, 6, & 7).

Figure 6.

Note that there are no current bindings in the DHCP Server binding tables on the switch (Figures 7 and 8).

Figure 7.

Figure 8.

Once the Cisco Catalyst 6509E switch was setup successfully, the Yersinia attack tool (GUI) was launched running on the Ubuntu 9.04 Virtual Machine (Inside VMware Fusion on a MacBook Pro laptop). Unbuntu is a Linux-based OS, so note that a Terminal window was opened and Yersinia was opened using the “sudo” prefix. When doing this, a prompt to enter the password was required before the application would load and run.

Figure 9.

Once the Yersinia GUI is up and running, the following setup steps are performed:

1. Select “Edit Interfaces” and choose the NIC required. In this case, the Linksys USB300M 10/100 Ethernet adapter was using port eth2 in Ubuntu.

Figure 10.

2. Select the “DHCP” tab

Figure 11.

3. Select “Launch attacks

Figure 12.

4. From the “Choose attack” windows, select “sending DISCOVER packet” as the Denial-of-Service (DoS) attack to run.

Figure 13.

5. Select “OK” to start the attack.

Looking at the “DHCP” tab the DHCP Discovery packets can be seen to be sent to the DHCP Server (Cisco Catalyst 6590E switch).

Figure 14.

From the Cisco Catalyst 6509E perspective, all the IP addresses in the DHCP Pool have been exhausted.

Figure 15.

In a matter of only a few minutes, Yersinia was able to accomplish the task of consuming all of the IP addresses in the DHCP Server IP address pool on the Cisco Catalyst 6509E.

Scenario 2: Cisco 881 Router is acting as the external DHCP Server

In this scenario, a Cisco 881 Router was connected to the Cisco Catalyst 6509E switch, which was functioning as the DHCP Server for the DHCP client machines. Another victim was added in this scenario.

The following hardware/software was used for the purpose of this test:

Victim 1:

Hardware: Cisco 881 IOS Router

Software: Cisco IOS Software 12.4(20)T1

IP Address: 10.1.0.200/24 (Interface VLAN 7)

MAC Address: 0022.5553.3db2

NIC: Integrated 10/100 Ethernet (FE 0) connected to Cisco Catalyst 6509E, port GE1/47

Victim 2:

Hardware: Apple MacBook Pro

Software: Parent OS is OS X 10.5.7. Running Windows XP OS Virtual Machine in VMware Fusion

IP Address: Dynamic DHCP from DHCP Server (Cisco 881 Router)

MAC Address: 0023.6950.4fd2

NIC: Linksys USB300M (USB-to-Ethernet 10/100 Network Adapter)

Attacker:

Hardware: Apple MacBook Pro

Software: Parent OS is OS X 10.5.7. Running Ubuntu 9.04 OS Virtual Machine in VMware Fusion

Attack Tool: Yersinia version 0.7.1

IP Address: See *** Note *** below

MAC Address: 0023.6948.b89c

NIC: Linksys USB300M (USB-to-Ethernet 10/100 Network Adapter)

Cisco Catalyst 6509E Port: GE 1/2

Note: For the Attacker machine, the DHCP Consumption attack was performed with the following IP addressing:

1. DHCP from external Cisco 881 Router (DHCP Server)

2. 10.1.0.60/24 (Static IP, excluded from DHCP Server Pool of IP Addresses)

Below is the network diagram used for scenario 2. The DHCP Consumption attack used a Cisco 881 Router as the external DHCP server. Note that in this scenario, a second victim was added. The victim was a Windows XP Virtual Machine running under VMware Fusion on the MacBook Pro laptop computer. The MacBook Pro had a dual core CPU and 4GB of memory, so it had enough capacity for this test. Both Virtual Machines used a Linksys USB300M (USB-to-Ethernet) 10/100 Network Adapter. This allowed each virtual machine to be independent of the host OS (MacBook Pro OS X). VMware Fusion was setup for no network connection, meaning there was no NAT or Bridging between the Mac's integrated 10/100/1000 NIC and the two Virtual Machines. Each Virtual Machine detected the Linksys USB300M 10/100 Network Adapter and then used it to transmit and receive traffic for that Virtual Machine.

Figure 16.

Steps for the DHCP Consumption Attack (Scenario 2):

1. Start VMware Fusion and the Ubuntu 9.04 Virtual Machine

2. IP Addressing on Attacker machine

a. Get an IP address from the DHCP Server [881 Router] (1st run of the attack)

b. Use static IP address in same subnet as DHCP Server Pool (2nd run of the attack)

3. Verify that you can ping the Cisco 881 Router (Interface VLAN 7 = 10.1.0.200)

4. Verify that the DHCP Server is properly configured on the Cisco 881 Router

5. Verify that there are available DHCP addresses in the DHCP Pool

6. Enable DHCP debugs on the Cisco 881 Router

7. Open the Yersinia attack tool inside Ubuntu OS Virtual Machine

a. Select “OK” under the warning message

b. Select “Edit Interfaces” and choose the Ethernet interface to use

c. Select the “DHCP” tab

d. Select “Launch attack” to bring up attack choices

e. Select the “DHCP” tab within the “Choose attack” window

f. Select “sending DISCOVER packet” to the left of the “DoS” check mark

g. Select “OK

8. View debug output on the Cisco 881 Router and use show commands

9. Obtain an IP address from the DHCP Server on the Windows XP Virtual Machine before and then during the attack.

10. Configure mitigation for the DHCP Consumption Attack on the Cisco Catalyst 6509E switch

11. Perform step 6 again with mitigation in place on the Cisco Catalyst 6509E switch

12. Summary

As performed in Scenario 1, the Ubuntu 9.04 Virtual Machine was started within VMware Fusion on the Mac Book Pro laptop, which ran OS X 10.5.7.

Figure 17.

It was required to verify that IP address 10.1.0.200 could be pinged. This was Interface VLAN 7 on the Cisco 881 Router and was being used as the DHCP Server in this test.

Figure 18.

Here is the relevant information from the Cisco 881 IOS Router that acted as the DHCP Server in this test.

Figure 19.

Note that some addresses were excluded from the DHCP Server's IP Pool “SE_Residency.” This pool was used for interfaces on the router and the Cisco Catalyst 6509E switch. The IP address 10.1.0.60/24 was used as a static IP address on the Ubuntu 9.04 Virtual Machine (eth2).

The Attacker machine was connected to port GE1/2 on the Cisco Catalyst 6509E switch using a Linksys USB300M USB-to-Ethernet 10/100 Network Adapter. This allowed the Ubuntu 9.04 Virtual Machine to have direct access to the network connection without the need of NAT (Network Address Translation) or Bridging through the host (MacBook Pro) machine.

With everything configured on the Cisco 881 Router (DHCP Server), we can take a look at the router's perspective of the DHCP Pool and the range of addresses.

Figure 20.


We will go ahead and turn on some debugs on the Cisco 881 Router in order to see the attack in progress from the router's point of view.

Figure 21.

Figure 22.

The focus now moves back to the Yersinia GUI. Step 6 was followed in order to load and run the DHCP Consumption attack on the Cisco 881 Router (DHCP Server). Once the Yersinia GUI was started, the interface was selected. This was achieved by selecting the “Edit Interface” button. In this case it was Eth2 on the Ubuntu 9.04 Virtual Machine. Remember to select “OK.”

Figure 23.

Select the “DHCP” tab and leave the address in the bottom section of the page default. At this point, the DHCP Consumption attack can be started.

To start the attack, select the “Launch Attack” button. When the “Choose attack” window pops up, make sure the “DHCP” tab is selected. Select the “sending DISCOVER packet” DoS (Denial-of-Service) attack. Be sure to select “OK.”

Figure 24.

Back on the primary display windows in Yersinia, DHCP DISCOVER packets can be seen being sent out of the Ubuntu 9.04 Virtual Machine over the Linksys USB300M 10/100 NIC, through port GE1/2 on the Cisco Catalyst 6509E, and out interface GE1/47 to the Cisco 881 Router (DHCP Server).

Figure 25.

On the Cisco 881 Router (DHCP Server). two debugs were enabled prior to starting the DHCP Consumption attack as shown in the following output.

Figure 26.

On the Cisco 881 Router from the Ubuntu 9.04 attack machine, it can be seen how DHCP Consumption attack affects the DHCP Server (Cisco 881 Router). In Figure 27, the first page of DHCP Bindings is displayed. Note how the Yersinia application creates bogus MAC addresses.

Figure 27.

Below, the captured debugs output is displayed. Note that “logging buffered” was setup on the 881 Router. Only a small portion of the debug is shown.

Figure 28.

When trying to view the status of the DHCP IP Pool “SE_Residency,” the DHCP Server was overwhelmed to the extent that it was unable to display the information until the DHCP Consumption attack was stopped in Yersinia.

Figure 29.

By the time the DHCP Consumption attack was stopped and responses were seen from the Cisco 881 Router, a number of the addresses in the pool had been returned.

Figure 30.

The Windows XP Virtual Machine was also using the Linksys USB300M 10/100 Network Adapter and connected to the same Cisco Catalyst 6509E switch. It was setup to get an IP address from the DHCP Server (881 Router). With a command shell opened on the Windows XP Virtual Machine, the DHCP Consumption attack’s affect on the client could be seen.

Figure 31.

In Figure 31, we see that he Windows XP Virtual Machine could successfully obtain an IP address from the DHCP Server before we started the DHCP Consumption attack.

From the DHCP Server's perspective, we saw the DHCP binding table as displayed in Figure 32.

Figure 32.

Next the IP address that the DHCP Server was given was released, and the DHCP Consumption attack from Yersinia was restarted.

Figure 33.

When to the host tried to renew its IP address, the DHCP Server (Cisco 881 Router) did not respond to the request; rather, the request timed out.

Figure 34.

While the DHCP Consumption attack was running, WireShark (free Network Analyzer) was run on the same device under attack (Ubuntu 9.04 Virtual Machine). In Figure 35 the DHCP DISCOVER packets can be seen being transmitted from Yersinia.

Figure 35.

DHCP Consumption Attack Mitigation

The DHCP Consumption Attack is a very straightforward and easily executed attack that can be initiated from the Yersinia GUI. It was shown above how the DHCP Consumption attack works and how effective it can be on an on-box DHCP Server (as configured on the Cisco Catalyst 6509E switch) as well as on an external DHCP Server (Cisco 881 Router in this case).

Next, some mitigation techniques are investigated to highlight how to stop the DHCP Consumption attack. Note that the mitigation configuration on the Cisco Catalyst 6509E switch remains the same whether the Cisco Catalyst switch is set up as a DHCP Server or whether an external DHCP Server, such as the Cisco 881 Router, is used.

The two mitigation features that are used against a Layer 2 DHCP Consumption attack are DHCP Snooping and Dynamic ARP Inspection (DAI). Note that configuring DHCP Snooping is a prerequisite to being able to configure DAI. Before providing information on how to configure these features, it is important to understand what these features actually do.

DHCP Snooping is a security feature capable of intercepting DHCP messages crossing a switch and blocking bogus DHCP offers. DHCP Snooping uses the concept of trusted and untrusted ports. Typically, trusted ports are used to reach DHCP servers or relay agents, while untrusted ports are used to connect to clients. All DHCP messages are allowed on trusted ports, while only DHCP client messages are accepted on untrusted ports. As neither servers nor relay agents are supposed to connect to untrusted ports, server messages like DHCPOFFER, DHCPACK, and DHCPNAK are dropped on untrusted ports. Additionally, DHCP Snooping builds and maintains a MAC-to-IP binding table that is used to validate DHCP packets received from untrusted ports. The DHCP Snooping binding table contains the MAC address, IP address, lease time in seconds, and VLAN port information for the DHCP clients on the untrusted ports of a switch. The information that is contained in a DHCP-snooping binding table is removed from the binding table when its lease expires or DHCP Snooping is disabled in the VLAN. DHCP Snooping discards all untrusted DHCP packets not consistent with the information in the binding table. For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces.

Dynamic ARP Inspection (DAI) is a security feature that helps prevent ARP poisoning and other ARP-based attacks by intercepting all ARP requests and responses, and by verifying their authenticity before updating the switch's local ARP cache or forwarding the packets to the intended destinations. The DAI verification consists primarily of intercepting each ARP packet and comparing its MAC address and IP address information against the MAC-IP bindings contained in a trusted binding table. DAI discards any ARP packets that are inconsistent with the information contained in the binding table. This trusted binding table is dynamically populated by DHCP snooping when this feature is enabled. In addition, DAI allows the configuration of static ARP ACLs to support systems that use statically configured IP addresses and that do not rely on DHCP. DAI can also be configured to drop ARP packets with invalid IP addresses, such as 0.0.0.0 or 255.255.255.255, and ARP packets containing MAC addresses in their payloads that do not match the addresses specified the Ethernet headers.

Another important feature of DAI is that it implements a configurable rate-limit function that controls the number of incoming ARP packets. This function is particularly important because all validation checks are performed by the CPU, and without a rate-limiter, there could be a DoS condition.

DAI associates a trust state with each interface on the system, similar to DHCP Snooping. Packets arriving on trusted interfaces bypass all DAI validation checks, while those arriving on untrusted interfaces go through the DAI validation process. In a typical network configuration for DAI, all ports connected to host ports are configured as untrusted, while all ports connected to switches are configured as trusted. With this configuration, all ARP packets entering the network from a given switch will have passed the security check. By default, DAI is disabled on all VLANs, and all ports are configured as untrusted.

As previously mentioned, DAI populates its database of valid MAC address to IP address bindings through DHCP snooping. It also validates ARP packets against statically configured ARP ACLs Access Control List). It is important to note that ARP ACLs have precedence over entries in the DHCP snooping database. ARP packets are first compared to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, then the packet will be denied even if a valid binding exists in the database populated by DHCP snooping.

Mitigation is started by configuring DHCP Snooping. Enter enable mode and then configuration mode on the Cisco Catalyst 6509E switch. In the Global Configuration, enter the commands listed in Figure 36. By default, the “ip dhcp snooping information option” is on. Unfortunately, because it is default, it will not show up in the configuration when a “show running” (“wr t” for old school) is invoked. Without being able to see this default command, it makes it rather difficult to know that you need to disable this. The default command will enable the DHCP Option-82 data insertion when the DHCP clients and servers do not reside in the same subnet or network, and when the switch sits between them. Since only one switch is used in this test and all the IP addresses are in the same subnet, this default parameter is required to be disabled.

Figure 36. Configure DHCP Snooping (Global Configuration)

In interface configuration mode, interface GE1/47 is configured as a “Trusted Port.” The external DHCP Server (Cisco 881 Router) is connected to this 10/100/1000 Ethernet port.

Figure 37. Configure DHCP Snooping (Trusted port – Interface Configuration)

Configure DHCP Snooping rate limiting (ARP traffic) on interface GE1/2. The Ubuntu Virtual Machine (Attacker) is connected to this port via a Linksys USB300M 10/100 Network Adapter. This is the key mitigation piece to stop the Attacker. When the Attacker reaches the defined rate limit, the switch will automatically put the Attackers switch port (GE1/2) into an ERRDISABLE (Error Disabled) state.

Figure 38. Configure DHCP Snooping rate-limiting (Interface GE1/2)

Next, configure Error Disabled (ERRDISABLE) detection and causes. Figure 39 displays all the possible parameters for the “errdisable detect cause” command.

Figure 39. Configure ERRDISABLE detect cause (Global Configuration)

Next, configure the Error Disable (ERRDISABLE) recovery options. Note that in Figure 38 DHCP Snooping rate-limiting for ARP traffic was configured on the Attackers switch port (GE1/2). An enable timer for individual or all ERRDISABLE causes can be configured. This will allow the switch to automatically re-enable the users switch port after the enable timer has expired. Note that you might choose not to automatically recover ports from the ERRDISABLE state. This is a choice available for security administrators.

Figure 40. Configure ERRDISABLE recovery for DHCP-Rate-Limit (Global Configuration)

With DHCP Snooping successfully configured on the Cisco Catalyst 6509E switch, the “show” commands to verify the configuration can be used. The “show ip dhcp snooping” commands display details such as on which VLANs DHCP Snooping is enabled, which switch ports are trusted, and which switch ports have rate-limiting enabled.

Figure 41. Show IP DHCP snooping

As mentioned earlier, in order to enable Dynamic ARP Inspection (DAI) DHCP Snooping must be enabled. DAI is not required in order to stop the DHCP Consumption attack, but it is required to stop other Layer 2 attacks such as the ARP Poisoning (Man-In-The-Middle) [MITM] Attack and the MAC Address Overflow Attack. Figure 42 depicts the Global Configuration commands needed to configure DAI on our Cisco Catalyst 6509E switch.

Figure 42. Configure ARP Inspection (Global Configuration)

Similar to the DHCP Snooping configuration, a “Trusted Port” was configured on interface GE1/47, which connects to the external DHCP Server (Cisco 881 Router).

Figure 43. Configure ARP Inspection (Trusted Port – Interface Configuration)

With DHCP Snooping and Dynamic ARP Inspection (DAI) enabled, some debugs are turned on. DHCP Snooping events with the “debug ip dhcp snooping events” command were enabled first. If no debugs are seen during the attack, logging debugs to the console or logging buffered should be enabled. Also make sure the “terminal monitor” command is entered.

Figure 44. Enable DHCP Snooping Debug


Figure 45 shows the switch detecting that the DHCP Snooping rate-limit has been exceeded on the Attacker's switch port GE1/2.

Figure 45.

Once the attacker Virtual Machine running Yersinia started the attack and exceeded the DHCP Snooping rate-limit, the switch detected this and immediately put the switch port into and ERRDISABLE (Error Disabled) state.

The output in Figure 46 shows the switch putting the Attacker's switch port (GE1/2) into an ERRDISABLE (Error Disabled) state

Figure 46.

Earlier the “errdisable recovery cause” was configured (refer to Figure 40). In the last portion of Figure 47, the switch can be seen attempting to recover from the ERRDISABLE state.

Figure 47. Recovery from an ERR-DISABLE state


Summary

The DHCP Consumption is an effective attack if the proper mitigation techniques are not in place on the Cisco Catalyst switch. When properly configured, the DHCP Snooping feature on the Cisco Catalyst 6509E switch is a very good tool to stop DHCP Consumption (DoS) attacks. When used in conjunction with the Dynamic ARP Inspection (DAI) feature, ARP Poisoning (Man-In-The-Middle [MITM]) and the MAC Address Overflow attacks can also be stopped.

DHCP Snooping is a security feature capable of intercepting DHCP messages crossing a switch and blocking bogus DHCP offers. DHCP Snooping uses the concept of trusted and untrusted ports. Typically, the trusted ports are used to reach DHCP servers or relay agents, while untrusted ports are used to connect to clients. All DHCP messages are allowed on trusted ports, while only DHCP client messages are accepted on untrusted ports. As neither servers nor relay agents are connected to untrusted ports, server messages like DHCPOFFER, DHCPACK, and DHCPNAK are dropped on untrusted ports. In addition, DHCP Snooping builds and maintains a MAC-to-IP binding table that is used to validate DHCP packets received from untrusted ports. DHCP Snooping discards all untrusted DHCP packets not consistent with the information in the binding table. For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces. The DHCP Snooping binding table contains the MAC address, IP address, lease time in seconds, and VLAN port information for the DHCP clients on the untrusted ports of a switch. The information that is contained in a DHCP-snooping binding table is removed from the binding table when its lease expires or DHCP Snooping is disabled in the VLAN.

Dynamic ARP Inspection (DAI) is a security feature that helps prevent ARP poisoning and other ARP-based attacks by intercepting all ARP requests and responses, and by verifying their authenticity before updating the switch's local ARP cache or forwarding the packets to the intended destinations. The DAI verification consists primarily of intercepting each ARP packet and comparing its MAC address and IP address information against the MAC-IP bindings contained in a trusted binding table. DAI discards any ARP packets that are inconsistent with the information contained in the binding table. The trusted binding table is dynamically populated by DHCP snooping when this feature is enabled. In addition, DAI allows the configuration of static ARP ACLs to support systems that use statically configured IP addresses and that do not rely on DHCP. DAI can also be configured to drop ARP packets with invalid IP addresses, such as 0.0.0.0 or 255.255.255.255, and ARP packets containing MAC addresses in their payloads that do not match the addresses specified the Ethernet headers.

Another important feature of DAI is that it implements a configurable rate-limit function that controls the number of incoming ARP packets. This function is particularly important because all validation checks are performed by the CPU, and without a rate-limiter, there could be a DoS condition.

DAI associates a trust state with each interface on the system, similar to DHCP Snooping. Packets arriving on trusted interfaces bypass all DAI validation checks, while those arriving on untrusted interfaces go through the DAI validation process. In a typical network configuration for DAI, all ports connected to host ports are configured as untrusted, while all ports connected to switches are configured as trusted. With this configuration, all ARP packets entering the network from a given switch will have passed the security check. By default, DAI is disabled on all VLANs, and all ports are configured as untrusted.

As discussed earlier, DAI populates its database of valid MAC address to IP address bindings through DHCP snooping. It also validates ARP packets against statically configured ARP ACLs. It is important to note that ARP ACLs have precedence over entries in the DHCP snooping database. ARP packets are first compared to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, then the packet will be denied even if a valid binding exists in the database populated by DHCP snooping.


Note that configuring DHCP Snooping is a prerequisite to configure Dynamic ARP Inspection (DAI). It is also worth noting that if any static IP addresses on your switch are planned to be used when configuring DHCP Snooping and DAI, a static IP-to-MAC address mapping must also be configured in the Cisco Catalyst 6500 switches configuration. For instance, lets say that a static IP-to-MAC mapping for the IP address 10.1.0.60 with the MAC address of 0023.6948.B89C for interface GE1/2 on VLAN 7 is required. The global configuration command on switch would be:

ip source binding 0023.6948.B89C vlan 7 10.1.0.60 interface Gi1/2

By using the mitigation techniques covered in this white paper, the DHCP Consumption (DoS) attack can be stopped from bringing down a DHCP Server; whether the DHCP Server is configured on the Cisco Catalyst switch or an external DHCP Server.

References

Solder, Carl (2006). “Cisco Networkers”

Cisco Systems, Inc. (2007). “Infrastructure Protection on Cisco Catalyst 6500 and 4500 Series Switches.”

Cisco Systems, Inc. (2008). “Protecting the Cisco Catalyst 6500 Series Switches Against Denial-Of-Service Attacks”

Cisco Systems, Inc. (2009). “Cisco Catalyst 6500 Architecture White Paper.”

Cisco Systems, Inc. (2009). “Configuring DHCP Snooping”

Cisco Systems, Inc. (2009). “Configuring Dynamic ARP Inspection.”

Cisco Systems, Inc. (2009). “Design Zone for Security.”

Hodgdon, Scott (2009). “CSSTG SE Residency Project Plan.”

Configurations Used in Lab

Cisco Catalyst 6509E Configuration for Scenario 1

(Cisco Catalyst 6509E switch acting as the internal DHCP Server)
(Mitigation configured)

DHCP Consumption Attack—Scenario #1


6509E# wr t
Building configuration...
Current configuration: 7513 bytes
!
upgrade fpd auto
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service counters max age 5
!
hostname 6509E
!
boot-start-marker
boot system flash disk0:
boot system disk0:s72033-adventerprisek9-mz.122-33.SXI1
boot-end-marker
!
security passwords min-length 1
logging buffered 4096 debugging
enable password 12345
!
no aaa new-model
ip subnet-zero!
!***********************************************************
! Configuration for enabling DHCP Snooping
!***********************************************************
ip dhcp snooping vlan 7
no ip dhcp snooping information option
ip dhcp snooping
no ip domain-lookup
!
!*************************************************************************
! Configuration for enabling Dynamic ARP Inspection (DAI)
!*************************************************************************
ip arp inspection vlan 7
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 1024 interval 10
vtp domain CISCO
vtp mode transparent
mls netflow interface
no mls flow ip
mls cef error action reset
!
redundancy
keepalive-enable
mode sso
main-cpu
auto-sync running-config
spanning-tree mode pvst
!
!*************************************************************************************
! The “ errdisable recovery cause all” command will automatically add the following configuration
! commands to the switch
!*************************************************************************************
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause security-violation
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause gbic-invalid
errdisable recovery cause l2ptguard
errdisable recovery cause psecure-violation
errdisable recovery cause dhcp-rate-limit
errdisable recovery cause mac-limit
errdisable recovery cause unicast-flood
errdisable recovery cause vmps
errdisable recovery cause storm-control
errdisable recovery cause arp-inspection
errdisable recovery cause link-monitor-failure
errdisable recovery cause oam-remote-failure
errdisable recovery cause loopback
errdisable recovery interval 30
fabric timer 15
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
!
vlan 7,10,20
!
vlan 50
remote-span
!
vlan 255
!
interface GigabitEthernet1/1
switchport
switchport access vlan 7
switchport mode access
shutdown
!
!************************************************************************************
! Attacker Machine (Ubuntu 9.04 Virtual Machine) connected to GE1/2
!************************************************************************************
interface GigabitEthernet1/2
switchport
switchport access vlan 7
switchport mode access
! **************************************************************************************************
! Configure DHCP Snooping ARP Rate Limiting on Attacker's switch port (GE1/2)
!***************************************************************************************************
ip dhcp snooping limit rate 10
!
!
!
!
!
interface GigabitEthernet1/3
switchport
switchport access vlan 7
switchport mode access
shutdown
!
interface GigabitEthernet1/4
no ip address
shutdown
!
interface GigabitEthernet1/5
no ip address
shutdown
!
interface GigabitEthernet1/6
no ip address
shutdown
!
interface GigabitEthernet1/7
no ip address
shutdown
!
interface GigabitEthernet1/8
no ip address
shutdown
!
interface GigabitEthernet1/9
no ip address
shutdown
!
interface GigabitEthernet1/10
no ip address
shutdown
!
interface GigabitEthernet1/11
no ip address
shutdown
!
interface GigabitEthernet1/12
no ip address
shutdown
!
interface GigabitEthernet1/13
switchport
switchport access vlan 7
switchport mode access
shutdown
!
interface GigabitEthernet1/14
switchport
switchport access vlan 7
switchport mode access
shutdown
!
interface GigabitEthernet1/15
switchport
shutdown
!
interface GigabitEthernet1/16
no ip address
shutdown
!
interface GigabitEthernet1/17
no ip address
shutdown
!
!
interface GigabitEthernet1/18
no ip address
shutdown
!
interface GigabitEthernet1/19
no ip address
shutdown
!
interface GigabitEthernet1/20
no ip address
shutdown
!
interface GigabitEthernet1/21
no ip address
shutdown
!
interface GigabitEthernet1/22
no ip address
shutdown
!
interface GigabitEthernet1/23
no ip address
shutdown
!
interface GigabitEthernet1/24
no ip address
shutdown
!
interface GigabitEthernet1/25
no ip address
shutdown
!
!
!
interface GigabitEthernet1/26
no ip address
shutdown
!
interface GigabitEthernet1/27
no ip address
shutdown
!
interface GigabitEthernet1/28
no ip address
shutdown
!
interface GigabitEthernet1/29
no ip address
shutdown
!
interface GigabitEthernet1/30
no ip address
shutdown
!
interface GigabitEthernet1/31
no ip address
shutdown
!
interface GigabitEthernet1/32
no ip address
shutdown
!
interface GigabitEthernet1/33
no ip address
shutdown
!
!
!
interface GigabitEthernet1/34
no ip address
shutdown
!
interface GigabitEthernet1/35
no ip address
shutdown
!
interface GigabitEthernet1/36
no ip address
shutdown
!
interface GigabitEthernet1/37
no ip address
shutdown
!
interface GigabitEthernet1/38
no ip address
shutdown
!
interface GigabitEthernet1/39
no ip address
shutdown
!
interface GigabitEthernet1/40
no ip address
shutdown
!
interface GigabitEthernet1/41
no ip address
shutdown
!
!
!
interface GigabitEthernet1/42
no ip address
shutdown
!
interface GigabitEthernet1/43
no ip address
shutdown
!
interface GigabitEthernet1/44
no ip address
shutdown
!
interface GigabitEthernet1/45
no ip address
shutdown
!
interface GigabitEthernet1/46
switchport
switchport access vlan 7
switchport mode access
!
interface GigabitEthernet1/47
description *** Connects to 881 Router Acting as DHCP Server [10.1.0.200] port 0/5, used in scenario 2 ***
switchport
switchport access vlan 7
switchport mode access
ip arp inspection trust
ip dhcp snooping trust
shutdown
!
interface GigabitEthernet1/48
switchport
switchport mode dynamic auto
!
interface GigabitEthernet5/1
no ip address
shutdown
!
interface GigabitEthernet5/2
switchport
switchport access vlan 255
switchport mode access
media-type rj45
!
interface Vlan1
no ip address
shutdown
!
interface Vlan7
ip address 10.1.0.1 255.255.255.0
!
interface Vlan255
description *** Not used in this test ***
ip address 172.18.176.198 255.255.255.0
!
router eigrp 100
network 10.1.0.0 0.0.0.255
network 172.18.176.0 0.0.0.255
no auto-summary
!
ip classless
!
no ip http server
no ip http secure-server
!
control-plane
!
dial-peer cor custom
!
alias exec sdsb show ip dhcp snooping binding
!
line con 0
exec-timeout 0 0
line vty 0 4
session-timeout 800
password 12345
login
length 0
transport preferred none
transport input all
transport output none
line vty 5 15
login
transport input lat pad udptn telnet rlogin ssh
!
scheduler process-watchdog terminate
scheduler switch allocate 1000 1000
scheduler allocate 400 100
mac-address-table aging-time 480
!
end

Cisco Catalyst 6509E Configuration for Scenario 2

(Cisco 881 Router acting as external DHCP Server)
(Mitigation configured)

DHCP Consumption Attack—Scenario #2

6509E#wr t
Building configuration...
Current configuration : 7513 bytes
!
upgrade fpd auto
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service counters max age 5
!
hostname 6509E
!
boot-start-marker
boot system flash disk0:
boot system disk0:s72033-adventerprisek9-mz.122-33.SXI1
boot-end-marker
!
security passwords min-length 1
logging buffered 4096 debugging
enable password 12345
!
no aaa new-model
ip subnet-zero
!
!***********************************************************
! Configuration for enabling DHCP Snooping
!***********************************************************
ip dhcp snooping vlan 7
no ip dhcp snooping information option
ip dhcp snooping
no ip domain-lookup
!
!*************************************************************************
! Configuration for enabling Dynamic ARP Inspection (DAI)
!*************************************************************************
ip arp inspection vlan 7
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 1024 interval 10
vtp domain CISCO
vtp mode transparent
mls netflow interface
no mls flow ip
mls cef error action reset
!
redundancy
keepalive-enable
mode sso
main-cpu
auto-sync running-config
spanning-tree mode pvst
!
!*************************************************************************************
! The “ errdisable recovery cause all” command will automatically add the following configuration
! commands to the switch
!*************************************************************************************
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause security-violation
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause gbic-invalid
errdisable recovery cause l2ptguard
errdisable recovery cause psecure-violation
errdisable recovery cause dhcp-rate-limit
errdisable recovery cause mac-limit
errdisable recovery cause unicast-flood
errdisable recovery cause vmps
errdisable recovery cause storm-control
errdisable recovery cause arp-inspection
errdisable recovery cause link-monitor-failure
errdisable recovery cause oam-remote-failure
errdisable recovery cause loopback
errdisable recovery interval 30
fabric timer 15
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
!
vlan 7,10,20
!
vlan 50
remote-span
!
vlan 255
!
interface GigabitEthernet1/1
switchport
switchport access vlan 7
switchport mode access
shutdown
!
!*************************************************************************************
! Attacker Machine (Ubuntu 9.04 Virtual Machine) connected to GE1/2
!*************************************************************************************
interface GigabitEthernet1/2
switchport
switchport access vlan 7
switchport mode access
! **************************************************************************************
! Configure DHCP Snooping ARP Rate Limiting on Attacker's switch port (GE1/2)
!*************************************************************************************
ip dhcp snooping limit rate 10
!
!
!
!
!
!***********************************************************************************
! Victim Machine (Windows XP Virtual Machine) connected to GE1/3
!***********************************************************************************
interface GigabitEthernet1/3
description *** Victim / Windows XP Virtual Machine/ 2nd Linksys USB300M NIC, DHCP from 881 Router ***
switchport
switchport access vlan 7
switchport mode access
!
interface GigabitEthernet1/4
no ip address
shutdown
!
interface GigabitEthernet1/5
no ip address
shutdown
!
interface GigabitEthernet1/6
no ip address
shutdown
!
interface GigabitEthernet1/7
no ip address
shutdown
!
interface GigabitEthernet1/8
no ip address
shutdown
!
interface GigabitEthernet1/9
no ip address
shutdown
!
!
interface GigabitEthernet1/10
no ip address
shutdown
!
interface GigabitEthernet1/11
no ip address
shutdown
!
interface GigabitEthernet1/12
no ip address
shutdown
!
interface GigabitEthernet1/13
switchport
switchport access vlan 7
switchport mode access
shutdown
!
interface GigabitEthernet1/14
switchport
switchport access vlan 7
switchport mode access
shutdown
!
interface GigabitEthernet1/15
switchport
shutdown
!
interface GigabitEthernet1/16
no ip address
shutdown
!
!
!
interface GigabitEthernet1/17
no ip address
shutdown
!
interface GigabitEthernet1/18
no ip address
shutdown
!
interface GigabitEthernet1/19
no ip address
shutdown
!
interface GigabitEthernet1/20
no ip address
shutdown
!
interface GigabitEthernet1/21
no ip address
shutdown
!
interface GigabitEthernet1/22
no ip address
shutdown
!
interface GigabitEthernet1/23
no ip address
shutdown
!
interface GigabitEthernet1/24
no ip address
shutdown
!
!
!
interface GigabitEthernet1/25
no ip address
shutdown
!
interface GigabitEthernet1/26
no ip address
shutdown
!
interface GigabitEthernet1/27
no ip address
shutdown
!
interface GigabitEthernet1/28
no ip address
shutdown
!
interface GigabitEthernet1/29
no ip address
shutdown
!
interface GigabitEthernet1/30
no ip address
shutdown
!
interface GigabitEthernet1/31
no ip address
shutdown
!
interface GigabitEthernet1/32
no ip address
shutdown
!
!
!
interface GigabitEthernet1/33
no ip address
shutdown
!
interface GigabitEthernet1/34
no ip address
shutdown
!
interface GigabitEthernet1/35
no ip address
shutdown
!
interface GigabitEthernet1/36
no ip address
shutdown
!
interface GigabitEthernet1/37
no ip address
shutdown
!
interface GigabitEthernet1/38
no ip address
shutdown
!
interface GigabitEthernet1/39
no ip address
shutdown
!
interface GigabitEthernet1/40
no ip address
shutdown
!
!
!
interface GigabitEthernet1/41
no ip address
shutdown
!
interface GigabitEthernet1/42
no ip address
shutdown
!
interface GigabitEthernet1/43
no ip address
shutdown
!
interface GigabitEthernet1/44
no ip address
shutdown
!
interface GigabitEthernet1/45
no ip address
shutdown
!
interface GigabitEthernet1/46
switchport
switchport access vlan 7
switchport mode access
!
!
!
!
!
!
!
!
!
!
!*************************************************************************************
! Connects to 881 Router Acting as DHCP Server [10.1.0.200] port 0/5
!*************************************************************************************
interface GigabitEthernet1/47
switchport
switchport access vlan 7
switchport mode access
!*************************************************************************************
! Configuring GE1/47 as a trusted port for both DHCP Snooping and Dynamic ARP Inspection (DAI)
!*************************************************************************************
ip arp inspection trust
ip dhcp snooping trust
!
interface GigabitEthernet1/48
switchport
switchport mode dynamic auto
!
interface GigabitEthernet5/1
no ip address
shutdown
!
interface GigabitEthernet5/2
switchport
switchport access vlan 255
switchport mode access
media-type rj45
!
interface Vlan1
no ip address
shutdown
!
!
!
!
interface Vlan7
ip address 10.1.0.1 255.255.255.0
!
interface Vlan255
description *** Not used in this test ***
ip address 172.18.176.198 255.255.255.0
!
router eigrp 100
network 10.1.0.0 0.0.0.255
network 172.18.176.0 0.0.0.255
no auto-summary
!
ip classless
!
no ip http server
no ip http secure-server
!
control-plane
!
dial-peer cor custom
!
alias exec sdsb show ip dhcp snooping binding
!
line con 0
exec-timeout 0 0
line vty 0 4
session-timeout 800
password 12345
login
length 0
transport preferred none
transport input all
transport output none
line vty 5 15
login
transport input lat pad udptn telnet rlogin ssh
!
scheduler process-watchdog terminate
scheduler switch allocate 1000 1000
scheduler allocate 400 100
mac-address-table aging-time 480
!
end

Setting Up Ubuntu OS

Configuration for obtaining an IP address from the DHCP:

In order for the Unbuntu 9.04 Virtual Machine to get a dynamic IP address from the external DHCP Server (Cisco 881 Router), we made the following configuration changes:

1. In the upper right corner of the Ubuntu Desktop, right click on the networking icon and select “Edit Connections.”

Figure 48.

2. Now select “Add.” Our Linksys USB300M 10/100 USB-to-Ethernet Network Adapter has a MAC address of 00:23:69:48:b8:9c. This is entered under the “Wired” tab.

Figure 49.

3. Under the “IPV4 Settings” tab, the method should be “Automatic (DHCP).”

Figure 50.

4. Be sure to select “Apply” for the setting to take.

Configuration for a Static IP Address (Ubuntu Virtual Machine):

There is a little more involved in setting up the Ubuntu 9.04 Virtual Machine with a static IP address. Below are the steps you need to follow.

1. From a Terminal windows in Ubuntu, open up the /etc/network/interfaces file. Note that you need SUDO access in order to edit and save this file.

Figure 51.

2. Once you have the “interfaces” file open, you need to add an eth2 interface, give it an IP address, Netmask, and Default Gateway.

Figure 52.

3. Now “save” and close “close” the “interfaces” file. Quit out of the gedit editor application.

Special Note

Whether using a DHCP address or static IP address, be sure not to plug your Linksys USB300M 10/100 Network Adapter into your MacBook Pro until you have opened up your Ubuntu Virtual Machine in VMware Fusion. Once the Ubuntu Virtual Machine has fully loaded, then plug in the Network Adapter into an available USB interface on your MacBook Pro.

Appendix

Introduction to Ubuntu Install Guide for L2 Attack Tools

This appendix is intended for those users that are not familiar with the Ubuntu Linux OS and want to be able to quickly download and use the Layer 2 attack and monitoring tools (Ettercap, Yersinia, packETH and Wireshark) that are utilized throughout these series of Layer 2 attack whitepapers. The Synaptic Package Manager in Ubuntu is the GUI application for installing software packages in the dpkg format with the file extensions of “.deb.” This dpkg format was the first Linux packaging to integrate dependency information. The Debian Package Mgmt. system database tracks which software packages are installed, which version is installed, and other packages that it is dependent on. This allows you to automatically identify, download, and install all dependent applications that are part of your original application installation selection. The Synaptic Package Manager by default will only point to those dpkg repositories that are supported by Ubuntu Linux. If you want the Synaptic Package Manager to point to repositories that are not supported by Ubuntu, you must add those repositories to /etc/apt/sources.list.

This appendix covers the complete installation of the Ettercap application, modification of its initial configuration file (parameter values that provide privilege level, rerouting capabilities, remote browser capabilities, etc to ettercap) and where and how to launch the application. The other L2 attack and monitoring tool installations (Yersinia, packETH and Wireshark) are not covered in their entirety as the process is similar. These applications do differ in where and how they are launched and the appendix will cover these unique differences in detail.

Listed below is a summary of the different attack scenario’s and which L2 attack tools were used:

STP MiTM (Vlan) Attack: Yersinia, Ettercap, Wireshark

STP MiTM (ISL) Attack: Yersinia, Ettercap, packETH, Wireshark

ARP MiTM Attack: Ettercap, Wireshark

MAC Overflow Attack: Ettercap, Wireshark

DHCP Consumption Atack: Yersinia, Wireshark

Ettercap

Ettercap Installation via Synaptic Package Manager

Select “System>Administration>Synaptic Package Manager” to load Synaptic; the GUI application to download, install and remove applications on Ubuntu Linux.

Figure 53.

You will be required to enter your password to perform Administrative Tasks such as installing software.

Figure 54.

Type “ettercap” in the Quick Search Field and the Synaptic Package Manager will locate the application for installation.

Figure 55.

Select the “ettercap-gtk” application for the GUI version of Ettercap by left clicking your mouse on the application.

Figure 56.

Left click on “Mark for Installation.”

Figure 57.

Additional application dependencies have been identified. Mark this additional application for installation.

Figure 58.

Ettercap has been marked along with its application dependency on “ettercap-common.” Go ahead and hit “Apply” to install both applications.

Figure 59.

Hit “Apply” in the summary screen to confirm your installation selections.

Figure 60.

When your installation is complete, the “Changes applied” window will pop up. Close this window to proceed.

Figure 61.

Synaptic will indicate that the applications have been successfully installed by the filled green boxes next to the application.

Figure 62.

Modification of Ettercap initialization file “/etc/etter.conf”

We are going to use the terminal shell to modify the “/etc/etter.conf” file. Select “Applications>Accessories>Terminal“ to open a terminal window.

Figure 63.

When the terminal window opens, type “sudo gedit /etc/etter.conf” to open the file with the appropriate privileges to modify the file. You will be prompted for the root password to continue.

Figure 64.

The “ec_uid” and “ec_gid” values both need to be changed to “0” to provide the appropriate privilege level to Ettercap upon execution. The default values are “65534.” Change these to “0” as depicted below.

Figure 65.

The “port_steal_send_delay” value needs to be changed to “1” microseconds. The default value is “2000” microseconds for the port steal send delay. We need to populate arp tables faster than Cisco’s default ARP table timeout values can clear them.

Figure 66.

Comment out “#” the original remote browser command line and add the remote_browser command line as entered below—mozilla is replaced with firefox. This fixes the MiTM remote browsing plugin within ettercap. This enables us to view the same web pages as a victim in real time.

Figure 67.

Uncomment the iptables commands by removing the “#” symbol. This will allow you to reroute traffic when performing a MiTM attack on behalf of the gateway and the victim.

Figure 68.

When you have completed these modifications, hit the “save” tab at the top of the editor.

Figure 69.

Launching Ettercap

Ettercap can be launched from “Applications>System Tools” or you can right click on “ettercap” from “System Tools” and install a launcher to the desktop.

Figure 70.

Ettercap can now be launched from the Ubuntu Desktop.

Figure 71.

Double clicking on the Ettercap icon launches the following Ettercap application.

Figure 72.

Yersinia

Yersinia Installation via Synaptic Package Manager

Follow the same process as outlined in Figures 53 to 62 to install the Yersinia (Figure 73) application. The below figure depicts the currently installed application—as denoted by the green box next to the application.

Figure 73.

Launching Yersinia’s Graphical Interface

Yersinia must be launched from a terminal window. Click on “Applications>Accessories>Terminal” to open a terminal window.

Figure 74.

Give the terminal window root privilege by typing the command “sudo su” at the command prompt. You will be required to provide a root password. There are several different options to launch yersinia from the CLI—“-G “ for Graphical or “-I” for interactive. The “yersinia –G” option loads the Graphical version of Yersinia depicted in Figure75.

Figure 75.

The default Yersinia screen when using the Graphical option for launching the application.

Figure 76.

Launching Yersinia’s Interactive Interface

To launch the Interactive interface of Yersinia, you must be using a full size terminal window. Make sure you maximize your terminal session before launching the application with the “-I” option.

Figure 77.

Once the window is maximized launch Yersinia with the “-I” option from the CLI.

Figure 78.

If your window was not maximized, you will receive the error message depicted below.

Figure 79.

The initial dialog screen informs you that eth0 has been selected as the default interface. You have an option to load an additional Ethernet interface if desired or to change the default interface. Hit any key to proceed.

Figure 80.

Type a lower case “h” to pull up the help screen of available commands. This is just another interface for using Yersinia. Our examples of L2 attacks all use the Graphical version of Yersinia. This should be enough to get you going if you choose to use the Interactive interface to Yersinia.

Figure 81.

packETH

packETH Installation via Synaptic Package Manager

Follow the same process as outlined in Figures 53 to 62 to install the packETH (Figure 82) application. The below figure depicts the currently installed application—as denoted by the green box next to the application.

Figure 82.

Launching packETH

packETH must be launched from a terminal window. Click on “Applications>Accessories>Terminal “ to open a terminal window.

Figure 83.

Give the terminal window root privilege by typing the command “sudo su” at the command prompt. You will be required to provide a root password. Once you have root privilege, type “packeth” at the command prompt and hit enter.

Figure 84.

This is a partial view of the default window that appears for packETH upon launching. You will notice that this packet generator supports ver II, 802.3 and 802.1q frames.

Figure 85.

Wireshark

Wireshark Installation via Synaptic Package Manager

Follow the same process as outlined in Figures 53 to 62 to install the Wireshark (Figure 86) application. The below figure depicts the currently installed application—as denoted by the green box next to the application. You will note that the Wireshark application is dependent on “wireshark-common.” The Synaptic Package Manager will identify the dependency and prompt you to also install “wireshark-common.”

Figure 86.

Launching Wireshark

Wireshark can be launched from “Applications>Internet>Wireshark (as root)” by a single click or you can add the launcher to the desktop by right clicking on wireshark and then select “Add this launcher to desktop.” The Wireshark icon can be double clicked from the Desktop to launch the application. Launched application is depicted in Figure88.

Figure 87.

Figure 88.