ASA 5505 - Severity 1: An attack is in progress

I'm getting a lot of severity 1 - attack in progress on my ASA 5505:
Deny TCP reverse path check from xx.xx.xx.xx (external ip) to outside interface

I'm new to these logs; severity 1 seems serious.
Are these common? should I be concerned or is the asa just doing its job and telling me about it?

Any suggestions or input would be appreciated.
ShawnGrayAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

harbor235Commented:
Sounds like someone is directing spoof traffic at your device, you have unicast reverse-path forwarding on and
your device is dropping the traffic. Unfortunately this is too common today, but it sounds like someone is attacking  but your configuration is working to stop this unwanted traffic. How much traffic is it?


Does the ASA add a SHUN for the attacking sources?


harbor235 ;}
0
btanExec ConsultantCommented:
you can verify the what is contributing to this msg with also  "ip verify reverse-path interface ....". the msg is supposed to mean to alert the interface stated received a packet with the source address matching a known inside network address. The intent is to verify that source address is not spoofed and likely there is some config issue. You may want to catch these talking about the uRPF with symptoms that triggers
an incoming packet on that specific interface sources from an address that does not exist in the routing table or exists but with an exit path toward another interface against the one on which it arrives
or
In your case you have either "ip verify reverse-path interface outside" and "ip verify reverse-path interface Inside" feature enabled on both outside and inside interfaces, so what happens is when an incoming packet arrives at the outside and/or inside interface it would be subject to the source validity check (uRPF), if a route exists for that packet flow it would be passed through, otherwise if a route does not exist, or exist but not match the flow, the packet would be denied.
https://learningnetwork.cisco.com/thread/65566
https://supportforums.cisco.com/discussion/11678641/deny-tcpicmp-reverse-path-check-interface-inside
0
ShawnGrayAuthor Commented:
Harbor235 - We had some malicious stuff on the inside of the network which was creating a shun for a couple of local machines.  They're clean and I haven't seen any issues with that.  I have not seen a shun since.

btan - thank you for the input; I'll dig in to these.

Interestingly, I've received a severity 2 "deny IP due to land attack from 'outfacing ip' to the same 'outfacing ip'
How can that happen?  btan, wondering if this could be related to what you are suggesting?

Thank you both,
0
btanExec ConsultantCommented:
you can check out the severity level e.g. alert = sev1 and critical = sev2
http://www.cisco.com/web/about/security/intelligence/identify-incidents-via-syslog.html#3

Ref also this http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html
In Land attacks, the attacker sends the victim a TCP SYN packet that contains the same IP address as the source and destination addresses. Such a packet completely locks the victim's system. This is different as the Cisco device under denial of service - intend to bring it down to no services. Compared to the prev one that is more of IP spoofing and service is still running. Of course the source IP can be spoofed to trigger land attack .. but effort on the adversary

But overall, check out the article for mitigation measures that primarily look into filtering source IP (which can be for the prev alert sev1 if that is not due to misconfig), filtering service  (rid those unnecessary port for exploitation) and filtering dest IP (safeguarded target systems or machines). The Best Current Practices (BCP) 38 in RFC 2827 is one area to look at too. You can find out more in Cisco best practice guide below on topic of anti-spoofing (has uRPF and the BCP 38).
http://www.cisco.com/web/about/security/intelligence/firewall-best-practices.html#_Toc332806006
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ShawnGrayAuthor Commented:
Excellent; thank you
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cisco

From novice to tech pro — start learning today.