Implicit Rule: Permit all traffic to less secure networks

Unanswered Question
Mar 22nd, 2007

When an access-list is not applied to an interface, Cisco ASDM shows the following rule for that interface:

'Any' to 'Any less secure network' Permit

But as soon as ANY rule is added, the implicit DENY takes over and no other traffic is allowed.

The question is, is there an access-list statement that would restore the 'Any to Any less secure network' rule?

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
vitripat Thu, 03/22/2007 - 09:02

Hi ,

In order to restore access to all the less secure networks, we will need to create new rules. Here are the steps you could follow in creating these rules:

1) Permit access to some resources as per requirement on more secure network. If not traffic is to flow from less secure to more secure network, then skip to step 2.

2) Deny access to any more secure networks from less secure interface using access-rule.

3) Permit all other access or permit access based on the requirements.

Now access to more secure networks will be denied, however what ever access to less secure networks is desired will be available.

ASDM shows it logically but has no ACL as such in place. Once you create a rule and bind it to an interface, only those rules are in effect. Thus we need to make changes to the rules binded to an interface accordingly.

Hope that helps.



acomiskey Thu, 03/22/2007 - 09:07

Yes, remove the access list.

If you are looking to deny only some traffic and not all, add your denies, then add a permit ip any any. I think this is what you're asking

access-list inside deny ...

access-list inside deny ...

access-list inside permit ip any any

access-list inside deny ip any any

access-list inside in interface inside Thu, 03/22/2007 - 09:27

Thank you for you responses.

This all seems very archaic.

The solution basically creates a situation where something has to be explicitly denied, otherwise it will pass. Hardly good security practice.

So for example, if another interface is added on the firewall with a higher security level, the lower security traffic would be allowed into it, unless the admin remembers to specifically add the DENY.

If this is the only way, then what is the syntax for specifying ALL traffic to a specific Interface?

In ADSM, the access-list only allows specification of a target by IP, or interface IP (or object groups which are a list of IPs). How can one specify ANY for a specific interface?

vitripat Thu, 03/22/2007 - 09:36


If another higher security level interface is added, acces to this interface from a lower security level interface will be implicitly denied and this is a good security practice.

However, if you add another lower security level interface, access to lower-security level will be obvioulsy available from a higher security level interface, provided we have translation rules in place.

In ASDM, we cant specify the interface name as the target. Targets can be the networks/hosts on that interface. This is as per the syntax of access-list command. Thu, 03/22/2007 - 12:30

Let me try again to explain the problem:

interface Ethernet0/0

nameif internet

security-level 0

interface Ethernet0/01

nameif priv1

security-level 10

interface Ethernet0/02

nameif priv2

security-level 20

Without any access lists added, the traffic allowed is from higher security interfaces to lower security interfaces...

So this is allowed:

priv2 -> priv1 and internet

priv1 -> internet

internet -> nothing

But if I add the following access list:

access-list priv1 extended permit ip any host_in_priv2

Then the allowed traffic will be like this:

priv2 -> priv1 and internet

priv1 -> host_in_priv2

internet -> nothing

Meaning that priv1 will lose access to the internet (because of implicit deny).

What I'm trying to do is to restore the internet access.

But I can't do this:

access-list priv1 extended permit ip any any

Because it would allow access from priv1 into priv2 (which has a higher security context):

priv2 -> priv1 and internet

priv1 -> priv2 and internet

internet -> nothing

So your suggestion is to do the following:

access-list priv1 extended permit ip any host_in_priv2

access-list priv1 extended DENY ip any priv2_nets

access-list priv1 extended permit ip any any

Which would have the desired result of:

priv2 -> priv1 and internet

priv1 -> host_in_priv2 and internet

internet -> not allowed


My reply to you was that this is bad, because if another interface with higher security is added:

interface Ethernet0/03

nameif topsecret

security-level 80

Then the immediate result of traffic being allowed would be:

topsecret -> priv2, priv1 and internet

priv2 -> priv1 and internet

priv1 -> host_in_priv2 and internet and topsecret (<- this is the problem)

internet -> not allowed

So you can see that priv1 now has access to the topsecret interface which is not desirable. Unless the admin again adds an explicit deny to the priv1 accesslist to prevent it.

But that is my point, that this is archaic and convoluted.

So the question still stands if anyone can answer it.

vitripat Thu, 03/22/2007 - 12:42

I see your point.

However, whenever we add a new interface to the configuration, we are aware prior to adding it to the configuration about the security-level and the networks on the new interface. Thus, prior to adding the new interface to config, first you should edit the ACL on the lower interface to deny the traffic to the new networks on the new higher security level interface and then add the interface.

This is the way to make things secure, safe and running all the time....

I hope I make my point clear ..



acomiskey Thu, 03/22/2007 - 12:48

Vibhor has explained this very clearly. You are making it harder than it needs to be. If you created a topsecret interface, you should know enough not to give it a lower security level than an interface which is not supposed to access it has. Thu, 03/22/2007 - 12:56

Read over the post again carefuly please.

In the scenario, the topsecret interface does have the highest security level of all interfaces.

Which is why it is problematic that the traffic from the lower security 'priv1' network will be allowed into it.

An admin should never have a situation where they have to explicitly deny traffic to prevent it.

vitripat Thu, 03/22/2007 - 13:02

Have you gone through what I recently posted ?

It explains the steps you need to take when deciding to add a new higher security level interface.

In secure networks, first we do planning, verify current config, modify current config as per new plan, implement the new changes.

In your case, if you straight add the interface to configuration, it will be planning and then implementing the new changes .. skipping the two very important steps in between. All has to be sequential.


Vibhor. Thu, 03/22/2007 - 13:17

Yes. We're on the same page.

But the other guy wasn't even understanding the point.

My assertion is that this is non-optimal. Adding ANY to ANY permit rules makes it real easy for traffic to slip through, especially if you then have to go back and DENY elsewhere.

vitripat Thu, 03/22/2007 - 13:24

Right, if you need to add one more interface, we need to deny access to these networks first so that traffic does not slip through using the existing permit ip any any access-lists.

Hope things are clear now .. :-)



acomiskey Thu, 03/22/2007 - 13:26

Ha, what is it that you would like exactly?

You don't want to permit any any, but you also don't want to have to deny anything....interesting concept I should have gotten the first time around.

Yes, I did miss your security level 80, I admit that, but you could have made the conversation much easier by using inside outside dmz etc...


This Discussion