ZBF & ACL?

[louis0001]

We have a private MPLS network which we want to tighten up the security on the ISR routers we have.

Lets say:

g0/1.4000 = MPLS (our connection into the MPLS network) We'll call this OUTSIDE

g1/1.100 = LAN 1 (our data wit the odd server sitting on there, let's say RDP or VNC) We'll call this INSIDE

g1/1.200 = LAN 2 (our guest) We'll call this GUEST

To simplify this, we want all traffic to flow from:

INSIDE > OUTSIDE (only to specific Private IP ranges and public IP's)
GUEST > OUTSIDE (but only to public IP's and not private IP's)

OUTSIDE > INSIDE (only to specific IP running VNC or RDP)

CBAC is fairly easy to understand in this scenario:

eg ACL on the INSIDE limiting traffic to specific Private IP's and public IP's and an ACL on the OUTSIDE in with an inspect on the OUTSIDE out. The ACL on the OUTSIDE in allows RDP to INSIDE specific IP on RDP or VNC

I want to translate this to ZBF but not sure how ACL's interact with ZBF?

[Georg Pauwen]

Hello,

as far as I recall, the recommendation is to NOT use access lists and zone based firewalls together. If you configure ZBF, the order of operation is that the ACL is applied first, then the zone based firewall. Typically, if configured correctly, the zone based firewall should provide enough security...

[louis0001]

If the ACL is applied first, the explicit deny would drop all returning traffic. With CBAC, isn't the outgoing inspect dynamically added to incoming ACL above the explicit deny on the same interface?

Does ZBF not do the same?

In this case, I want to allow all outgoing but block all incoming apart from 1 IP using RDP

[Karsten Iwen]

The manually applied ACL is not part of the stateful inspection. Any deny is applied statelessly. It's best to be used with a permit any at the and only to block protocols that should never enter your network (as an infrastructure-ACL, like blocking incoming SNMP, TELNET, and so on.)

[louis0001]

I think this may be done with zone-pairs?

eg

OUTSIDE would have zone-pair INSIDE>OUTSIDE to allow all traffic out.

The above alone would allow traffic to be initiated from client INSIDE and thereturning response from outside. It wouldn't allow traffic to be initiated from outside to server on INSIDE

We would then need another zone-pair OUTSIDE>INSIDE to allow traffic to be initiated from Outside to the server on the INSIDE

So with the above zone-pairs, traffic can flow from inside to outside and receive responses but only traffic initiated on outside can go to server on INSIDE?

[Karsten Iwen]

It has to be done with zone-pairs. Without them, you don't have a ZBF.

And with the two zone-pairs (and correctly applied policy-maps and class-maps with match-conditions) it will work as outlined by you.

[louis0001]

So if I just applied an INSIDE>OUTSIDE allowing all,

I would have thought the following would occur:

traffic from INSIDE would access outside and returning traffic would be allowed (as it's stateful)

But OUTSIDE > INSIDE traffic would not be allowed if not intitiated from the INSIDE

To get OUTSIDE initiated traffic to hit the INSIDE, I would have to add another zone-pair eg OUTSIDE>INSIDE

[Karsten Iwen]

Yes, that is exactly how it works.

[louis0001]

Brill. I've had a few days on it now and getting used to ZBF.

Quick question - is it better to specify a custom service via a port map or via an access list

eg

class-map type inspect match-all MYCLASSMAP
match access-group name MYACCESSLIST

ip access-list extended MYACCESSLIST
permit tcp object-group LOCAL-LAN object-group REMOTE-LAN eq 6000

OR

ip port-map MYAPP port tcp 6000

class-map type inspect match-all MYCLASSMAP
match access-group name MYACCESSLIST
match MYAPP

ip access-list extended MYACCESSLIST
permit ip object-group LOCAL-LAN object-group REMOTE-LAN