ASA Object Group Best Practices

[jdeisenm]

Does anyone have any thoughts on best practices for object groups. We are replaces a pix v6 with an ASA. There are several interfaces (inside, outside, dmz). I'm thinking I could have a generic service object group for windows (dns, backup, av update, backup, patch update) and another for unix (dns, syslog), one for mail (smtp). For the naming convention, i'm thinking service_interface like this "smtp_outside", "smtp_dmz", "windows_dmz", where _outside and _dmz when the services in a specific object group use the interface defined in the object group.

 

[Supergrrover]

As far as I am concerned the group objects are there to make your life convenient - so do just that. Break things into logical groups that do not overlap. Name them so you can make sense of them and in a way that is extensible so when you want to add in the future you will not have to re-name everything.
A neat feature is that you can nest groups. So use that to your advantage.



Brent
Systems Engineer / Consultant
CCNP, CCSP

 

[kmcferrin]

While you're thinking of breaking them into groups for server types, I prefer to break it down further into services. On mine I usually have a group called Web (TCP443 and TCP80), SMTP(TCP25), Windows Active Directory (a whole slew of RPC and NetBIOS related ports), BackupExec (a handful of ports that BE uses), etc. Then you can apply those objects only to the servers that need them. Because not every Windows server will need the same ports open. Same with Unix/Linux, etc.

As pointed out, you can use them however is convenient to you. But if you break it down to the services level you'll end up with the most restrictive/secure policies.