Skip to main content
ronnie_jorgensen
ronnie_jorgensen
New Member
July 24, 2020
Solved

After some firewall policy advice

  • July 24, 2020
  • 1 reply
  • 4717 views

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

      • Best answer by ede_pfau

      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.

      1 reply

      rwpatterson
      rwpatterson
      New Member
      July 24, 2020

      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
      emnoc
      New Member
      July 24, 2020

      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
      SuperUser
      ede_pfauAnswer
      SuperUser
      July 24, 2020

      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.

      Terms & ConditionsAccessibility statement