03-22-2007 08:56 AM - edited 03-11-2019 02:50 AM
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.
03-22-2007 09:02 AM
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.
Regards,
Vibhor.
03-22-2007 09:07 AM
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
03-22-2007 09:27 AM
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?
03-22-2007 09:36 AM
No.
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.
03-22-2007 12:30 PM
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 255.255.255.255
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 255.255.255.255
access-list priv1 extended DENY ip any priv2_nets 255.255.255.0
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
BUT
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.
03-22-2007 12:42 PM
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 ..
Regards,
Vibhor.
03-22-2007 12:48 PM
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.
03-22-2007 12:56 PM
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.
03-22-2007 01:02 PM
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.
Regards,
Vibhor.
03-22-2007 01:17 PM
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.
03-22-2007 01:24 PM
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 .. :-)
Regards,
Vibhor.
03-22-2007 01:26 PM
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...
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