After some firewall policy advice

[ronnie_jorgensen]

Hi all,

I have worked with the Fortigate firewalls now for about 2 years in my current role, but I do not consider myself a firewall person at all.

I seem to struggle to come up with a good naming scheme for my policies and also how to best create policies so:

[ol]

We dont have tons of policies

easier to find the policy you are after[/ol]

So we have policies named like "SiteA to SiteB" allowing all services and from and to has 2 different subnets

Or we have "Allow AD,DNS,NTP from DMZ to LAN"  with services "Windows AD" + "NTP" from the DMZ subnet to 2 specific domain controllers.

But we also have policies named "SiteA Server Lan to Datacentre" which has 4 VLAN interfaces in the from field and 1 VPN tunnel in the To field. The problem i seem to have is coming up with a consistent naming format for my policies and we we seem to mix in regards to creating 1 policy per thing either "SiteA to SiteB" or "Allow SMTP for Server1 to Exchange".

[ul]

How do you name your policies?

Do you create one policy for access to Exchange server and add multiple from and source into that or individual policies for each from interface? (interface, vlan, vpn tunnels)[/ul]

I think it makes sense to me that access to services like AD, NTP, DNS, Exchange could be done from subnets rather than individual servers.

Thx in advance

[rwpatterson]

For the most part it doesn't matter as long as it is easy for you to read. The only reason to group or split in my opinion would be if were interested in monitoring traffic individually or don't care and dump all AD bound traffic together. To each, their own I guess is what I'm getting at. Both get the job done and if you don't have a ton of policies it's not an issue either way. This is more about grouping than naming but it may help your query.

[emnoc]

FWIW I don't use names. If I want to find the policyid I look at the src and|or dst address and comments if I use that. The same for other firewall vendor I work with also, I almost never look for names, typically I search on the destination 1st than src 2nd.

One tip, I started doing approx 5 years back is firewall policy and address address.groups can be tag. If you tag by dept,function,etc... you can easily audit policy by tag type. So build tag or as many tags as you need

example of a recent tag convention we deployed

tag=vcenter

tag=hr

tag=mail_sys

tag=outside_vendor

tag=sso

tag=azure

tag=aws

tag=vpn_ssl

tag=vpn_ipsec

tag=gcp

tag=aaa

tag=san_primary

tag=san_secondary

tag=bio

tag=camera_interior

tag=camera_exterior

tag=guest_access

tag=ftp-servers

tag=epo

I found doing  this and then searching by tag type is much easier to locate what you looking for 

You get the picture and then you apply the tag in the policy when you 1st build it. 

Another option is  to reserve policy id range and when you build policyid from ci you edit that next available number in that.

So we have something like 1-99, 100-199,200-299, and so on and in 1-99 you might use these for all internal dc-vlan, 100 hundred range for external mail, 200 range sql related.

So if you don't expect more than a hundred policy in those range that might work also.

Ken Felix

[ede_pfau · Accepted solution]

To each his own...that applies to naming conventions here as well as for other fields of daily life.

One thing is, I do not use the word "allow" in policy names. In 99% of cases a policy allows traffic, and if it doesn't, I use "DENY" in the name, just to make it stand out.

When a policy table is growing the most often used tool is the search box. If your interface names are not specific enough, you should use keywords in your policy names. The goal is to find the right policy, or all policies involved, as quick as possible. Using tags is another way of getting keywords into it, though I don't use them yet - I would have to think of tags before using them. I get away with keywords in names (policies, addresses, groups) pretty well even with 200+ policies.

I made it a habit to strictly avoid multi-interface policies. With the "Bytes" field, I can immediately see which interface pairs carry traffic, and more importantly, which do not. To avoid more work, I use scripting a lot, with a simple text editor (OK, it offers regex search&replace). These config snippets are either copied in via ssh/CLI, or using the script import function in GUI.

If I really have quite a number of similarily treated interfaces (say, VPN tunnels), I create a zone and use that in policies. You can still control single traffic streams when using zones, just by selecting the source/destination address.

HTH.