questions regarding Security Zones

[Wolfgang]

We have configured Security Zones on an interfaces and some rules with Security Zones as source or destination.

Traffic with destination IP-address of the interface in the defined Security Zone does not match via the rule with zones. I believe the interface IP-address should be included in the defined Security Zone of the interface, but maybe not ?

Another question regarding logging... Is it possible to use the Security Zones as a filter in the logs ?

[Bob_Zimmerman]

Is the traffic from the zone to itself? If so, I would expect that to match traffic to the firewall.

If instead you're allowing traffic from one zone to another zone, I would expect that to not match traffic to the interface leading to the destination zone. The zone matches traffic which would come in or go out the interface. Traffic to an IP owned by the firewall stops at the routing table and wouldn't go out the interface.

The inherent difficulty of predicting what will match a zone object is a big part of why I dislike them.

[the_rock]

I believe you can do that, yes.

[Lari_Luoma]

Zones are basically interface tags or groups. You add interfaces into a specific zone and then create rules based on those zones, for example you can have internal, external and DMZ zones. 
While you can allow traffic based on zones only, it's fairly broad unless you have very specific services behind each interface. Best practice with zones is to use inline layers. 
Parent rule is from zone 1 to zone 2. Then build more granular sub-policy where you can use identities, IPs, applications etc. to match traffic.

[Wolfgang]

@Lari_Luoma parent rules with zones and then inline layer with more granular rules is what we configure.

But return to my questions......

1. Is the interface IP included in the zone of the interface ?

2. Is it possible to define a log filter with zones ?

3. Are Security Zones working with automatic topology calculation ?

 

[Lari_Luoma]

1. A Security Zone incude whatever traffic comes through that interface. It's not based on IP-addresses. 
2. You cannot directly filter based on zones in the logs. However, you can filter according to the rules or rule names that use zones.
3. Zone is an interface tag/definition and does not interfere with the topology in any way. 

[Bob_Zimmerman]

For item 1, is the decision based on the routing topology, or is it based on actually passing through the interface?

Let's say you have a firewall with bond1.123 (address 10.0.123.1/24, zone A) and bond1.234 (address 10.0.234.1/24, zone B) a rule which allows traffic from zone A to zone A, and another rule which allows traffic from zone A to zone B.

If 10.0.123.5 tries to connect to 10.0.234.5, that should match the A-to-B rule.

If 10.0.123.5 tries to connect to 10.0.123.1, I would expect that to match the A-to-A rule. Is that what actually happens?

If 10.0.123.5 tries to connect to 10.0.234.1, that traffic won't ever hit bond1.234, so I expect it to not match the A-to-B rule. Is that what actually happens?

[Lari_Luoma]

yes, those networks are behind the interfaces in zone A or zone B, so traffic between them should match the zone based rule. If you are only connecting to the interface IP address, I don't think that would match a zone though.

[Wolfgang]

Additional question….

We have three gateways managed by the same management in the same management domain.

gateway A with zone A

gateway B with zone B

gateway C with zone C

Traffic flow from zone A to zone C goes through gateway B. When I configure a rule allowing traffic from zone A to zone C and install this rule on gateway B, knows gateway B the zones from the other gateways and allows the traffic? 

[PhoneBoy]

Zones are evaluated locally by the gateway processing the traffic.
Which means, in your example, the "Zone A to Zone C" rule would work only if Gateway B has Zone A and Zone C configured on the appropriate interfaces.

[Wolfgang]

Verified by a small test scenario. Policy install failed if we use a security zone, that is not attached to the gateway interfaces.

Gateway: XXXXXXX

Policy: Policy_XXXX

Status: Failed

- Layer 'Network': Rule 15.79 has security zone objects that are not attached to any interface used XXXXXX: Zone XXXXXXX.

- Policy verification failed.

Any possibility to use Security Zones in a global way ? Use of zones from a bunch of gateways to the central datacenter firewall.

[PhoneBoy]

No, and I'm not sure how such a thing would work in practice.
Maybe something similar to "Identity Awareness" passing zone tags between gateways somehow.
Not sure how scalable that is, practically speaking. 

[Bob_Zimmerman]

That's basically the problem meant to be solved by Cisco's TrustSec with the Security Group Tags (newly supported by R82.20's Identity Awareness).

[Lari_Luoma]

You cannot use zone objects that are not attached to any interface.

[Arne_Boettger]

To be honest, for me Zone Based Firewalling in CheckPoint always looked like a feature only implemented because other vendors could put "but CheckPoint can not filter based on Zones" on their Battle Cards.

I have quite some experience with the approach of putting rules on interfaces other vendors use, and I am always happy to see that a CheckPoint Policy does not care about which interface traffic comes from. 

And I would always recommend to structure your firewall policy on other things than network topology.

Ignoring the interface traffic comes from or goes to is of course only possible and acceptable with proper Anti-Spoofing configuration 😉

[ccsjnw]

Totally agree. Zones exist because other vendors do it this way (Cisco) and it's useful when migrating rule bases from Cisco ASA to CheckPoint. I would never use zones natively in a CheckPoint environment. Wrong way of thinking about traffic flows in my opinion.

[PhoneBoy]

Above and beyond competitive battlecards, we also had specific customer requests for Zone-Based Policies. 🙂
We added support for Zones in R80.