25 March 2011

TMG rule maintenance optimisastion and organising tips

In a previous article http://fixmyitsystem.com/2010/11/tmg-rule-organising-enhancements.html I covered how to organise your rules so that they are easier to manage.  What becomes inevitable is that some of your rules become stale or unused.  Some of these might even be created in a trouble shoot or testing situations and then be forgotten about.

Naming convention
Everyone has an opinion as to how this should be done.  I am gong to tell you how I do mine and maybe there is some useful.

If we look at the firewall policy screen there is a nice rich environment that show you at a glance what is configured.  The columns are:


  • Order - containing indicative icon
  • Name - free text field
  • Action - containing Allow or Deny icon
  • Protocols -  populated by all the applicable protocols with a generic icon and text description
  • From / Listener - Contains the existing name of the network object
  • TO - Contains the existing name of the network object
  • Condition - Might as well be called users
  • Description - the most often neglected field
  • Policy - This could also have been called the policy scope and is either System Array or Enterprise.




The only fields you can actually change or have control over is

Name
Using the name you can put a lot of information into it.  This can come on very useful when doing log analysis.
Remember that all the nice GUI stuff from the firewall policy screen are not available anywhere else in logs.  So it may seem redundant to call a rule Allow xxx whenre there is an icon indicating this, but it is not.

As an example if you are using log and report and want to create a filter based on a rule, you will only see the rule name. By following a function based naming convention you can quickly figure out what the rules are and do.


I use the following function names:


  • Allow
  • Deny
  • Deny Redirect
  • Publish
  • Publish NLB
  • Allow VPN
  • Deny VPN


To indicate that a rule is temporary for trouble shooting or testing I prefix the rule name with "!"  This allows you to stick to the naming convention and easily distinguish the temporary ones.  And when this becomes a permanent rule it is a quick change.

From / Listener
When creating a listener I normally stick to assigning a single IP per listener, for various reasons.  I therefor like to name my listener in the following manner.

IP - Application name  eg. 192.100.3.33 - Exchange 2010 listener

In my case I find this very useful because this then brings up the affected IP address in the firewall policy screen.  Another advantage is if i am looking for a free IP or need to add another NLB i can quickly see what is and what is not being used.

To
This field is not as customisable as I would like but it can still be very useful.  Normally this would contain the network object name such as:

  • Networks
  • Computers
  • URL Sets
  • Server Farms

When creating these object using a sensible name can make a big difference.  as an example if you are creating a web server farm I like to use the following format:

NLB - Application name  eg. NLB - Sharepoint Head Office

Condition
Naming User group with enough information can make it very simple to administer.  I have been around the block a few time on this one and have finally settled on matching the corresponding Active Directory group.

Description
Here you can go into loads of details as to that the purpose and point of the rule is.  If your naming convention is done correctly you should not need to put much information in here.  TMG be default has change tracking,  but another very useful bit you can do with the description filed is to keep relevant change or request numbers with dates. Since rules can live for years it is a nice addition for the change tracking system.

Maintenance
I find using the naming convention helps me maintain the rule set much easier.  I can easily spot or search for temporary rules.  I can then use these in a logs and reports filter to see if it was used within the last 7 or 30 days.


For more in depth rule maintenance you might want to use a 3rd party log analyser.  I use Webspy for various reasons.  But even here you can see how a good organising of names and object can refine information much easier.


If you have your own take on this or maybe have some additional tips or recommendations please put hem in a comment .

No comments:

Post a Comment