Best practice with defining Zones - how many is too many

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Best practice with defining Zones - how many is too many

L4 Transporter

Hi

 

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

 

 

 

8 REPLIES 8

L5 Sessionator

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

 

V.

 

 

Cyber Elite
Cyber Elite

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

 

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Cyber Elite
Cyber Elite

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!

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 ?

 

A

PA3060 supports 40 zones.

 

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

 

Can you explain a bit your serial zone setup.

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

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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 :).

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.

  • 3352 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!