This Best Practice Guideline for Fortigate is compiled from both FortiOS 5.2 and 5.4 for common issues encountered by myself and shared to everyone to ensure the most secure and reliable operation of our Fortigate units. This is updated periodically as I come across known issues and best practice recommendations.
A. General Configurations
Below are usual guidelines or considerations when setting up a fresh firewall or performing a device hardening. Always remember to save a backup copy of the running config before making any changes as any changes done to the Fortigate are committed instantly.
- Use Trusted Hosts – to allow only certain hosts or networks that can access Firewall Management.
- Use Custom Ports for Management – Dont leave the management port on the default 443 or 22, change it to some other ports like 9443 or 8222
- Enable Management Access on Interface, but limit to only one or a couple of interfaces – do not enable management to all the ports, (e.g. DMZ)
- NAT Mode vs Transparent Mode – NAT mode is the most common where the Fortigate is acting as an L3 Router, Interfaces has IP Addresses and packets are routed by IP whereas in Transparent Mode, Fortigate is OSI L2 Switch or bridge, interfaces wont have an IP Address and cannot route packets, only forwards (or drops)
- Use NTP to synchronize time on the FortiGate and the core network systems, such as email servers, web servers, and logging services
- Always configure a default route!
- Avoid traffic shaping if you need maximum performance. Traffic shaping, by definition, slows down traffic.
- Any changes on the Fortigate are applied right-away and live. Make sure to save a backup configurations before making any (major) changes.
B. System and Performance
Below are the guidelines for best practice to ensure system performance and maximum efficiency of your firewall.
- On Firewall Policies, put the most used firewall on top of the Policy list – Remember that the firewall reads the policy from top to bottom, so you can save a precious amount of time and computing resources if you will set the most commonly matched policies on top of the policies rather than at the end.
- Inspect your log settings and make sure you only log the necessary traffic – you will save computing resources and as well as log storage. Writing of logs, especially if to an internal hard disk slows down the performance.
- Make sure to enable only required application inspections
- Avoid FQDN addresses on policies if possible, unless they are internal. It can cause a performance impact on DNS queries and security impact from DNS spoofing
C. Security – Firewall Policies
- 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.
- Take advantage of the comment field to input information or management data regarding that policy.
- Avoid FQDN addresses on policies if possible, unless they are internal. (As discussed in Section B. #4)
- Outbound Traffic – Is it okay to allow all? – The answer is, it depends. Fortigate still recommend allowing only necessary INBOUND and OUTBOUND traffic. Many application use non-standard ports that can possibly be block if you limit specific ports to get to the internet. In most cases, all outbound traffic is allowed provided you enable the UTM features such as Antivirus, DLP, Antibot, Certificate-Inspection (if this wont break the connection) etc. Keep in mind also that there might be some traffic that you want to control, example if you implement a proxy server, you dont want your users to disable the proxy and still be able to get to the internet, so you would allow HTTP/HTTPS/DNS outbound to come from specific hosts only (for example, the proxy and DNS servers) so its a matter of understanding your requirment and tailor fit it with the best approach of how do you want your network to run.
- Inbound traffic – Apply IPS to the policy. Also remember to secure the access by restricting the access only to known hosts/IP Addresses, especially if it is RDP, SSH or critical applications that does need to be accessible from the general public.
- Do not use wildcards in policy. Read more details here
- 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.
- VPNs – Add blackhole routes for subnets reachable using VPN tunnels. This ensures that if a VPN tunnel goes down, traffic is not mistakingly routed to the Internet unencrypted.
- WAN Failovers – When using multiple WAN/ISPs and wish to put them on failover. Set up the Static default route for both ISPs (Provided they are static IPs). If both interfaces have the same distance, then both can pass traffic, (higher priority but if one has a higher number, that interface will be inactive and not pass traffic until the failover. The priority determines which route will be chosen first, so the lowest number will be chosen first.
- Do not enable NAT for inbound traffic unless it is required by an application. If, for example, NAT is enabled for inbound SMTP traffic, the SMTP server might act as an open relay.
F. Migrating into Fortigate
- On migrating objects and policies into Fortigate from Cisco PIX, ASA, Checkpoint or Juniper you can take advantage of the migration tool from Fortigate known as FortiConverter which can be downloaded from http://convert.fortinet.com. The Converter can securely upload and convert the policy into the Fortinet format.
G. Security – UTM
- Enable only the protocols you need to scan. If you have antivirus scans occurring on the SMTP server, or use FortiMail, it is redundant to have scanning occur on the FortiGate unit as well.
- Reduce the maximum file size to be scanned. Viruses usually travel in small files of around 1 to 2 megabytes.
H. Heartbeat interfaces / Interface Monitoring
- Configure at least two heartbeat interfaces and set these interfaces to have different priorities.
- For clusters of two FortiGate units, as much as possible, heartbeat interfaces should be directly connected using patch cables (without involving other network equipment such as switches). If switches have to be used they should
not be used for other network traffic that could flood the switches and cause heartbeat delays.
– If you cannot use a dedicated switch, the use of a dedicated VLAN can help limit the broadcast domain to protect the heartbeat traffic and the bandwidth it creates.
- Isolate heartbeat interfaces from user networks.
- Do not monitor dedicated heartbeat interfaces; monitor those interfaces whose failure should trigger a device failover.
- Avoid configuring interface monitoring for all interfaces
- Monitor interfaces connected to networks that process high priority traffic so that the cluster maintains connections to these networks if a failure occurs
If there are Best Practices that you want to share, please dont hesitate to email me so I can add it to the list.