%ASA-2-106017 Deny IP due to Land Attack errors

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?

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.

ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG#

Content here is sourced from tunnelsup.com

http://www.tunnelsup.com/isakmp-ike-phase-1-status-messages/

ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG#

ISAKMP (IKE Phase 1) Negotiations States

The MM_WAIT_MSG state can be an excellent clue into why a tunnel is not forming. If your firewall is hanging at a specific state review this graph below to find where along the path the VPN is failing.

ASA ISAKMP STATES

IKE Phase Messages - IMG

Graph source: tunnelsup.com

These are the possible ISAKMP negotiation states on an ASA firewall. ISAKMP stands for: The Internet Security Association and Key Management Protocol

  • MM_WAIT_MSG2 Initiator Initial DH public key sent to responder. Awaiting initial contact reply from other side. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. If stuck here it usually means the other end is not responding. This could be due to no route to the far end or the far end does not have ISAKMP enabled on the outside or the far end is down.
  • MM_WAIT_MSG3 Receiver Receiver is sending back its IKE policy to the initiator. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. Hang ups here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.
  • MM_WAIT_MSG4 Initiator Initiator is sending the Pre-Shared-Key hash to its peer. Initiator sends a hash of its PSK. Initiator will stay at MSG4 until it gets a PSK back from its peer. If the receiver is missing a tunnel group or PSK the initiator will stay at MM_WAIT_MSG4
  • MM_WAIT_MSG5 Receiver Receiver is sending its PSK hash to its peer. Receiver does not yet check if PSK hashes match. If receiver has a tunnel-group and PSK configured for this peer it will send the PSK hash to the peer. If PSKs don’t match, receiver will stay at MM_WAIT_MSG5. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off.
  • MM_WAIT_MSG6 Initiator Initiator checks if PSK hashes match. If PSK keys match, Initiator becomes MM_ACTIVE and lets receiver know of match. If PSK doesn’t match, initiator stays at MM_WAIT_MSG6. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off. However, if the state goes to MSG6 then the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to stay at MM_ACTIVE.
  • AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed.

PIX ISAKMP STATES

    • MM_NO_STATE

ISAKMP SA has been created but nothing else has happened yet.

    • MM_SA_SETUP

The peers have agreed on parameters for the ISAKMP SA.

    • MM_KEY_EXCH

The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The I SAKMP SA remains unauthenticated.

    • MM_KEY_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state trans itions immediately to QM_IDLE and a Quick mode exchange begins.

    • AG_NO_STATE

The ISAKMP SA has been created but nothing else has happened yet.

    • AG_INIT_EXCH

The peers have done the first exchange in Aggressive mode but the SA is not authenticated.

    • AG_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE and a Quick mode exchange begins.

    • QM_IDLE

The ISAKMP negotiations are complete. Phase 1 successfully completed. It remains authenticated with its peer and may be used for subsequent Quick mode exchanges.

What is the difference between MM and AM?

Main mode vs Aggressive mode. Here is a image taken from Cisco’s website to show the difference.

MM AM - IMG

As you can see the Main mode is the same as the flowchart at the top of the page. Aggressive mode only uses 4 steps to establish the tunnel.

Troubleshooting ISAKMP Or Phase 1 VPN connections

When troubleshooting VPNs, a very common problem is phase 1 not establishing correctly. Here’s a quick checksheet to make sure you have the configuration correct.

  • Verify ISAKMP parameters match exactly.
  • Verify pre-shared-keys match exactly.
  • Check that each side has a route to the peer address that you are trying to form a tunnel with.
  • Verify ISAKMP is enabled on the outside interfaces.
  • Is ESP traffic permitted in through the outside interface?
  • Is UDP port 500 open on the outside ACL?
  • Some situations require that UDP port 4500 is open for the outside.

Dead Peer Detection – DPD on ASA

ASA and PIX firewalls support “semi-periodic” DPD only. I.e. they send R-U-THERE message to a peer if the peer was idle for<threshold> seconds. ASA may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every <threshold> seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.

Unlike routers, you can completely disable DPD on ASA and it will not negotiate it with a peer (“disable” configuration option).

Also, you can configure “one-way” DPD mode on ASA. The ASA will respond to R-U-THERE messages, but will not initiate DPD exchange (“threshold infinite” configuration option).

isakmp keepalive {disable | threshold <threshold> retry <retry-interval> | threshold infinite}

If the peer doesn’t respond with the R-U-THERE-ACK the ASA starts retransmitting R-U-THERE messages every <retry-interval>seconds with a maximum of three retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on ASA.

DPD is enabled by default on ASA for both L2L and RA IPSec:

tunnel-group DefaultL2LGroup ipsec-attributes
 isakmp keepalive threshold 10 retry 2
tunnel-group DefaultRAGroup ipsec-attributes
 isakmp keepalive threshold 300 retry 2

In brief, on ASA we have the following:

  • only “semi-periodic” DPD is supported
  • DPD can be completely disabled
  • one-way mode is supported
  • bidirectional mode is the default one
  • retry interval can be configured
  • retry count cannot be configured and equals to three

PFS (Perfect Forward Secrecy)

PFS will ensure the same key will not be generated again, so forcing a new diffie-hellman key exchange. This would ensure if a hacker\criminal was to compromise a private key, they would only be able to access data in transit protected by that key and not any future data, as future data would not be associated with that compromised key.

PFS is enabled on an ASA with the crypto map set pfs command.

Both sides of the VPN must be able to support PFS in order for PFS to work. When PFS is turned on, for every negotiation of a new phase 2 SA the two gateways must generate a new set of phase 1 keys. This is an extra layer of protection that PFS adds, which ensures if the phase 2 SA’s have expired, the keys used for new phase 2 SA’s have not been generated from the current phase 1 keying material. Of course if PFS is not turned on then the current keying material already established at phase 1 will be used again to generate phase 2 SA’s.

Therefore using PFS provides a more secure VPN connection. Although using PFS does have its drawback. It will require more processing power, and take slightly longer for phase 1 and 2 to complete. PFS in general is known as a session key. A session key is a key just created for a particular session, and when the session is bought down, the key is destroyed and not used again. Next time a session is initiated a new and completely different session key is created.

You don’t have to use PFS if you don’t want to, just leave it disabled. However if you are protecting very sensitive data then maybe it should be enabled. It depends on your requirements and security policies. It depends on how sensitive your data is and how often you would like to renew these keys. What is the worst that could happen if a criminal did get their hands on this sensitive data? This should give you a good indication to whether you should have it enabled and for how long each key is renewed or disabled. Just remember having it enabled and renewing keys more often will have a little performance impact but provide further security.

So in a nutshell leaving PFS on will improve security forcing a new key exchange. It does this every so often depending on the configured time settings.

 

 

How to reset Cisco ASA 5505 to factory default setting

How to reset Cisco ASA 5505 to factory default setting:

Step 1:
Go to global configuration mode by below command

ASA5505# config terminal
Step 2:
Now give below command to make firewall at default setting

ASA5505(config)# config factory-default 

If you want to get back to the prompt that looks like: ‘ciscoasa(config)#’
Then you have to follow third step

Step 3:

ASA5505(config)# reload save-config noconfirm

Now make sure that the outside line is plugged into port ethernet0, and your pc is plugged into any of the ports 1-7.

The Cisco ASA has been reset to factory settings. DHCP is enabled on the cisco device, and it’s internal IP address is now 192.168.1.1!