Fortinet Document Library

Version:

Version:


Table of Contents

Download PDF
Copy Link

Policies

The FortiGate's primary role is to secure your network and data from external threats. It accomplishes this using policies and security profiles. Policies control what kind of traffic is allowed where, and security profiles define what to look for in the traffic.

FortiGate also has an NGFW mode in which you can allow applications and URL categories directly in the policies, and do not need to define security profiles.

Use the different policy types to secure the different types of traffic that the FortiGate processes.

DoS policies

DoS policies are checked before security policies to prevent attacks from overwhelming your network and FortiGate by triggering more resource intensive security protection. These policies should be adjusted based on your business traffic rates (see Performance monitoring).

Local-in policies

Local-in policies control access to the FortiGate interfaces. They are often used to block unauthorized access to management ports or other well known ports, and to limit access from specific sources. They should be used to further enable or restrict access to the FortiGate based on your security requirements.

Note that extra care should be taken when configuring a local-in policy, as an incorrect configuration could inadvertently deny traffic for SSL VPN, dynamic routing protocols, HA, and other FortiGate features.

Security policies
  • Security policies control the flow of traffic and the security features that are applied to the traffic flow. They are the most commonly used policy type.

  • Each policy should have a unique name and there should not be any unused policies.

  • Policies that allow traffic should apply to a specific interface, and not the any interface.

  • Only the security profiles that are necessary for the traffic matching policy should be enabled.

  • Security policies are evaluated in order. When traffic matches a policy, further policies are not processed. Put the most specific policies at the top of the list, and follow the least privilege access principle.

  • Interface aliases

    • It might not be possible to use the same interface on each FortiGate for the same function. Add aliases to the interfaces so that policies are easier to understand. For example, a policy that controls traffic between you network and your phones switch is clearer if it shows LAN to Phones, instead of port4 to port2.

  • Zones

    • Zones are used to group multiple interfaces or subinterfaces into a single interface object that can be used in policies.

    • Grouping interfaces and VLAN subinterfaces into zones simplifies security policy creation by allowing multiple network segments to use the same policy settings and protection profiles.

    • Interfaces in a zone can also still be used individually and still route normally.

  • Policies

    • Put the most specific, or narrow, policies at the top of the policy list.

    • Do not use the all or any objects in a policy, except when routing to the internet.

    • Do not override the implicit deny policy.

    • Use users in policies. This makes the policy more specific and reduces the chances of unintended traffic matching.

Policies

The FortiGate's primary role is to secure your network and data from external threats. It accomplishes this using policies and security profiles. Policies control what kind of traffic is allowed where, and security profiles define what to look for in the traffic.

FortiGate also has an NGFW mode in which you can allow applications and URL categories directly in the policies, and do not need to define security profiles.

Use the different policy types to secure the different types of traffic that the FortiGate processes.

DoS policies

DoS policies are checked before security policies to prevent attacks from overwhelming your network and FortiGate by triggering more resource intensive security protection. These policies should be adjusted based on your business traffic rates (see Performance monitoring).

Local-in policies

Local-in policies control access to the FortiGate interfaces. They are often used to block unauthorized access to management ports or other well known ports, and to limit access from specific sources. They should be used to further enable or restrict access to the FortiGate based on your security requirements.

Note that extra care should be taken when configuring a local-in policy, as an incorrect configuration could inadvertently deny traffic for SSL VPN, dynamic routing protocols, HA, and other FortiGate features.

Security policies
  • Security policies control the flow of traffic and the security features that are applied to the traffic flow. They are the most commonly used policy type.

  • Each policy should have a unique name and there should not be any unused policies.

  • Policies that allow traffic should apply to a specific interface, and not the any interface.

  • Only the security profiles that are necessary for the traffic matching policy should be enabled.

  • Security policies are evaluated in order. When traffic matches a policy, further policies are not processed. Put the most specific policies at the top of the list, and follow the least privilege access principle.

  • Interface aliases

    • It might not be possible to use the same interface on each FortiGate for the same function. Add aliases to the interfaces so that policies are easier to understand. For example, a policy that controls traffic between you network and your phones switch is clearer if it shows LAN to Phones, instead of port4 to port2.

  • Zones

    • Zones are used to group multiple interfaces or subinterfaces into a single interface object that can be used in policies.

    • Grouping interfaces and VLAN subinterfaces into zones simplifies security policy creation by allowing multiple network segments to use the same policy settings and protection profiles.

    • Interfaces in a zone can also still be used individually and still route normally.

  • Policies

    • Put the most specific, or narrow, policies at the top of the policy list.

    • Do not use the all or any objects in a policy, except when routing to the internet.

    • Do not override the implicit deny policy.

    • Use users in policies. This makes the policy more specific and reduces the chances of unintended traffic matching.