Cisco ASA – Apple Devices Causing ‘Land Attack’ on Cisco ASA

ciscocisco-asaSecurity

Recently migrated to a Cisco ASA/Sourcefire implementation in our enviroment and have been going through the logs on the ASA. Looking over the logs I noticed multiple critical errors that kept coming in waves. The message is a "Land Attack" being denied.

The IP's are our external PAT POOL addresses being sent from the inside to the ASA itself. Here is the error message from the ASA. Below is a sample of the error message:

06-17-2016 08:01:16 Local4.CriticalX.X.X.X.X%ASA-2-106017: Deny IP due
to Land Attack from (external IP) to (external IP)

After doing some wiresharking we discovered that this was happening everytime Apple devices in the network were trying to get to addresses:

17.173.254.222

17.173.254.223

17.173.255.222

17.173.255.223

Here is a packet capture from one: (1.1.1.1 = Our external Nat address)

61065 232.862006 10.70.200.188 -> 17.173.254.222 UDP Source port:
58994 Destination port: 16384

61066 232.862006 10.70.200.188 -> 17.173.254.222 UDP Source port:
58994 Destination port: 16385

61067 232.862006 10.70.200.188 -> 17.173.254.223 UDP Source port:
58994 Destination port: 16386

61068 232.862006 10.70.200.188 -> 17.173.254.222 UDP Source port:
49729 Destination port: 16384

61069 232.862006 10.70.200.188 -> 17.173.254.222 UDP Source port:
49729 Destination port: 16385

61070 232.862006 10.70.200.188 -> 17.173.254.223 UDP Source port:
49729 Destination port: 16386

61080 232.901006 10.70.200.188 -> 1.1.1.1 UDP Source port: 58994
Destination port: 58994

Line 61080 is what triggers the "land attack" message and is repeated about 5 times before reverting back to using the correct inside local address for the source. For some reason it is acting like Apple resorts to using the outside global address as the source address for the devices, causing the land attack log. We have found the ports its using when this happens are common to Apple's FaceTime, iMessage, Gamecenter and iChat. Usually 16393 – 16403.

I have tried adding "ip verify unicast source reachable-via rx" on layer 3 interfaces on the core switch right before the ASA with no success.

Has anyone seen this before and successfully fix it? Looking for a solution other than blocking the 17.173.xxx.222/3 with an ACL at the core before being sent to the ASA.

Best Answer

A LAND attack, or LAN-D attack in some circles, is an attack that involves sending a host a packet with a source and destination address matching the host's IP address.

The idea is if a host with the IP 5.5.5.5, receives a packet with a destination of 5.5.5.5 (itself) and a source of 5.5.5.5, it will respond to the packet, back to itself... potentially creating a response loop... and sometimes simply blue-screen crashing the host's OS.

Nearly all modern operating system have been patched to make this "attack" useless, but the Cisco ASA (and many other security products) still protect against this type of "attack". Which is to say, if the ASA seems a packet with a matching Source and Destination address, it will drop it claiming a potential LAND attack.

In your case, your inside addresses 10.70.200.0/24 are being NAT'ed to a public address of 1.1.1.1. So two things can be happening, both of which might be triggering the LAND attack.

Imagine this scenario:

Host ----- ASA ----- Upstream Router ----- Internet

Scenario #1: Host sends a packet with SRC 10.70.200.20 and DST 1.1.1.1. Packet gets to ASA, ASA applies your PAT rule and translates it to SRC 1.1.1.1 DST 1.1.1.1 -- ASA detects matching source/destination and drops packet

Scenario #2: Host sends a packet with SRC 10.70.200.20 and DST 1.1.1.1. Packet gets to ASA, ASA applies your PAT rule and translates it to SRC 1.1.1.1 DST 1.1.1.1. Packet is forwarded to Upstream Router. Upstream Router has an entry in its Routing Table telling it the 1.1.1.1 IP address exists back towards your ASA and sends it that way. ASA receives a packet with a DST of 1.1.1.1 and a SRC of 1.1.1.1 -- ASA detects matching source/destination and drops packet

In my experience, I have seen it mostly be #2 that was in play. I don't believe (don't quote me) the ASA will watch for the land attack on traffic going from higher security level to lower security level (aka, inside to outside).

I am guessing this is happening when the Apple devices are trying to talk directly to each other, they detect each other's public IP addresses using STUN or some other system, but they don't realize are on the same internal network, so they both actually share the same public IP address.

To circumvent, you will need to create a new PAT rule so that when your inside hosts are speaking to 1.1.1.1, their source should be re-written as 1.1.1.2 (or anything other than 1.1.1.1). This way the SRC and DST don't match, and don't trigger the ASA's LAND Attack defense.

Related Topic