02-10-2010 07:36 AM - edited 03-11-2019 10:07 AM
I'm currently using an ASA 5540 with several basic access lists. I'm attempting to view the hit counts on a particular access list, specifically the 'deny any any' on the outside interface. Now, I can actually see the hit counts themselves increasing by either running the 'sh acces list' or by viewing the ASDM under Configuration/Firewall/Access Rules. The 'deny any any' acl is set to 'log informational', so I can see the hit counts increasing with each failed attempt to reach the outside interface. What I *want* to see is all failed traffic that is attempting to access that interface.Not just the hit counts themselves, but what those hits actually are.
Here are my log settings on the firewall currently
logging enable
logging buffer-size 10000
logging monitor errors
logging buffered informational
logging trap notifications
logging asdm informational
A few more details may be important: The outside interface is open from only one specific source IP. And it's only allowing in a custom TCP port, we'll call it TCP 56128. All is fine and well with that, as it works like it should.
So when I attempt to access the outside interface from an unallowed port like say, icmp, http, https, smtp, ftp, telnet, dns, ldap, netbios, or RDP, the real time log veiwer shows the failed attempt. Great!
BUT, when I try to access that outside interface from a different port that is not allowed like tftp or kerberos or a random tcp port like 56128, it does not log it. The hit count increases, but I don't see what the heck it is.
Am I missing something? Is there a way to tell the ASA "when you see this TCP port fail to reach the outside interface, show it in the log viewer"?
Thanks in advance!
02-10-2010 06:50 PM
This question was asked in the forum in the past. I can't seem to find that thread.
Only when there is translation in place the acl will be checked to see if there is permission.
If there is not static pat for this odd port that you are testing then it won't check it against acl and hence won't log.
You can find it drop in the asp drop catpure.
you can issue "sh asp drop" then "clear asp drop" and show again.
capturing asp drop :
cap capasp type asp-drop all
sh cap capasp | i x.x.x.x
you can issue "clear cap capasp" to start collecting fresh packet and "no cap capasp" to remove the capture altogether.
where x.x.x.x is the source IP in question or you can grep for the odd port number as well.
-KS
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide