A zillion or so years ago, humans developed writing. This was a big deal for civilization. People could document things like how to get rid of lice, defend castles from Huns and which berries are toxic. Civilization would have quickly succumbed to lice, toxic berries and Huns were it not for the foresight of learned scholars to document knowledge in a manner that other humans could understand.
Somehow this wisdom of the ancient world has been completely lost upon firewall administrators.
There is nothing more irritating, time consuming and problematic than trying to decipher the byzantine logic of firewall object names. I am sure it all makes sense to the original psychotic lunatic who installed the firewall. For the rest of us, it makes no sense whatsoever.
Unless you plan to manage the firewall forever (and happen to be immortal), you need to document the firewall rules.
Firewall naming conventions go a long way to helping understand your controls, as well as organizing them. Most modern firewalls support complex names with spaces, periods, underscores, etc. With a little discipline and a standard, you can make your rule set comprehensible to other people.
While any convention is better than none, Anitian has developed our own convention scheme. Naturally, you may want to adapt these for your own needs.
Address Object Convention
- Country (Optional). The country where the item is located. This can be dropped for single country enterprises.
- Location (Optional): The city or location name of the object. This is expressed as office name or city. However for smaller networks, in one physical location, this element can be dropped.
- Context: The location of the object in context to the enterprise. This is an important field as it defines a class or category of object types. Customize these to suit your enterprise.
|ext||External or public Internet||ext.net.fedline|
|cde||Cardholder data environment (for PCI compliance)||cde.host.payment.server|
|ha||High availability network||ha.net.firewalls|
- Type: The type of object:
|net||Network||An entire network or subnet.||dmz.net.wifi|
|grp||Group||A group or range of addresses or networks.||int.grp.mailservers|
|host||Single host or server.||A single IP address, this would be used to identify something other than a meaningful host.||dmz.host.router|
|srv||Server||An alternate for host, useful for separating server hosts from workstations or other hosts.||Int.srv.dc-01|
|user||User||A specific user object||int.usr.aplato|
|usrgrp||User Group||A group of users||int.usg.itadmins|
|fqdn||Fully qualified domain name||The full domain name for a host.||ext.fqdn.mcafee.updates|
- Name: A meaningful name for the object that describes the object. This can contain multiple words each word should be separated by a period. The name should be clear and make sense to another person managing the firewall.
Service Object Convention
- Type: The protocol type. Such as TCP, UDP, ICMP
- Port: The relevant port (if there is one)
- Name: A meaningful name for the service.
Many firewalls also have Comment fields attached to each rule. These are also useful to explain a rule and provide more detail. Things you should document in the comments field include:
- Date and time rule was created
- Original author of rule
- Description or rationale for rule
Using these conventions, you can document your firewall rules in a manner which may actually communicate to other people. This is not only required for some regulations (like PCI) but it also is widely accepted best practice. Moreover, when the time comes to upgrade to a new firewall, or audit the rules, this information will make the auditing process a lot smoother.
It may also get rid of lice. But no promises there.