Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Donate Today!

Do you enjoy these
technical forums?
Donate Today! Click Here

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Staticfactory (IS/IT--Management)
30 Jan 09 14:49
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 (IS/IT--Management)
30 Jan 09 15:06
this is a security mechanism. you have the following command in your config:

CODE

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 smile

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

Staticfactory (IS/IT--Management)
30 Jan 09 15:38
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 (TechnicalUser)
3 Feb 09 11:54
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 (IS/IT--Management)
4 Feb 09 12:46
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.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close