Fortinet black logo

Handbook

Firewall

6.0.0
Copy Link
Copy Doc ID 4afb0436-a998-11e9-81a4-00505692583a:853096
Download PDF

Firewall

  • Be careful when disabling or deleting firewall settings. Changes that you make to the firewall configuration using the GUI or CLI are saved and activated immediately.
  • Arrange firewall policies in the policy list from more specific to more general. The firewall searches for a matching policy starting from the top of the policy list and working down. For example, a very general policy matches all connection attempts. When you create exceptions to a general policy, you must add them to the policy list above the general policy.
  • Avoid using the All selection for the source and destination addresses. Use addresses or address groups.
  • If you remove all policies from the firewall, there are no policy matches and all connections are dropped.
  • If possible, avoid port ranges on services for security reasons.
  • The settings for a firewall policy should be as specific as possible. Do not use 0.0.0.0 as an address. Do not use Any as a service. Use subnets or specific IP addresses for source and destination addresses and use individual services or service groups.
  • Use a 32-bit subnet mask when creating a single host address (for example, 255.255.255.255).
  • Use logging on a policy only when necessary and be aware of the performance impact. For example, you may want to log all dropped connections but can choose to use this sparingly by sampling traffic data rather than have it continually storing log information you may not use.
  • It is possible to use security policies based on 'any' interface. However, for better granularity and stricter security, explicit interfaces are recommended.
  • Use the comment field to input management data, for example: who requested the rule, who authorized it, etc.
  • Avoid FQDN addresses if possible, unless they are internal. It can cause a performance impact on DNS queries and security impact from DNS spoofing.
  • For non vlan interfaces, use zones (even if you have only one single interface for members) to allow:
  • An explicit name of the interface to use in security policies ('internal' is more explicit than 'port10').
  • A split between the physical port and its function to allow port remapping (for instance moving from a 1G interface to a 10G interface) or to facilitate configuration translation, as performed during hardware upgrades.

Firewall

  • Be careful when disabling or deleting firewall settings. Changes that you make to the firewall configuration using the GUI or CLI are saved and activated immediately.
  • Arrange firewall policies in the policy list from more specific to more general. The firewall searches for a matching policy starting from the top of the policy list and working down. For example, a very general policy matches all connection attempts. When you create exceptions to a general policy, you must add them to the policy list above the general policy.
  • Avoid using the All selection for the source and destination addresses. Use addresses or address groups.
  • If you remove all policies from the firewall, there are no policy matches and all connections are dropped.
  • If possible, avoid port ranges on services for security reasons.
  • The settings for a firewall policy should be as specific as possible. Do not use 0.0.0.0 as an address. Do not use Any as a service. Use subnets or specific IP addresses for source and destination addresses and use individual services or service groups.
  • Use a 32-bit subnet mask when creating a single host address (for example, 255.255.255.255).
  • Use logging on a policy only when necessary and be aware of the performance impact. For example, you may want to log all dropped connections but can choose to use this sparingly by sampling traffic data rather than have it continually storing log information you may not use.
  • It is possible to use security policies based on 'any' interface. However, for better granularity and stricter security, explicit interfaces are recommended.
  • Use the comment field to input management data, for example: who requested the rule, who authorized it, etc.
  • Avoid FQDN addresses if possible, unless they are internal. It can cause a performance impact on DNS queries and security impact from DNS spoofing.
  • For non vlan interfaces, use zones (even if you have only one single interface for members) to allow:
  • An explicit name of the interface to use in security policies ('internal' is more explicit than 'port10').
  • A split between the physical port and its function to allow port remapping (for instance moving from a 1G interface to a 10G interface) or to facilitate configuration translation, as performed during hardware upgrades.