topic Re: Best practice with defining Zones - how many is too many in General Topics

Best practice with defining Zones - how many is too many

Alex_Samad — Thu, 11 May 2017 00:07:11 GMT

So I have 3 locations (DC), Internet access , Vendor access, environment (Prod, Uat etc) and user and support users and dmz and ...

should each of these be a zone ??? I am thinking not, after have a bit of a play, you can't make dynamic zones from tags.

So I am thinking

zone_internet - where the interface talks to the internet

zone_vendor - where there interface talk to my Vendor network

zone_int - anything inside.

zone - guest - i have a guest wifi network - sort of internet ....

maybe ...

a zone prod - to add extra protection around prod ??? or just use address groups

zone - staff << probably most dangerious group 🙂

zone - support staff << nearly as dangerious as the above

Re: Best practice with defining Zones - how many is too many

VinceM — Thu, 11 May 2017 08:08:37 GMT

Hi,

Keep in mind that if you want a flow move from on zone to another, you need a security rule.

Then more you have zone more you hace security policies and potentially more you have to provide support and more it's difficult to maintain.

If you work in a bank, for sure you need more zone than if you are a small company ...

Then there is no worldwide best best practice ...

Just see a zone as a Trust group .... group in zone computer with same trust level.

Hope help

Re: Best practice with defining Zones - how many is too many

reaper — Thu, 11 May 2017 08:14:38 GMT

you can be pretty flexible with the amount of zones you use as long as you take into account there are 2 default rules at the end of the security policy that allow intrazone and block interzone sessions

so to prevent unchecked cross-talk, you'll want to create your own intrazone policies

Optimize Your Security Policy

Intrazone vs. interzone rules

Re: Best practice with defining Zones - how many is too many

OtakarKlier — Thu, 11 May 2017 18:25:45 GMT

Hello,

Another thing to consider is the limit on the number of zones you PAN can support. To aleviate this and still lock things down, you can use a combination, e.g. a large encompasing zone broken up into subnets. Then you will need policies to allow traffic such as the two prvious posts suggest.

Cheers!

Re: Best practice with defining Zones - how many is too many

Alex_Samad — Fri, 12 May 2017 00:19:42 GMT

I can see a zone per vlan / network, but thats a lot of zones.

Where can I find the limitation on say a pa-3060 for the number of zones ?

plus question. if I have 5 zones z1 , z2 ... z5 and then are connected in serial one after another

z1 -> z2 -> ... ->z5

if I have a packet that is coming from z5 going to zone 1 and I have a rule that says allow z1 to talk to z5 will the PA allow it through even though the next hop is z2 ?

Re: Best practice with defining Zones - how many is too many

Raido_Rattameister — Fri, 12 May 2017 00:36:48 GMT

PA3060 supports 40 zones.

https://www.paloaltonetworks.com/content/pan/en_US/products/product-comparison.html?chosen=pa-3020,pa-3060

Can you explain a bit your serial zone setup.

You need rule every time traffic moves from one zone to other.

Re: Best practice with defining Zones - how many is too many

reaper — Fri, 12 May 2017 12:03:40 GMT

I'm also wondering how you are serializing the zones 🙂

but the underlying logic is that each time a packet is received, a route lookup determines source and destination zone. the security policy will need to match those zones for it to allow the session to be created and the packets to pass through

if you're doing vsys hopping, you'd need a policy per vsys that accomodates the packet going into and coming out of 'the void' ('external' zone) between the vsys

a security policy is session-state aware, so you only need to create a policy in the direction of the syn, returning ack packets will automatically match the policy

Re: Best practice with defining Zones - how many is too many

OtakarKlier — Fri, 12 May 2017 13:44:18 GMT

Hello,

I'm not sure I did a good job of explaining what I meant in my earlier post. You can have multiple subnets within the same zone and have policies defining what traffic can pass.

i.e.

zone 1 = 10.0.0.1/24

zone 1 = 172.16.0.1/24

zone 1 = 192.168.0.1/24

Policies

zone 1 source subnet 10.0.0.1/24 can send smtp to zone 1 172.16.0.1/24 and deny all other traffic. This way the 10.0.0.1/24 zone can send smtp packets to 172.16.0.1/24 but deny packets from 192.168.0.1/24 (if these were the only policies, etc.).

While this is a highly simplified example, remember that each column in the security policies has to match. This way you can split up your zones using subnets so you dont run out :).

Re: Best practice with defining Zones - how many is too many

jsalmans — Fri, 12 May 2017 14:11:08 GMT

We do a lot of what @OtakarKlier outlined. Our security zones are defined by grouping network types. For example:

Internet

DMZ

Wifi

Residence Network

Data Center

Main Network

Load Balancers

etc.

Each actual network has a subnet and each security zone can consist of one or many networks. Rules that say "Allow traffic from Wifi security zone" would allow traffic from any network inside that zone whereas "Allow traffic from Wifi security zone if it is from subnet 192.168.1.0/24" would allow traffic only from a specific network/range in that zone.

So far it has worked out really well for us although one of my supervisors asked if we could do sub-zones... something like a "Building A" zone that belongs to the Residence Network zone. For them it is mostly about readability in the monitoring logs but I haven't seen a way to do this yet. Instead we just kind of have to know what the subnets for each building are or reference our documentation.