ACL explicit any any IP deny needed?

[quang@thaweb.com]

Hello,

I'm new to setting up Cisco ASA and so ACL will be new for me too. The ACL is set up with rules for ports opened to specific IPs on my DMZ but I was wondering if I need to create an explicit rule for any any IP deny so that everything else not in the rules are blocked or are everything else blocked implicitly without me creating the any any IP Deny?

Any help is greatly appreciated!

Thanks!

[Steven Case, MBA-ITM]

The answer is "kinda yeah".

So, if you don't configure anything, then the default action will be to not allow packets from less-secure (lower-number) ports to more-secure ports. In this instance, you'd configure your Outside to 0, DMZ to 50 (or whatever is > 0 but less than "inside") and Inside to 100. Your inside will communicate with DMZ and Outside without issue, keeping state on all traffic (kinda slow, but these devices handle it well). However, non-stateful (UDP) and non-state (TCP non-established) will not travel from Outside to inside, or Outside to DMZ without ACE in the ACL.

Here's where it gets fun. If you add a ACE into the ACL, this default setting goes away. You now have to configure a whole ACL. I generally do this on my ASA.

This is the "kinda yeah" part. At the very bottom of your ACL screen (in ASDM - totally recommend using, and I'm a CLI guy for everything but these devices), you'll see an implicit deny ip any any, which will match all other traffic that isn't otherwise defined. If you don't configure the ACE and only use the security levels, this rule applies to all "unmatched" packets. So, no matter what, the deny ip any any does exist, but the ACL work differently depending on configuration.

Hope it helps.

[quang@thaweb.com]

Hi Steven,

Thank you for your quick response. I am using ASDM. I do see the any any IP Deny in the Global but it's not enabled. Should this be enabled it or create another one at the bottom of the Outside rules?

Appreciate the help!

[Steven Case, MBA-ITM · Accepted solution]

Based on that photo, that rule looks to be enabled, but could also be at the end of an ACL, as it's line 3 and the implicits are usually the only line at the end.

When you alter one of the ACL (outside, inside, DMZ, etc.), the implicit rule is added but not visible (much like a regular ACL). So, you're good without adding the rule. Best thing to test is to enable logging, go to Monitor -> Logging -> View log, and verify that the traffic you haven't allowed (or don't want to allow) is being blocked. The interface is... questionable as far as interaction, but each line gives you the same SYSLOG information you'll get anywhere else.

The only benefit I've ever had with an explicit rule at the end is the "Hit Counter" aspect. I'll reset it every hour just to get an idea of whether I need to start a capture or not (and thus ruin the rest of my day). So, if you want to monitor the denys occurring do the explicit, otherwise it's just clutter. Also, some requirements (DISA STIG, ACAS, etc.) require an explicit entry, because the scanners aren't intuitive. If you have a SOC or IA group that will be evaluating the device against a baseline then throw the explicit in there as well.