ASA5540 - Deny reverse path check

[Staticfactory]

I could really use your help as I'm still fairly wet behind the ears when it comes to this sort of thing.

Our ASA has been flooded with "Deny reverse path check" drops and I can't figure out for the life of me how to find the culprit. I'll elaborate... first, here is an example from the ASA log:

===========================================

Jan 30 2009 14:29:46 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.7 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:46 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.7 on interface inside
Jan 30 2009 14:29:47 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.9 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:47 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.9 on interface inside
Jan 30 2009 14:29:48 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.101 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:48 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.101 on interface inside
Jan 30 2009 14:29:48 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.6 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:48 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.6 on interface inside
Jan 30 2009 14:29:49 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.7 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:49 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.7 on interface inside
Jan 30 2009 14:29:50 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.5 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:50 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.5 on interface inside
Jan 30 2009 14:29:51 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.8 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:51 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.8 on interface inside
Jan 30 2009 14:29:53 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.5 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:53 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.5 on interface inside
Jan 30 2009 14:29:54 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.9 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:54 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.9 on interface inside
Jan 30 2009 14:29:55 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.7 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:55 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.7 on interface inside
Jan 30 2009 14:29:59 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.5 to 65.58.240.105 on interface inside
Jan 30 2009 14:29:59 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.5 on interface inside
Jan 30 2009 14:30:01 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.6 to 65.58.240.105 on interface inside
Jan 30 2009 14:30:01 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.6 on interface inside
Jan 30 2009 14:30:02 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.101 to 65.58.240.105 on interface inside
Jan 30 2009 14:30:02 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.101 on interface inside
Jan 30 2009 14:30:04 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.8 to 65.58.240.105 on interface inside
Jan 30 2009 14:30:04 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.8 on interface inside
Jan 30 2009 14:30:04 Firewall : %ASA-1-106021: Deny TCP reverse path check from 10.10.10.6 to 65.58.240.105 on interface inside
Jan 30 2009 14:30:04 Firewall : %ASA-1-106021: Deny TCP reverse path check from 65.58.240.105 to 10.10.10.6 on interface inside

===========================================

As you can see, we're seeing up to 10 attempts per second for these connections. The hosts are ALWAYS 10.10.10.X and 65.58.240.105 respectively.

First of all, we do not have anything internally that uses the 10.x.x.x range, nor do we have any routes for that range (besides the default). Based on some packet sniffing, It appears that these 10.0.0.x hosts are trying to establish connections on TCP 10000 to the external host 65.58.240.105 (my only guess is that they are trying to create an IPSEC tunnel over TCP/IP).

The packets only show that the source and destination MAC addresses are the inside interface of the ASA and one of our VLANs on the core switch respectively. I can't find any ARP information or anything else that would help clarify the situation.

This has been happening for days, and I assume I could just deny the traffic entirely, but I would rather STOP the traffic (if possible) and avoid the added load on the ASA.

Can anyone give me a hint as to how to find out where these connections are coming from?? It would be GREATLY appreciated!!

 

[unclerico]

this is a security mechanism. you have the following command in your config:

ip verify reverse-path interface inside

You need to trace this back to the source. This may or may not be a malicious attack. Go to your core switch and look in the arp cache and the mac address table to see what port(s) the traffic is originating from. Physically walk down to the machine and hit it and the user with a baseball bat

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[Staticfactory]

Thanks for your reply unclerico.

The problem is that I can't, for the life of me, find the source of this traffic.

The core switch does not contain ANY ARP information regarding any of the addresses in question, nor is there anything in the mac address table to trace back.

I don't even know if the traffic is originating from inside our outside the network. One article I read suggested that it's possible a user has VPN'd in and is using the "Use gateway on remote network" option in their client. Considering the number of addresses in question, I would find this hard to believe.

All I know is that this rogue 10.10.10.X subnet is managing to hit the inside interface on my firewall... I almost wonder if someone's popped a home router/switch onto the network somewhere and is not PATing the hosts behind it... but you'd think I would be able to find SOME kind of ARP information or something similar.

 

[North323]

do you have avaya phone swith? or avaya IP phones. i have seen this before, check out the whois for that IP destination

http://samspade.org/whois/65.58.240.105

that could be a dns server the phone equip is trying to reach

 

[Staticfactory]

The host addresses have started to change dynamically as we set up blocking rules, so we've deduced that a host somewhere has been compromised and is creating the spoofed traffic. Thanks for your help.