There have been multiple cases where someone sees a drop syslog on his ASA / PIX / FWSM firewall saying "Deny IP due to Land Attack" and wonders what it means. 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).
Explanation of the message
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 to investigate 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.
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
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?
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
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?
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 thead. 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.
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.
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 traffi destined to 10.10.10.10 then the ASA/FWSM is going to see the packet and flag it as Land attack.
We have some Cisco 891W Routers with that have Cisco Virtual Office (CVO) on them. We need to delete it. Resetting the routers does not remove this. We are not sure what this is exactly, but notice that when you type in the username and passwor...
Hi,We are trying to figure out if there is a way to monitor certificate valid period / expiry date via SNMP on ISE v2. From earlier posts this kind of monitoring seems to usually be done via SMTP or syslog. However, this solution is not preferable wi...
HiI have a customer who is using a 2FA Anyconenct VPN on FTD 6.6.1. How can I change the Anyconnect '2nd password' field to something more user friendly, such as 'pin' or 'token'? I have found how you do it on ASDM but not on FTD. Any hel...
Hello all!I have a couple of ISA3k devices, which have lost FMC connection after losing power.More than that, they show no FMC configured at all:> show managersNo managers configured. But if I try to add one it reports DB loss:> configure manag...
Hello everybody, newly our customer get the error message in teh FMC Health Monitor: High unmanaged disk usage on /ngfw /ngfw using 85%: 106G (20G Avail) of 126Gon both Firepower 4110 of a HA pair (see attached screen dump). My qu...