I recently had excessive Land Attack errors in the logs of an ASA. The land attack was from the public (PAT) IP address of the ASA back to itself.

%PIX|ASA-2-106017: Deny IP due to Land Attack from IP_address to IP_address

After a bit of troubleshooting using Splunk I found UDP deny errors between two hosts at the exact same second(s) when the Land Attack errors appeared. The UDP session in question was from an internal guest WiFi IP to an Apple server. It appears that this issue is quite common and talked about much online which lead me to this article regarding AppleTalk, i Messaging etc..

https://discussions.apple.com/thread/3995672

After reading the article, the solution to stop these errors was to add an access list to stop UDP traffic from the private guest IP range to the PAT public IP of the ASA.

access-list guest_out line 1 deny “guestnetwork and subnet” hosts “PAT public IP”.

A check of the logs shows no more land errors since the access list was applied – problem solved!

What is Land attack?

A land attack is a remote denial-of-service (DOS) attack caused by sending a packet to a machine with the source host/port the same as the destination host/port.

How do you troubleshoot?

Error Message    %PIX|ASA-2-106017: Deny IP due to Land Attack from IP_address to IP_address

Explanation:   

The security appliance received a packet with the IP source address equal to the IP destination, and the destination port equal to the source port. This message indicates a spoofed packet that is designed to attack systems. This attack is referred to
as a Land Attack.

What this message practically means is that the ASA/FWSM saw a packet that was sourced and destined to the same ip address and ports. Such a packet cannot logically exist because you cannot have a host send a packet through the network to itself. What the attack was trying to achieve is to have a computer respond to itself and thus have an infinite loop and cause a DoS to it. Most contemporary systems are not vulnerable to such an attack and its variations, but a network level firewall as the ASA / PIX / FWSM should be able to catch them and drop them.

The checks against Land Attacks happen on the ASA/FWSM before many other advanced checks (ACL check, NAT, inspections). There is nothing that can be be done to stop the ASA from dropping these packets as these checks happen as part of the early “network checks” on the packets (not configurable).

If someone sees many of these messages it is probably because of some misconfiguration and we would recommend investigating further. Even if these logs do not relate to any issues, we believe that it should be investigated and corrected in order to find out if it is due to malicious activity or involuntary user-inflicted errors.

Recommended Action:

If this message persists, an attack may be in progress. The packet
does not provide enough information to determine where the attack originates.

ü  You need to find out the packet flow

ü  In order to fetch the packet flow, please capture the pcap in  all the interfaces (it will give lot of information including mac  address)

ü  If you have a firewall deployed between the source and destinations, they its already blocked. However it will display in the logs as blocked often.

ü  If you see the Public IP, it may get statically NATed somewhere. So please try removing the static entry and observe the logs  (this is workaround)

ü  You can execute the shun command in the firewall (if cisco) to tell the device to discard the packet from processing.

The actual syslog looks like,

%ASA-session-2-106017: Deny IP due to Land Attack from <ip address> to <ip address>

These syslogs often seem to occur with no apparent reason, and make most administrators think they are under attack. Experience has shown that in most cases the issue is caused by a mis-configuration on the ASA or other network devices. It is rare that someone is attacked with a Land attack in current systems (it was an old type of attack for older unpatched OSs).

Troubleshooting

For troubleshooting purposes here is a list of the sample questions to be answered to investigate the issue:

• Capture the packets of the Land Attack on the ASA/FWSM interface using the capture command.
• Who does the ip address in the Land Attack belong to

o    If the ip address belongs to the ASA/FWSM

• Is the ASA/FWSM doing any translations of hosts to that ip address?
• What hosts are translated to that ip address?
• Is the ASA allowing “hair-pinning” (reaching the interface and be sent out the same interface) on the interface that also translates?

o    If the ip address does not belong to the ASA/FWSM

• Are there any other devices that could be translating to that ip address?
• Look into logical traffic flows that could be destined to the ip address

o    Could there be a routing loop that is sending packet that is destined to a host through a NATting device that translates to an ip that is the same as a destination?

Common causes:

Depending on the ip addresses mentioned in the error messages, there has been a few common root causes for involuntarily generating Land Attack packets that trigger the Land Attack messages. These can be categorized as follows:

Traffic hair-pinning on the ASA/FWSM

The issue is often caused by NATting and hair-pinning of traffic on the ASA. An example could be this thread. If the ip address mentioned in the Land Attack syslog belongs to one of the ASA interfaces, it is more likely that the problem faced belongs in this category. We would recommend trying to capture the packets on the interface using the capture command and checking if the issue is caused by hair-pinning traffic (traffic hitting an interface is sent out on the same interface) on the ASA itself and routing it back. Commands in the config like “same-security-traffic permit intra-interface” and “nat/global” or “static” referring to the same interface usually tie with the issue.

Routing

It is also common that routing loops can trigger this issue. For example if a host is going through a path that translates its source but then the packet is also going through a route that translates its destination and then the Ethernet frame it is forwarded to the ASA’s MAC address. Than it might end up having the ASA complain about same source and destination?

NATting

We will present an example that can show how improper NATting can cause a land attack packet. Let’s think of an ASA/FWSM that has configuration

nat (inside) 1 0.0.0.0 0.0.0.0

global (dmz) 1 10.10.10.10

static (dmz,inside) 172.16.1.10 10.10.10.10

If a host behind the inside is trying to reach 172.16.1.10 the packet leaving the dmz interface will have source ip being 10.10.10.10 (because of the nat/global) and destination again 10.10.10.10 (because of the static). Thus, if the router on the dmz interface points to the ASA/FWSM for traffic destined to 10.10.10.10 then the ASA/FWSM is going to see the packet and flag it as Land attack.