Packet Goes Where? The Value of Firewall Naming Conventions

by andrew.plato

UTM / NGFW
3 comments
Packet Goes Where? The Value of Firewall Naming Conventions - Anitian

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. This is where having a standard Firewall rule naming convention scheme can come in handy.

Firewall Rule Naming Convention Scheme and Best Practices

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 Firewall Rule Naming Conventions

<country>.<location>.<context>.<type>.<name>

  • 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.
Convention Description Example
int Internal network int.host.mail.cluster
ext External or public Internet ext.net.fedline
dmz DMZ network dmz.net.homebanking
wifi Wireless network wifi.net.guests
cde Cardholder data environment (for PCI compliance) cde.host.payment.server
vpn VPN network us.boston.vpn.net.all
part Partner network part.net.visa
vlan VLAN network us.dallas.vlan.30.storage
adm Administration admin.net.ips
ha High availability network ha.net.firewalls

 

  • Type:  The type of object:
Type Convention Description Example
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 Firewall Naming Conventions

<type>.<port>.<name>

  • Type:  The protocol type. Such as TCP, UDP, ICMP
  • Port:  The relevant port (if there is one)
  • Name: A meaningful name for the service.
  • Examples:
    TCP.10443.ssl-vpn
    UDP.8099.backups
    TCP.10500-10510.device.monitoring

How to use Comment fields for Firewall Best Practices

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:

  1. Date and time rule was created
  2. Original author of rule
  3. Description or rationale for rule

 

Conclusion

Using these conventions, you can document your firewall rules in a manner that 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. Anitian SecureCloud for compliance automation and enterprise security solutions makes your path to compliance fast and simple.

It may also get rid of lice. But no promises there.

 

3 thoughts on “Packet Goes Where? The Value of Firewall Naming Conventions”

Leave a Reply