Best practice for setting up address groups

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 for setting up address groups

L4 Transporter

Hi

 

Newbie to PA.

 

I want to create a address group dynamic (think that might be best.  made up from a group of network addresses in each DC.

 

So for example if I have 3 DC

 

dc1 - 10.1.0.0/16

dc2 - 10.2.0.0/16

dc3 - 10.3.0.0/16

 

I could tag them with "dc_network"

 

Looking at dc3 I could make that a dynamic group 

 

say 

10.3.1.0/24

10.3.10.0/24

10.3.100.0/24

10.3.110.0/24

 

with tag say dc1_networks.

 

This is where i was going to leave it but then I thought  why not enter into the address object each server for example

10.3.1.50

10.3.10.50

10.3.100.50

10.3.110.50

 

and I could tag it as dc1_servers.

 

should I be doing it this way 

 

server -> network -> dc -> company network

 

or should I stick just to network level ?

 

 

 

3 REPLIES 3

Cyber Elite
Cyber Elite

@Alex_Samad,

Personally I don't see a big advantage of user an actual address entry for a whole network. Generally you are going to know that anything within 10.1.0.0/16 is dc1 and when you start to create rules you'll inadvertably enter that in a few times without actually clicking on the address object or address group. Then you have a mixture of statically defined addresses, and then other policies that actually mention the address object. Maybe some instances have you updating whole subnets for different things but I've found these to be highly static and you'll likely never change dc1 from 10.1.0.0/16 unless you go all ipv6. 

 

The dc1_servers dynamic address group is really where I would create things like this because it makes it generally easier to manage. So if you limit the objects in this group for anything tagged dc1_servers when you decomission or add a server you simply need to worry about create the address object and tagging it correctly instead of updating all of the security policies. This also comes in handy for things like printers and things like that. 

 

Really this is all going to depend on how you actually build out your rules. I would imagine that you'll have more rules destined to secure your servers then you will with your actuall entire network address for dc1 or so on. Generally speaking though I will manually type in the network addresses instead of using my set address groups for entire networks; but when it comes to things like servers or printers I'll always use dynamic address groups simply due to the fact that they change pretty often in all of my enviroments. 

For now I think I am going to do both ... doing a trial..

 

Trying to figure out best approach to building profiles

 

I have multi env prod , sim , uat , test, demo, dev ... all with similiar security set,  I was going to use tags which would sets which would define port/protocols, so app1 can talk to app2  but only for the same environment.

 

 

L7 Applicator

Your organization model and tagging can work.  But you will need to be very careful in how you construct the actual security policy order of rules.  Since you are going to have address objects at three levels each more specific than the previous, you will need to insure that any rules are in your policy from most specific address tags to the least specific.  

 

Otherwise the more specific rules will never get used and unanticipated permits or denies will occur.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center
  • 1758 Views
  • 3 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!