Detecting ARP Spoofing Attacks

Objective

Threat Defender can be set up to detect ARP spoofing inside the network and block the ARP spoofing device.

Attackers may use manipulated address resolution protocol (ARP) messages to redirect traffic to another device, e.g. the attackers’ computer. The attacker’s MAC address is linked to the IP addresses of legitimate devices in the network. Attackers can then log or manipulate the redirected data. For example, they can see what domains the victim requests or replace a download file with a Trojan.

ARP spoofing attacks can be detected by monitoring the relations between IP and MAC addresses. An IP address can only be related to one MAC address at a time. If an IP address frequently changes its MAC address relation in a short time, an ARP spoofing attack may be underway. If multiple IP addresses change their MAC address relations to the same MAC address, an ARP spoofing attack is very likely.

Threat Defender can detect this behavior and interrupt the ARP spoofing attack using two event tracking tables and a dynamic network object.

Creating a Correlation Scenario

First, navigate to Policy > Advanced Correlation. Create a correlation scenario that provides the framework for the required event tracking tables, dynamic network object and rule set.

Creating the Event Tracking Tables

In the correlation scenario, open the Event Tracking Tables tab. Create two event tracking tables. One table stores MAC addresses per IP address, the other table stores IP addresses per MAC address.

The following table shows the required settings of the event tracking tables:

Name	Retention Time	Primary Attribute Type	Max. No. Primary	Secondary Attribute Type	Max. No. Secondary per Primary
`ETT 1` `- MACs per IP`	`3600`	`IP Address`	`5000`	`MAC Address`	`500`
`ETT 2` `- IPs per MAC`	`3600`	`MAC Address`	`5000`	`IP Address`	`500`

Note

Under Maximum Number of Primary Attributes, make sure that both tables are large enough to fit your network.

For detailed instructions on how to create an event tracking table, refer to Creating an Event Tracking Table.

Creating a Dynamic Network Object

Create a dynamic network object in the correlation scenario. It stores the MAC addresses of the suspected ARP spoofing devices.

The following table shows the required settings of the dynamic network object:

Name	Network	Size	Timeout
`ARP spoofing devices`	`External`	`100`	`0`

For detailed instructions on how to create a dynamic network object in a correlation scenario, refer to Creating a Dynamic Network Object.

Tip

A timeout of 0 means that the entries are not removed automatically.

Note

If your network contains special configurations, such as a computer with two network cards in the same subnet, define exceptions for these devices by excluding their MAC addresses in the dynamic network object.

Creating the Rule Set

To monitor IP/MAC address relations and drop traffic from possible attackers, the following four rules are needed in the correlation scenario:

Rule 1 silently drops all traffic from devices stored in the ARP spoofing devices network object. This way, identified ARP spoofing devices are blocked.

Rule 2 enters all client IP and MAC addresses into the ETT 1 - MACs per IP event tracking table.

Rule 3 counts the entries in the ETT 1 - MACs per IP event tracking table. If a client IP has more than two MAC addresses, this indicates that an ARP spoofing attack may be underway. All clients with more than one entry are then added to the ETT 2 - IPs per MAC event tracking table.

Rule 4 counts the entries in the ETT 2 - IPs per MAC event tracking table to identify which device is the originator of the ARP spoofing attack. If a MAC address has more than two IP addresses, it is added to the ARP spoofing devices dynamic network object. This way, the source of the ARP spoofing attack is identified and isolated.

The following table shows the required rule settings:

Source	Destination	Condition	Actions
`ARP spoofing` `devices`	`Any`		Final Action: Drop Traffic and Stop Processing
`Any`	`Any`		Add to Event Tracking Table Event Tracking Table: `ETT 1 - MACs per IP` Primary Attribute: `Client Address` Secondary Attribute: `Client MAC Address`
`Any`	`Any`	Advanced Correlation Condition: Number of Similar Events in Event Tracking Table Event Tracking Table: `ETT 1 - MACs per IP` Count entries equal to: `Client Address` Minimum number of entries: `2`	Add to Event Tracking Table Event Tracking Table: `ETT 2 - IPs per MAC` Primary Attribute: `Client MAC Address` Secondary Attribute: `Client Address`
`Any`	`Any`	Advanced Correlation Condition: Number of Similar Events in Event Tracking Table Event Tracking Table: `ETT - IPs per MAC` Count entries equal to: `Client MAC Address` Minimum number of entries: `3`	Dynamic Network Object Operation: `Add` Host Identifier: `MAC Address` Who: `Client` Target Dynamic Network Object: `ARP spoofing devices`

For detailed instructions on how to create a rule in a correlation scenario, refer to Creating Rules in a Correlation Scenario.

Click the APPLY CHANGES button at the top of the menu bar to activate your configuration changes.

Result

Threat Defender monitors the IP/MAC address relations of all devices in the network. If it detects client IP addresses that are assigned more than two MAC addresses, this indicates that an ARP spoofing attack may be underway. There may be other reasons for this behavior, however.

Content of ETT 1, indicating that an ARP spoofing attack is underway.

To confirm if an ARP spoofing attack is being carried out, Threat Defender cross-checks the MAC/IP address relations. If multiple IP addresses are related to the same MAC address, this confirms that an ARP spoofing attack is indeed underway.

Content ETT 2 — Content of ETT 2, identifying the source of the ARP spoofing attack.

The originator of the ARP spoofing attack is identified. Threat Defender adds it to the dynamic network object to isolate it. Traffic from hosts in this network object is blocked. ARP spoofing attacks run by these hosts are stopped.

Note

Once the suspected ARP spoofing situation is remedied, you need to flush the content of the dynamic network object. To do so, click the RESET STATE button in the correlation scenario.