FGCP High Availability

Fortinet suggests the following practices related to high availability:

• Use Active-Active HA to distribute TCP and UTM sessions among multiple cluster units. An active-active cluster may have higher throughput than a standalone FortiGate unit or than an active-passive cluster.
• Use a different host name on each FortiGate unit when configuring an HA cluster. Fewer steps are required to add host names to each cluster unit before configuring HA and forming a cluster.
• Consider adding an Alias to the interfaces used for the HA heartbeat so that you always get a reminder about what these interfaces are being used for.
• Enabling load-balance-all can increase device and network load since more traffic is load-balanced. This may be appropriate for use in a deployment using the firewall capabilities of the FortiGate unit and IPS but no other content inspection.
• An advantage of using session pickup is that non-content inspection sessions will be picked up by the new primary unit after a failover. The disadvantage is that the cluster generates more heartbeat traffic to support session pickup as a larger portion of the session table must be synchronized. Session pickup should be configured only when required and is not recommended for use with SOHO FortiGate models. Session pickup should only be used if the primary heartbeat link is dedicated (otherwise the additional HA heartbeat traffic could affect network performance).
• If session pickup is not selected, after a device or link failover all sessions are briefly interrupted and must be reestablished at the application level after the cluster renegotiates. For example, after a failover, users browsing the web can just refresh their browsers to resume browsing. Users downloading large files may have to restart their download after a failover. Other protocols may experience data loss and some protocols may require sessions to be manually restarted. For example, a user downloading files with FTP may have to either restart downloads or restart their FTP client.
• If you need to enable session pickup, consider enabling session-pickup-delay to improve performance by reducing the number of sessions that are synchronized. See Improving session synchronization performance on page 1.
• Consider using the session-sync-dev option to move session synchronization traffic off the HA heartbeat link to one or more dedicated session synchronization interfaces. See Improving session synchronization performance on page 1.
• To avoid unpredictable results, when you connect a switch to multiple redundant or aggregate interfaces in an active-passive cluster you should configure separate redundant or aggregate interfaces on the switch; one for each cluster unit.
• Use SNMP, syslog, or email alerts to monitor a cluster for failover messages. Alert messages about cluster failovers may help find and diagnose network problems quickly and efficiently.

Heartbeat interfaces

Fortinet suggests the following practices related to heartbeat interfaces:

• 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.
• For clusters of three or four FortiGate units, use switches to connect heartbeat interfaces. The corresponding heartbeat interface of each FortiGate unit in the cluster must be connected to the same switch. For improved redundancy use a different switch for each heartbeat interface. In that way if the switch connecting one of the heartbeat interfaces fails or is unplugged, heartbeat traffic can continue on the other heartbeat interfaces and switch.
• Isolate heartbeat interfaces from user networks. Heartbeat packets contain sensitive cluster configuration information and can consume a considerable amount of network bandwidth. If the cluster consists of two FortiGate units, connect the heartbeat interfaces directly using a crossover cable or a regular Ethernet cable. For clusters with more than two units, connect heartbeat interfaces to a separate switch that is not connected to any network.
• If heartbeat traffic cannot be isolated from user networks, enable heartbeat message encryption and authentication to protect cluster information. See Enabling or disabling HA heartbeat encryption and authentication on page 1.
• Configure and connect redundant heartbeat interfaces so that if one heartbeat interface fails or becomes disconnected, HA heartbeat traffic can continue to be transmitted using the backup heartbeat interface. If heartbeat communication fails, all cluster members will think they are the primary unit resulting in multiple devices on the network with the same IP addresses and MAC addresses (condition referred to as Split Brain) and communication will be disrupted until heartbeat communication can be reestablished.
• Do not monitor dedicated heartbeat interfaces; monitor those interfaces whose failure should trigger a device failover.
• Where possible at least one heartbeat interface should not be connected to an NP4 or NP6 processor to avoid NP4 or NP6-related problems from affecting heartbeat traffic.
• Where possible, the heartbeat interfaces should not be connected to an NP4 or NP6 processor that is also processing network traffic.
• Where possible, each heartbeat interface should be connected to a different NP4 or NP6 processor.
• Any FortiGate interface can be used as a heartbeat interface including 10/100/1000Base-T, SFP, QSFP fiber and copper, and so on. If you set up two or more interfaces as heartbeat interfaces each interface can be a different type and speed.

Interface monitoring (port monitoring)

Fortinet suggests the following practices related to interface monitoring (also called port monitoring):

• Wait until a cluster is up and running and all interfaces are connected before enabling interface monitoring. A monitored interface can easily become disconnected during initial setup and cause failovers to occur before the cluster is fully configured and tested.
• Monitor interfaces connected to networks that process high priority traffic so that the cluster maintains connections to these networks if a failure occurs.
• Avoid configuring interface monitoring for all interfaces.

Supplement interface monitoring with remote link failover. Configure remote link failover to maintain packet flow if a link not directly connected to a cluster unit (for example, between a switch connected to a cluster interface and the network) fails.

Networking

When configuring your network, ensure that there is no ‘back door’ access to the protected network. For example, if there is a wireless access point, it must be appropriately protected with password and encryption.

Be sure to also maintain an up-to-date network diagram which includes IP addressing, cabling, and network elements.

Routing configuration

• Always configure a default route.
• 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.

Policy routing

Keep the number of policy routes to a minimum to optimize performance in route lookup and to simplify troubleshooting.

Dynamic routing

l Select a Router ID that matches an IP assigned to an interface. This avoids the likelihood of having two devices with the same router ID. l For routing over an IPsec tunnel, assign IP addresses to both ends of the tunnel.

Advanced routing

Use the following best practices for advanced routing when dealing with Border Gateway Protocol (BGP) and Open Shortest Path First (OSPF).

Border Gateway Protocol (BGP)

If you are using BGP, it is recommended that you enable soft-reconfiguration. This has two benefits:

l It allows you to perform ‘soft clear’ of peers after a change is made to a BGP policy. l It provides greater visibility into the specific prefixes learned from each neighbor.

Leave soft-reconfiguration disabled if your FortiGate does not have much unused memory. Soft-reconfiguration requires keeping separate copies of prefixes received and advertised, in addition to the local BGP database.

Open Shortest Path First (OSPF)

• Avoid use of passive interfaces wherever possible. l Avoid use of virtual links to connect areas. All areas should be designed to connect directly to the backbone area.
• Ensure that all backbone routers have a minimum of two peering connections to other backbone neighbors. l An entire OSPF domain should be under common administration.

Network Address Translation (NAT)

• Beware of misconfiguring the IP Pool range. Double-check the start and end IPs of each IP pool. The IP pool should not overlap with addresses assigned to FortiGate interfaces or to any hosts on directly connected networks.
• If you have internal and external users accessing the same servers, use split DNS to offer an internal IP to internal users so that they don’t have to use the external-facing VIP.

Configuring NAT

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.

Transparent Mode

• Do not connect two ports to the same VLAN on a switch or to the same hub. Some Layer 2 switches become unstable when they detect the same MAC address originating on more than one switch interface or from more than one VLAN.
• If you operate multiple VLANs on your FortiGate unit, assign each VLAN id to its own forwarding domain to ensure that the scope of the broadcast does not extend beyond the VLAN it originated in.

To protect against Layer 2 loops:

• Enable stpforward on all interfaces. l Use separate VDOMs for production traffic (TP mode VDOM) and management traffic (NAT/Route mode VDOM).
• Only place those interfaces used for production in the TP mode VDOM. Place all other interfaces in the NAT/Route mode VDOM. This protects against potential Layer 2 loops.

Using Virtual IPs (VIPs)

• Use the external IP of 0.0.0.0 when creating a VIP for a FortiGate unit where the external interface IP address is dynamically assigned.
• Be sure to select the correct external interface when creating a new virtual IP (VIP). The external interface should be set to the interface at which the FortiGate unit receives connection requests from external networks.

Web filtering

FortiGuard Web Filtering can help stop infections from malware sites and help prevent communication if an infection occurs.

• Enable FortiGuard Web Filtering at the network edge. l Install the FortiClient application and use FortiGuard Web Filtering on any systems that bypass your FortiGate unit.
• Block categories such as Pornography, Malware, Spyware, and Phishing. These categories are more likely to be dangerous

Patch management

When vulnerabilities are discovered in software, the software vendors release updates that fix these problems. Keeping your software and operating system up-to-date is a vital step to prevent infection and defend against attacks.

• Follow the latest advisories and reports on the FortiGuard webpage. l Apply updates to all software as the updates become available.
• FortiGuard Vulnerability Management can help identify security weaknesses in your network. This subscription service is available through FortiScan and FortiAnalyzer units.
• Apply firmware updates to your FortiGate unit as they are released.
• Subscribe to FortiGuard AntiVirus and IPS services, so that AntiVirus and IPS scanning engines are automatically updated when new version are released.

Policy configuration

Configuring the FortiGate unit with an ‘allow all’ traffic policy is very undesirable. While this does greatly simplify the configuration, it is less secure. As a security measure, it is best practice for the policy rulebase to ‘deny’ by default, and not the other way around.

Policy configuration changes

On a heavy-loaded system, plan configuration changes during low usage periods in order to minimize impact on CPU usage and established sessions. In this scenario, it is considered a best practice to de-accelerate the hardware-accelerated sessions.

You can configure de-accelerated behaviour on hardware-accelerated sessions using CLI commands to control how the processor manages policy configuration changes. The following CLI commands are to be used:

config system settings set firewall-session-dirty { check-all | check-new | check-policy-option }

end where you want the following to be true:

Policy whitelisting

• Allow only the necessary inbound and outbound traffic.
• If possible, limit traffic to specific addresses or subnets. This allows the FortiGate unit to drop traffic to and from unexpected addresses.

IPS and DoS policies

• Because it is critical to guard against attacks on services that you make available to the public, configure IPS signatures to block matching signatures. For example, if you have a web server, configure the action of web server signatures to Block.
• Your FortiGate unit includes IPS signatures written to protect specific software titles from DoS attacks. Enable the signatures for the software you have installed and set the signature action to Block.
• DoS attacks are launched against vulnerabilities. Maintain a FortiGuard IPS subscription to ensure your FortiGate unit automatically receives new and updated IPS signatures as they are released.
• Use and configure DoS policies to appropriate levels based on your network traffic and topology. This will help drop traffic if an abnormal amount is received. The key is to set a good threshold. The threshold defines the maximum Patch management Policy configuration

number of sessions/packets per second of normal traffic. If the threshold is exceeded, the action is triggered. Threshold defaults are general recommendations, but your network may require very different values. One way to find the correct values for your environment is to set the action to Pass and enable logging. Observe the logs and adjust the threshold values until you can determine the value at which normal traffic begins to generate attack reports. Set the threshold above this value with the margin you want. Note that the smaller the margin, the more protected your system will be from DoS attacks, but your system will also be more likely to generate false alarms.

Email filter

Spam is a common means by which attacks are delivered. Users often open email attachments they should not, and infect their own machine.

l Enable email filtering at the network edge for all types of email traffic. l Use FortiClient endpoint IPS scanning for protection against threats that get into your network. l Subscribe to the FortiGuard AntiSpam Service.

amURL filtering

Best practices for URL filtering can be divided into four categories: flow-based versus proxy based filtering; local category/rating feature; URL filter ‘Exempt’ action; and Deep Scan.

Flow-based versus proxy-based

Try to avoid mixing flow-based and proxy-based features in the same profile if you are not using IPS or Application Control.

Local category/rating feature

Local categories and local rating features consume a large amount of CPU resources, so use these features as little as possible. It is better to use Local categories instead of using the ‘override’ feature, since the ‘override’ feature is more complicated and more difficult to troubleshoot.

URL filter ‘Exempt’ action

When using the URL filter ‘Exempt’ option,webfilter, antivirus and dlp scans are bypassed by default, so use this option only for trusted sites.

Configuration notes: You need to configure ‘Exempt’ actions in the URL filter if you want to bypass the FortiGuard Web Filter.You can configure which particular inspection(s) you want to bypass using the set exempt command in config webfilter urlfilter.

Deep Scan

The ‘Deep Scan’ feature is much heavier on resources than ‘HTTPS URL Scan Only’. Deep Scan is much more accurate, since many sites (such as various Google applications) cannot be scanned separately without deep scanning enabled.

Note: If you configure Deep Scan in the SSL profile and then configure ‘Enable HTTPS URL Scan Only’ in the web filter profile, then Deep Scan is not performed.

Backing up a configuration file using SCP

You can use secure copy protocol (SCP) to download the configuration file from the FortiGate unit as an alternative method of backing up the configuration file or an individual VDOM configuration file. This is done by enabling SCP for and administrator account and enabling SSH on a port used by the SCP client application to connect to the FortiGate unit. SCP is enabled using the CLI commands:

config system global set admin-scp enable

end

Use the same commands to backup a VDOM configuration by first entering the commands:

config global set admin-scp enable end

Performing a configuration backup

Once you configure the FortiGate unit and it is working correctly, it is extremely important that you backup the configuration. In some cases, you may need to reset the FortiGate unit to factory defaults or perform a TFTP upload of the firmware, which will erase the existing configuration. In these instances, the configuration on the device will have to be recreated, unless a backup can be used to restore it.

It is also recommended that once any further changes are made that you backup the configuration immediately, to ensure you have the most current configuration available. Also, ensure you backup the configuration before upgrading the FortiGate unit’s firmware. Should anything happen during the upgrade that changes the configuration, you can easily restore the saved configuration.

Always backup the configuration and store it on the management computer or off-site. You have the option to save the configuration file to various locations including the local PC, USB key, FTP and TFTP site.The latter two are configurable through the CLI only.

If you have VDOMs, you can back up the configuration of the entire FortiGate unit or only a specific VDOM. Note that if you are using FortiManager or FortiCloud, full backups are performed and the option to backup individual VDOMs will not appear.

To back up the FortiGate configuration – web-based manager:

1. Go to Dashboard.
2. On the System Information widget, select Backup next to System Configuration.
3. Select to backup to your Local PC or to a USB Disk.

The USB Disk option will be grayed out if no USB drive is inserted in the USB port. You can also backup to the FortiManager using the CLI.

4. If VDOMs are enabled, select to backup the entire FortiGate configuration (Full Config) or only a specific VDOM configuration (VDOM Config).
5. If backing up a VDOM configuration, select the VDOM name from the list.
6. Select Encrypt configuration file.

Encryption must be enabled on the backup file to back up VPN certificates.

7. Enter a password and enter it again to confirm it. You will need this password to restore the file.
8. Select Backup.
9. The web browser will prompt you for a location to save the configuration file. The configuration file will have a .conf extension.

To back up the FortiGate configuration – CLI:

execute backup config management-station <comment>

… or …

execute backup config usb <backup_filename> [<backup_password>]

… or for FTP (note that port number, username are optional depending on the FTP site)…

execute backup config ftp <backup_filename> <ftp_server> [<port>] [<user_name>] [<password>]

… or for TFTP … execute backup config tftp <backup_filename> <tftp_servers> <password>

Use the same commands to backup a VDOM configuration by first entering the commands:

config vdom edit <vdom_name>