Management Network

Should be independent from production or business traffic, it does not have to compete for resources and management access can be maintained when reconfiguring the production network.

Policies

By utilizing a management interface, the separation of management and production traffic is facilitated, enabling distinct policies tailored for specific purposes. This approach enhances the ease of comprehension and troubleshooting of policies.

Security

When network devices have their management access on a separate network, it becomes more challenging to access them on the production network.

To streamline administrative access, it is recommended to have a dedicated single interface or VLAN interface in the management network. This specific interface should be solely used for all administrative tasks, while administrative access should be disabled on all other interfaces.

User authentication for management network access

Controlling who can access the FortiGate, and what permission they have, is integral to the security of your network.

Who may access the FortiGate

There are two ways for users to log in to the FortiGate: either by authenticating locally with the FortiGate itself or by using a remote access server integrated with the FortiGate, such as LDAP or RADIUS servers.

For local accounts on the FortiGate, it is important to establish a password policy that ensures a minimum level of complexity.

Remote authentication servers have their own password policies in place and offer additional configuration options. For instance, you can utilize pre-defined security groups to grant access to specific user groups. If an administrator’s access needs to be revoked, disabling their account on the remote access server will prevent them from logging in to the FortiGate.

It is strongly advised not to use shared accounts for accessing the FortiGate. Shared accounts are more susceptible to compromise, pose difficulties in managing password updates for all users, and hinder the ability to audit access to the FortiGate.

Apart from GUI and CLI administration accounts, the FortiGate can also be managed through API calls by API users. These API users are required to generate authorization tokens for REST API messages. If the FortiGate is managed by running scripts over SSH, it is recommended to authenticate users using certificates instead of storing and maintaining passwords in the application that establishes the SSH connection.

What can administrators access

To minimize potential attack vectors, it is essential to restrict an administrator’s access to only the features and functions necessary for their specific responsibilities. The access profile associated with the user account determines the areas within the FortiGate that the administrator can access and the actions they can perform within those areas. Regularly auditing the list of users with access is crucial to ensure its accuracy and currency.

How can users access the FortiGate

To enhance the security of the FortiGate, it is recommended to restrict access solely to a management interface within a designated management network. Additionally, trusted hosts can be utilized to specify specific IP addresses or subnets that are permitted to log in to the FortiGate.

To further fortify the authentication process, it is crucial to implement multi-factor authentication (MFA) when logging in to the FortiGate. MFA significantly increases the difficulty for potential attackers to gain unauthorized access to the system.

Administrative settings

Here are the recommended general administrative settings:

1. Set a low idle timeout value, preferably less than ten minutes, for administrators.

2. Utilize non-standard ports for HTTPS and SSH access to the administrative interface.

3. Disable weak encryption protocols to ensure stronger security measures.

4. If the physical security of the FortiGate device cannot be guaranteed, it is advisable to disable the maintainer account.

– The built-in maintainer account is primarily used as a backup in case all administrator credentials are lost.

– Disabling the maintainer account without any remaining administrator credentials will result in the need to reset the FortiGate to factory default settings, making it inaccessible.

5. Replace the default certificate offered for HTTPS access with a trusted certificate that includes the FQDN or IP address of the FortiGate.

6. When using multiple FortiGates and fabric devices, configure the Fortinet Security Fabric for streamlined administration.

– The Fortinet Security Fabric provides a single-pane-of-glass administration, enabling administrators to access each device in the fabric using Single Sign-On (SSO).

7. A Fortinet Security Fabric includes a root FortiGate, downstream FortiGates, and other Fortinet fabric devices It is recommended to have a maximum of 35 downstream FortiGates within the Fortinet Security Fabric.

Logging and reporting

Logging generates various types of records, including system events, traffic data, and user logins, which are essential for alerts, analysis, and troubleshooting purposes. These records can be stored locally (data at rest) or remotely (data in motion). To ensure the security of log data, it is crucial to encrypt data in motion during logging transmissions. While FortiAnalyzer and FortiCloud have default encryption, when logging to third-party devices, it is essential to establish a secure channel. If the channel is not secure, it is recommended to create a VPN connection to the remote logging device before transmitting logs.

There are several logging options available, including FortiAnalyzer, syslog, and local disk storage. Using syslog only stores the log messages, while FortiAnalyzer not only stores the logs but also provides log analysis capabilities. When a security fabric is in place, it becomes possible to create rules that trigger specific actions based on the logged events. For example, sending an email notification if there is a change in the FortiGate configuration or executing a CLI script in response to a compromised host. If you are using a standalone logging server, integrating an analyzer application or server allows for parsing the raw logs into meaningful data.

For the purpose of security information and event management (SIEM) and security orchestration, automation, and response (SOAR), various SIEM and SOAR products can be utilized. While any generic SIEM and SOAR product, along with any log analyzer, can be used. These products aggregate security data from multiple sources and generate alerts, with SOAR additionally providing automation capabilities to respond to different types of alerts.

Performance monitoring

FortiGate offers support for multiple resource monitoring protocols, including SNMPv3, NetFlow, and sFlow. These protocols play a crucial role in measuring the performance of the FortiGate device and providing valuable insights into the traffic it handles.

To optimize monitoring, SNMP polling and traps can be employed, and the results should be collected and consolidated to generate meaningful output. There are various third-party SNMP reporting applications available that can be utilized for analyzing the collected results.

Resource monitoring serves several purposes and helps establish baselines for resource utilization, which prove valuable in various scenarios:

1. Configuring IPS signature rates based on observed resource utilization.

2. Detecting abnormal activity, such as identifying ongoing attacks.

3. Comparing bandwidth utilization over specific time spans, such as month-to-month or year-to-year, to effectively plan for future growth.

4. Comparing bandwidth utilization across different WANs and implementing SD-WAN and traffic shaping techniques as required.

5. Fine-tuning security profiles to optimize resource usage and performance.

Identity access management

Establishing secure authentication is of utmost importance when implementing a robust security policy. Many severe security breaches result from compromised user accounts. By effectively identifying and authenticating users, a more precise level of control can be implemented to ensure appropriate access to network resources.

FortiGate offers support for various user identification methods, including but not limited to:

1. Local: Usernames and passwords are stored directly on the FortiGate device.

2. Remote: Usernames and passwords are stored on a remote server, such as LDAPS or TACACS+, which the FortiGate queries for authentication.

3. PKI/Peer: Users authenticate using client certificates, enhancing security through public key infrastructure.

These authentication mechanisms provided by FortiGate enable organizations to enforce stringent access controls and bolster the overall security posture.

Authentication can be configured for:

• Administrative access
• Firewall authentication and SSO
• VPN

The most effective authentication includes more than one of the following:

Something that the user knows: a username and password

Something that the user has: a certificate, a one time password (OTP) in the form of a token or code either sent to the user over email or SMS, or generated by a hardware token or authenticator app.

Something specific to the user: biometric data, such as a fingerprint

Implementing Single Sign-On (SSO) can significantly reduce user fatigue by enabling users to authenticate only once to gain access to all authorized resources seamlessly.

FortiClient offers a comprehensive solution for user and device identification and can function as an SSO agent. It also plays a vital role in the Zero Trust Network Access (ZTNA) solution, enabling authentication alongside security posture checks.

It’s important to note that when implementing Multi-Factor Authentication (MFA) on the FortiGate, a FortiToken can only be registered to one FortiGate at a time. If you opt to use a remote authentication server for MFA, each FortiGate should be configured to communicate with the server. FortiAuthenticator and FortiToken Cloud are remote authentication servers capable of managing FortiTokens for multiple FortiGates simultaneously. This allows for the use of a single token per user across multiple FortiGates, ensuring a consistent and secure authentication experience.

High availability and redundancy

High availability and redundancy are critical considerations to minimize downtime and ensure uninterrupted business operations in the face of unexpected network failures. The level of acceptable downtime varies among companies, so it is crucial to assess your specific uptime requirements and design a resilient network accordingly.

Building a resilient network may involve additional costs initially but provides long-term benefits. This can include implementing High Availability (HA) solutions, having cold standby spares, utilizing multiple internet circuits, and investing in premium support contracts, among other measures.

High availability

FortiGate offers various HA options to enhance network resilience. These include the FortiGate Clustering Protocol (FGCP), FortiGate Session Life Support Protocol (FGSP), Virtual Router Redundancy Protocol (VRRP), and auto scaling in cloud environments.

FGCP is commonly used for HA, allowing two or more FortiGates of the same type and model to form a cluster in Active-Passive (A-P) or Active-Active (A-A) mode. A-P mode ensures redundancy by having one or more FortiGates in hot standby to swiftly take over if the primary device fails. A-A mode balances traffic across the cluster for scanning purposes while also providing failover capabilities. For edge FortiGates, it is recommended to have at least a two-unit cluster.

FGSP is employed in advanced setups that incorporate external load balancers to distribute traffic across firewall nodes. FGSP members can have different network configurations and don’t need to be physically located together. Each FGSP member typically enforces identical firewall policies to maintain consistent access rules. In case of device failure, sessions can be seamlessly transferred to another FGSP member.

HA is also supported on cloud and virtual platforms, offering options such as A-P, A-A load balancing, and auto-scaling. Refer to the FortiGate Public Cloud documentation for detailed instructions.

VRRP is another HA option, particularly useful when interoperating with third-party routers and firewalls. For more information, consult the relevant public documentation.

Redundant and aggregate links

Implementing redundant and aggregated links further enhances network resiliency. Utilizing multiple interfaces and links provides redundancy in case of link failure and increases overall throughput at a lower cost compared to relying on a single high-capacity link. Assessing your network for single points of failure, such as switches or FortiGate devices, is crucial. A full mesh switching solution combined with FortiGate HA can eliminate single points of failure and ensure network continuity. For specific guidance on redundancy deployments with FortiSwitch, consult the FortiSwitch documentation.

Consider your environment and budget to determine the most suitable options for your specific use case, balancing resilience and cost-effectiveness.

Hardning

Hardening FortiGate firewalls is of paramount importance from a security perspective. FortiGate firewalls act as the first line of defense against unauthorized access and malicious activities in a network. By implementing robust hardening measures, organizations can significantly enhance their overall security posture and mitigate potential risks. Hardening involves configuring the firewall with secure settings, disabling unnecessary services and ports, enforcing strong authentication and access controls, implementing intrusion prevention systems (IPS), and keeping the firmware up to date. These measures help safeguard the firewall against vulnerabilities, unauthorized access attempts, and potential exploitation. Hardening FortiGate firewalls ensures that only authorized traffic is allowed, minimizes attack surfaces, and provides an essential layer of protection for critical network resources and sensitive data.