Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
CoSax
New Contributor

Object Naming convension

I have a basic question: From your experience, what would you recommend as a naming convention for the objects (hosts, networks, ports etc) in a fortigate firewall that is more practical and makes it easier later to support and resolve problems?

 

Your feedback will be appreciated!

2 Solutions
emnoc
Esteemed Contributor III

IMHO and to help in audits

 

1: name them the same as local dns

 

2: stick to all upper or lower case

 

3: try to avoid spaces

 

e.g

 

WINHOST01 AAA

vrs

WINHOST01AAA

 

4: standardize the naming convention  no matter what method you go by

 

 

e.g GEO or region or purpose

 

 

 EQXCH3WEBSRV001

 EQXNY2WEBSRV001

 EQXNY2LDAPMS001

 

 

5: Keep aware of the maximum character name value ( 63 )

 

  

 

 

 

Ken

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
Kenundrum

I will typically put the object type in the name to make it easier to distinguish what you are looking at. For example you might have an interface, vlan, and zone all named internal- so the interface would be internal, then internalVLAN, and internalZONE to separate them. I will put VIP at the end of VIPs to distinguish between the original object and the VIP to that object. Sometimes you have a VPN that connects two networks that are similar function, so i'll put VPN at the end of the vpn interface name. Address groups have group at the end to distinguish them.

To put it together in an example you have a network that just connects backup servers in two locations. You have the BackupVLAN which comprises the BackupZONE. It talks over the BackupVPN to another location. You have traffic rules that allow from BackupServersGroup in BackupZONE to BackupVPN.

It sounds redundant, but it makes it easier to distinguish things when looking at the config file since there is no icon coding there- you can easily tell if a policy is going to a vip, or address, or address group.

Definitely agree with emnoc- keep addresses to what the dns/hostnames are for individual devices both for sanity and auditing. Use the comment field to specify that it's a certain user if you want to. I also name addresses that are entire subnets something different to indicate that like servernetwork or usernetwork. 

As far as case sensitivity is concerned- the fortigate is case sensitive and Capital letters come before lowercase ones, so if you have an address item with a lowercase letter first, it will appear after all the other capitalized ones in the gui.

CISSP, NSE4

 

View solution in original post

CISSP, NSE4
6 REPLIES 6
emnoc
Esteemed Contributor III

IMHO and to help in audits

 

1: name them the same as local dns

 

2: stick to all upper or lower case

 

3: try to avoid spaces

 

e.g

 

WINHOST01 AAA

vrs

WINHOST01AAA

 

4: standardize the naming convention  no matter what method you go by

 

 

e.g GEO or region or purpose

 

 

 EQXCH3WEBSRV001

 EQXNY2WEBSRV001

 EQXNY2LDAPMS001

 

 

5: Keep aware of the maximum character name value ( 63 )

 

  

 

 

 

Ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau

6. stick to ASCII!


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
emnoc
Esteemed Contributor III

6. stick to ASCII!

 

Be cautious  of ASCII 

 

e.g

 

FGT01 (address) # edit +#@333 The string contains XSS vulnerability characters value parse error before '+#@333' Command fail. Return code -173 FGT01 (address) # edit +# The string contains XSS vulnerability characters value parse error before '+#' Command fail. Return

 

FGT01 (address) # edit #456 The string contains XSS vulnerability characters value parse error before '#456' Command fail. Return code -173

 

 

All are  ASCII but they will not work

 

;)

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
CoSax
New Contributor

thanks for the input.

How about networks, interfaces, services, vips ??

 

 

Kenundrum

I will typically put the object type in the name to make it easier to distinguish what you are looking at. For example you might have an interface, vlan, and zone all named internal- so the interface would be internal, then internalVLAN, and internalZONE to separate them. I will put VIP at the end of VIPs to distinguish between the original object and the VIP to that object. Sometimes you have a VPN that connects two networks that are similar function, so i'll put VPN at the end of the vpn interface name. Address groups have group at the end to distinguish them.

To put it together in an example you have a network that just connects backup servers in two locations. You have the BackupVLAN which comprises the BackupZONE. It talks over the BackupVPN to another location. You have traffic rules that allow from BackupServersGroup in BackupZONE to BackupVPN.

It sounds redundant, but it makes it easier to distinguish things when looking at the config file since there is no icon coding there- you can easily tell if a policy is going to a vip, or address, or address group.

Definitely agree with emnoc- keep addresses to what the dns/hostnames are for individual devices both for sanity and auditing. Use the comment field to specify that it's a certain user if you want to. I also name addresses that are entire subnets something different to indicate that like servernetwork or usernetwork. 

As far as case sensitivity is concerned- the fortigate is case sensitive and Capital letters come before lowercase ones, so if you have an address item with a lowercase letter first, it will appear after all the other capitalized ones in the gui.

CISSP, NSE4

 

CISSP, NSE4
emnoc
Esteemed Contributor III

One cool things on NAMING, you can always rename  firewall.adress and adrgp . So if you later change your format or need to bring objects into standard, it is easy todo.

 

Ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors