ConfigSentry Technical Security Report

The default built-in administrator account named admin is still enabled. Leaving the default administrator account active makes credential guessing easier because attackers already know a valid username, increasing the risk of brute-force attempts, credential-stuffing, unauthorized management access, and poor administrator accountability.

Create one or more named administrator accounts with appropriate access profiles, strong authentication, and trusted host restrictions, then disable the default admin account if the operational and support model allows it.

Recommended configuration:
config system admin
edit "<named-admin>"
set accprofile "super_admin"
set password <strong-password>
set trusthost1 192.0.2.10 255.255.255.255
next
edit "admin"
set status disable
next
end

Before disabling the default admin account, confirm that at least one named emergency or break-glass administrator exists, MFA and trusted hosts are configured where supported, credentials are stored securely, and operational recovery procedures are documented.

This active FortiGate administrator account is configured without multi-factor authentication or approved external authentication. Administrator accounts provide privileged access to firewall configuration, security policy, VPN settings, routing, logging, and other sensitive controls. If an administrator password is guessed, reused, phished, leaked, or stolen, an attacker may be able to access the firewall using only a single authentication factor.

Enable MFA for local FortiGate administrator accounts, or move administrator access to an approved external authentication workflow that enforces MFA.

Review all active administrator accounts and confirm that each one is protected by FortiToken, email-based two-factor authentication, SMS-based two-factor authentication where acceptable, or centrally managed remote authentication with MFA enforced by the identity provider.

Disable or remove unused local administrator accounts. Where local emergency or break-glass administrator accounts are required, restrict their use, protect them with MFA where supported, store credentials securely, and monitor their usage.

Example configuration using FortiToken:
config system admin
edit <admin-name>
set two-factor fortitoken
set fortitoken <token-serial>
next
end

This active FortiGate administrator account uses remote authentication, but the firewall configuration export does not prove whether the external authentication provider enforces MFA. Remote authentication can be an appropriate control when MFA, account lifecycle management, and access policy are enforced by the identity provider, RADIUS, TACACS+, LDAP, or SAML workflow.

Verify that the remote authentication path for this administrator account enforces MFA and is managed through an approved identity process.

Recommended checks:
- Confirm which remote authentication server or group is used by this administrator account.
- Confirm MFA is enforced by the identity provider or remote access workflow.
- Confirm disabled or departed users are removed through central identity lifecycle controls.
- Confirm administrator access is restricted to approved groups.
- Confirm emergency or break-glass accounts are separately controlled, monitored, and reviewed.

If MFA is not enforced externally, enable FortiGate MFA for the account or move administrator access to an approved MFA-protected authentication workflow.

Example local FortiToken configuration:
config system admin
edit <admin-name>
set two-factor fortitoken
set fortitoken <token-serial>
next
end

A WAN-facing FortiGate interface allows interactive administrator login services.

Remove interactive administrator access from interfaces that are internet-facing, external, or otherwise reachable from untrusted networks. Services such as HTTPS, HTTP, SSH, and Telnet expose the FortiGate management plane and can increase the risk of credential attacks, vulnerability probing, brute-force attempts, and accidental public administration exposure.

Recommended configuration:
config system interface
edit <wan-or-external-interface>
set allowaccess ping
next
end

Use a dedicated management interface, internal management VLAN, VPN, ZTNA, or controlled jump-host path for administrator access instead. If remote administration is genuinely required, restrict it with administrator trusted hosts and local-in policy controls, require MFA, disable insecure protocols such as HTTP and Telnet, and ensure all administrative access is logged and monitored.

Before removing access, confirm that administrators have a working approved management path so the firewall is not accidentally locked out.

A WAN-facing FortiGate interface allows interactive administrator login services.

Remove interactive administrator access from interfaces that are internet-facing, external, or otherwise reachable from untrusted networks. Services such as HTTPS, HTTP, SSH, and Telnet expose the FortiGate management plane and can increase the risk of credential attacks, vulnerability probing, brute-force attempts, and accidental public administration exposure.

Recommended configuration:
config system interface
edit <wan-or-external-interface>
set allowaccess ping
next
end

Use a dedicated management interface, internal management VLAN, VPN, ZTNA, or controlled jump-host path for administrator access instead. If remote administration is genuinely required, restrict it with administrator trusted hosts and local-in policy controls, require MFA, disable insecure protocols such as HTTP and Telnet, and ensure all administrative access is logged and monitored.

Before removing access, confirm that administrators have a working approved management path so the firewall is not accidentally locked out.

This policy appears to allow traffic from an internet, WAN, or external interface directly toward a likely Cardholder Data Environment (CDE), Payment Card Industry (PCI), payment, Point of Sale (POS), or cardholder-data destination without an obvious DMZ or segmented inspection tier.

Internet-facing payment systems should normally be placed behind a dedicated DMZ, reverse proxy, WAF, VPN, ZTNA, or other controlled inspection layer.

Example configuration:
config firewall policy
edit <policy-id>
set srcintf "<wan-or-external-interface>"
set dstintf "<dmz-or-inspection-interface>"
set srcaddr "<approved-remote-source>"
set dstaddr "<dmz-published-payment-service>"
set service "HTTPS"
set logtraffic all
next
end

Then use a separate tightly controlled policy from the DMZ or inspection tier to the CDE destination, restricted to the exact required source, destination, and service. If this policy is intentional, confirm the CDE classification, segmentation design, source restrictions, logging, monitoring, and compensating controls are documented.

This firewall policy allows unrestricted traffic because the source address, destination address, and service are all set to "all" or equivalent Any values.

An Any/Any/Any policy does not follow the principle of least privilege. It can allow more traffic than intended, increase the attack surface, and make it harder to control, monitor, and justify access between networks. If this rule is near the top of the policy list, it may also bypass more specific rules placed below it.

Review the policy to confirm whether it is still required. Use FortiGate logs, policy hit counts, and traffic analysis to identify the actual sources, destinations, and services using this rule.

Replace the broad policy with one or more specific policies that only allow the required traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Services or service groups
4. Source and destination interfaces and security zones
5. Security profiles
6. Schedule, if access is only required at specific times

Place the new restrictive policies above the existing Any/Any/Any policy, then monitor traffic to confirm they work as expected. Once the required access has been migrated, disable or remove the overly permissive policy.

Example configuration:
config firewall policy
edit <poicy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

This firewall policy allows unrestricted traffic because the source address, destination address, and service are all set to "all" or equivalent Any values.

An Any/Any/Any policy does not follow the principle of least privilege. It can allow more traffic than intended, increase the attack surface, and make it harder to control, monitor, and justify access between networks. If this rule is near the top of the policy list, it may also bypass more specific rules placed below it.

Review the policy to confirm whether it is still required. Use FortiGate logs, policy hit counts, and traffic analysis to identify the actual sources, destinations, and services using this rule.

Replace the broad policy with one or more specific policies that only allow the required traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Services or service groups
4. Source and destination interfaces and security zones
5. Security profiles
6. Schedule, if access is only required at specific times

Place the new restrictive policies above the existing Any/Any/Any policy, then monitor traffic to confirm they work as expected. Once the required access has been migrated, disable or remove the overly permissive policy.

Example configuration:
config firewall policy
edit <poicy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

This firewall policy allows unrestricted traffic because the source address, destination address, and service are all set to "all" or equivalent Any values.

An Any/Any/Any policy does not follow the principle of least privilege. It can allow more traffic than intended, increase the attack surface, and make it harder to control, monitor, and justify access between networks. If this rule is near the top of the policy list, it may also bypass more specific rules placed below it.

Review the policy to confirm whether it is still required. Use FortiGate logs, policy hit counts, and traffic analysis to identify the actual sources, destinations, and services using this rule.

Replace the broad policy with one or more specific policies that only allow the required traffic. Where possible, restrict:
1. Source addresses or source address groups
2. Destination addresses or destination address groups
3. Services or service groups
4. Source and destination interfaces and security zones
5. Security profiles
6. Schedule, if access is only required at specific times

Place the new restrictive policies above the existing Any/Any/Any policy, then monitor traffic to confirm they work as expected. Once the required access has been migrated, disable or remove the overly permissive policy.

Example configuration:
config firewall policy
edit <poicy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-group>"
next
end

The firewall policy publishes VIP 'VIP_RDP_SERVER' with sensitive exposed service or port VIP VIP_RDP_SERVER external port 3389.

Sensitive management or high-risk services should not normally be exposed directly through internet-facing VIP publication. Restrict the policy source to trusted remote addresses, VPN client ranges, partner ranges, or a controlled jump-host path. Where possible, avoid publishing administrative services directly to the Internet.

Recommended approach:

config firewall policy
edit <policy-id>
set srcaddr <trusted-source-or-vpn-range>
set dstaddr <specific-vip-object>
set service <required-specific-service-only>
set logtraffic all
next
end


If the service must remain externally reachable, confirm there is a documented business requirement, source restriction, logging, monitoring, and compensating controls such as VPN, ZTNA, MFA, IPS, or application-layer protection.

Administrator account admin does not restrict all administrative login sources with trusted hosts.

IPv4 trusted hosts are not restricted.
IPv6 trusted hosts are not restricted.

FortiOS trusted hosts work as a whitelist: when trusted hosts are configured, matching sources are allowed and all other login sources are implicitly denied. Leaving trusted host entries blank, unset, or unrestricted can allow administrator login attempts from unauthorized locations.

Restrict each administrator account to approved management hosts or management subnets for both IPv4 and IPv6 where IPv6 administration is possible.

Recommended IPv4 configuration:
config system admin
edit "<admin-name>"
set trusthost1 192.0.2.10 255.255.255.255
set trusthost2 198.51.100.0 255.255.255.0
next
end

Recommended IPv6 configuration:
config system admin
edit "<admin-name>"
set ip6-trusthost1 2001:db8:100::10/128
set ip6-trusthost2 2001:db8:200::/64
next
end

Do not configure a broad trusted host such as 0.0.0.0/0 or ::/0. To remove an unwanted trusted host entry, unset the relevant trusthost field. After applying the change, confirm administrator access still works from approved management locations and is denied from unauthorized sources.

Administrator account radius-admin does not restrict all administrative login sources with trusted hosts.

IPv4 trusted hosts are not restricted.
IPv6 trusted hosts are not restricted.

FortiOS trusted hosts work as a whitelist: when trusted hosts are configured, matching sources are allowed and all other login sources are implicitly denied. Leaving trusted host entries blank, unset, or unrestricted can allow administrator login attempts from unauthorized locations.

Restrict each administrator account to approved management hosts or management subnets for both IPv4 and IPv6 where IPv6 administration is possible.

Recommended IPv4 configuration:
config system admin
edit "<admin-name>"
set trusthost1 192.0.2.10 255.255.255.255
set trusthost2 198.51.100.0 255.255.255.0
next
end

Recommended IPv6 configuration:
config system admin
edit "<admin-name>"
set ip6-trusthost1 2001:db8:100::10/128
set ip6-trusthost2 2001:db8:200::/64
next
end

Do not configure a broad trusted host such as 0.0.0.0/0 or ::/0. To remove an unwanted trusted host entry, unset the relevant trusthost field. After applying the change, confirm administrator access still works from approved management locations and is denied from unauthorized sources.

The FortiGate administrator password policy does not meet the required minimum password-strength baseline.

Password policy status is disable; it must be enabled.
Minimum password length is 8; the required minimum is 12.
Minimum lowercase-letter requirement is 0; the required minimum is 1.
Minimum uppercase-letter requirement is 0; the required minimum is 1.
Minimum numeric-character requirement is 0; the required minimum is 1.
Minimum non-alphanumeric-character requirement is 0; the required minimum is 1.

Weak administrator password requirements increase the risk that local administrator accounts can use short or easily guessed passwords. This can increase the likelihood of management-plane compromise through credential guessing, credential reuse, brute-force attempts, or stolen credentials.

Update the password-policy settings that do not meet the required minimum. Existing settings that already meet or exceed the baseline do not need to be reduced or changed.

Recommended configuration:
config system password-policy
set status enable
set minimum-length 12
set min-lower-case-letter 1
set min-upper-case-letter 1
set min-number 1
set min-non-alphanumeric 1
end

Where supported by the operational environment, consider using stronger requirements than the minimum shown above, especially for local break-glass administrator accounts. Combine password complexity with MFA, restricted trusted hosts, named administrator accounts, administrator audit logging, and centralized authentication where appropriate.

Administrator lockout and retry protection is not configured strongly enough, allowing repeated failed login attempts without an effective delay or lockout. Weak lockout settings increase the risk of brute-force attempts, password guessing, credential-stuffing, and noisy management-plane attacks against FortiGate administrator accounts.

Configure a low administrator login failure threshold and a meaningful lockout duration so repeated failed login attempts are throttled.

Recommended configuration:
config system global
set admin-lockout-threshold 3
set admin-lockout-duration 60
end

Use a threshold of 1 to 5 failed attempts and a lockout duration of at least 30 seconds. A slightly longer duration, such as 60 seconds or more, is usually preferable for internet-exposed or sensitive management environments.

This should be combined with MFA, strong administrator passwords, named administrator accounts, restricted trusted hosts, VPN or jump-host management access, and administrator audit logging.

HTTPS administration explicitly allows TLS 1.1.

The FortiGate HTTPS administration service is configured with TLS 1.1 in the list of permitted SSL/TLS versions. This means the management interface may allow administrators or clients to connect using an outdated encryption protocol.

TLS 1.1 is deprecated and should not be permitted for administrative access. Even when management access is restricted to trusted networks, administrative sessions should use modern cryptographic protocols to help protect credentials, session tokens, and sensitive configuration activity. Allowing older protocols can increase the risk of downgrade attacks, weak encryption, and exposure of management traffic if the connection path is intercepted or otherwise untrusted.

Remove TLS 1.1 from the permitted HTTPS administration protocol list. Configure HTTPS administration so that only TLS 1.2 or newer is allowed, preferably including TLS 1.3 where supported by the FortiOS version and administrator client compatibility.

Before applying the change, confirm that approved browsers, jump hosts, automation tools, and management platforms can connect using TLS 1.2 or TLS 1.3. After applying the change, test HTTPS administrative access from an approved management workstation.

Example configuration:
config system global
set admin-https-ssl-versions tlsv1-2 tlsv1-3
end

HTTPS administration minimum protocol is lower than TLS 1.2.

The FortiGate HTTPS administration service is configured with a minimum SSL/TLS protocol version lower than TLS 1.2. This means clients may be allowed to negotiate SSLv3, TLS 1.0, or TLS 1.1 when connecting to the management interface.

Legacy protocols such as SSLv3, TLS 1.0, and TLS 1.1 are deprecated and provide weaker protection for administrative sessions. HTTPS administration protects sensitive activity, including administrator login, session handling, and firewall configuration changes. Allowing clients to negotiate older protocols increases the risk of weak encryption, downgrade attacks, and exposure of management traffic if the connection path is intercepted or exposed.

Set the minimum permitted protocol for HTTPS administration to TLS 1.2 or higher. This prevents clients from negotiating SSLv3, TLS 1.0, or TLS 1.1 when connecting to the FortiGate management interface.

Before applying the change, confirm that approved browsers, jump hosts, automation tools, and management platforms support TLS 1.2 or newer. After applying the change, test HTTPS administrative access from an approved management workstation.

Example configuration:
config system global
set ssl-min-proto-version TLSv1-2
end

Administrator SSH access allows legacy SSH version 1 compatibility, which weakens the security of FortiGate management access.

Disable SSH version 1 compatibility for FortiGate administrator access. SSHv1 is an obsolete management protocol and should not be permitted on firewall administration services. Even when administrators normally use SSHv2, leaving SSHv1 compatibility enabled increases exposure to legacy protocol negotiation, weak cryptographic behaviour, and unnecessary management-plane attack surface.

Administrative CLI access should use SSHv2 only, with access limited to trusted management networks, VPN users, jump hosts, or dedicated administrator workstations. This control should be combined with MFA for administrator accounts, restricted trusted hosts, strong admin authentication, and logging of administrative activity.

Recommended configuration:
config system global
set admin-ssh-v1 disable
end

After applying the change, confirm that legitimate administrators can still connect using SSHv2 and that SSH management is only reachable from approved source networks.

Strong cryptography is disabled, which can allow weaker cryptographic algorithms to remain available for FortiGate security and management functions.

Enable the FortiGate strong cryptography baseline so supported administrative and security functions use stronger cryptographic behaviour.

Recommended configuration:
config system global
set strong-crypto enable
end

After applying the change, verify that administrator access, VPN services, monitoring systems, and any integrated security tools continue to connect successfully. If an older client or integration depends on weaker cryptography, upgrade or replace that client rather than weakening the firewall cryptographic baseline.

Static-key TLS cipher suites are enabled, which can weaken FortiGate management-plane TLS security.

Disable static-key TLS cipher suites for FortiGate administrative services. Static-key TLS ciphers do not provide modern forward secrecy, meaning that if a private key is compromised later, previously captured TLS sessions may be at greater risk of decryption. Firewall management interfaces should only offer modern TLS cipher suites that support stronger key exchange and current cryptographic expectations.

This setting should be disabled alongside other management-plane hardening controls, including restricting HTTPS/SSH administration to trusted management networks, disabling obsolete TLS protocol versions, using a trusted administrator certificate, enabling MFA for administrators, and logging administrative access.

Recommended configuration:
config system global
set ssl-static-key-ciphers disable
end

After applying the change, confirm that approved administrators and management tools can still connect using modern TLS clients. If an old browser, scanner, or management platform requires static-key ciphers, upgrade or replace that client rather than weakening the firewall management plane.

No persistent FortiGate logging destination is enabled and fully configured.

A firewall without persistent logging can lose critical evidence needed for incident response, troubleshooting, change review, compliance reporting, and investigation of administrator activity.

Enable at least one retained logging destination so security, traffic, system, VPN, and administrative events are preserved beyond the local session/runtime log buffer.

Preferred options are centralized logging to FortiAnalyzer, FortiAnalyzer Cloud, or a managed syslog/SIEM platform. When using remote syslog or FortiAnalyzer, make sure the destination is not only enabled but also has a valid server value configured. Local disk logging may provide retained on-box logs where supported, but centralized logging is normally preferred so logs survive device failure, compromise, or replacement.

Example configuration:
config log syslogd setting
set status enable
set server "192.0.2.50"
set port 514
end

Example FortiAnalyzer configuration:
config log fortianalyzer setting
set status enable
set server "192.0.2.60"
end

After enabling persistent logging, confirm log delivery by generating a test event and verifying that it appears in the FortiAnalyzer, FortiAnalyzer Cloud, syslog, SIEM, or approved retained logging platform.

No enabled valid remote logging destination was detected in the configuration export.

Result:
- The firewall does not appear to be sending logs to an external syslog collector or FortiAnalyzer destination.

Why this matters:
- Security events, administrator activity, VPN events, traffic logs, and incident evidence may be unavailable if the firewall is compromised, rebooted, replaced, or loses local log history.

Configure centralized remote logging using an approved secure transport, such as encrypted syslog where supported or FortiAnalyzer.

Recommended checks:
- Send security and event logs to a central collector.
- Use encrypted transport where supported.
- Restrict logging traffic to approved management or logging networks.
- Confirm logs are retained, searchable, and protected from unauthorized access.

Example encrypted syslog configuration:
config log syslogd setting
set status enable
set server "192.0.2.50"
set enc-algorithm high
end

Example FortiAnalyzer logging configuration:
config log fortianalyzer setting
set status enable
set server "192.0.2.60"
set enc-algorithm high
set certificate-verification enable
set ssl-min-proto-version TLSv1-2
end

Example FortiAnalyzer Cloud logging configuration:
config log fortianalyzer-cloud setting
set status enable
set enc-algorithm high
set certificate-verification enable
set ssl-min-proto-version TLSv1-2
end

Administrator audit logging and automatic configuration revision backup are both disabled. Without these controls, it may be difficult to determine who made a change, what was changed, when it happened, and whether the change was authorized. This reduces visibility during incident response, troubleshooting, compliance review, and post-change investigation.

Enable administrator audit logging and configuration revision backup so administrative activity and configuration changes can be reviewed after the fact.

Example configuration:
config system global
set cli-audit-log enable
set revision-backup-on-logout enable
end

Administrator audit logs should also be sent to a persistent logging destination such as FortiAnalyzer, FortiAnalyzer Cloud, syslog, or a SIEM. Local audit history is useful, but centralized retained logging is preferred because it helps preserve evidence if the firewall is rebooted, replaced, misconfigured, or compromised.

After enabling these settings, make a controlled test change with an administrator account and confirm that the activity is visible in the local logs and in the approved retained logging platform.

This interface allows insecure administrator access using HTTP and/or Telnet. These protocols do not provide the protection expected for firewall management access: Telnet sends administrative sessions without encryption, and HTTP exposes management traffic without TLS.

Remove HTTP and Telnet from interface administrative access. FortiGate administrator access should use secure management paths such as HTTPS or SSH, and only from trusted management networks, VPN users, ZTNA paths, or controlled jump hosts.

Example Configuration:
config system interface
edit <interface-name>
set allowaccess ping https ssh
next
end

Only enable the management services that are genuinely required on each interface. For internet-facing or untrusted interfaces, avoid exposing interactive administrator access entirely unless there is a documented exception with trusted hosts, local-in policy restrictions, MFA, logging, and monitoring.

No IPv4 or IPv6 local-in policies were detected.

Result:
- Traffic destined directly to FortiGate interfaces is not protected by an explicit top-down local-in policy set.

Why this matters:
- Local-in policies control traffic destined directly to FortiGate interfaces.
- Missing or incomplete local-in deny coverage can leave administrator access, SNMP, routing protocols, or FortiManager control-plane services exposed.
- Interface administrative access settings alone do not provide the same explicit top-down local-in policy control.

Configure explicit local-in policies that allow only trusted sources, followed by deny rules for untrusted sources to the protected services.

The rule checked the actual configured FortiGate administrator ports from `config system global`, SNMP query ports from `config system snmp`, and fixed routing/control-plane ports for BGP, RIP, RIPng, and FGFM.

Recommended IPv4 pattern:
config firewall local-in-policy
edit 1
set intf "mgmt"
set srcaddr "Trusted_Admin_Sources"
set dstaddr "all"
set action accept
set service "ADMIN_HTTPS_PORT" "ADMIN_SSH_PORT" "SNMP_QUERY_PORT"
set schedule "always"
next
edit 2
set intf "wan1"
set srcaddr "Approved_BGP_Peers"
set dstaddr "all"
set action accept
set service "BGP"
set schedule "always"
next
edit 3
set intf "wan1"
set srcaddr "Approved_RIP_Peers"
set dstaddr "all"
set action accept
set service "RIP"
set schedule "always"
next
edit 4
set intf "mgmt"
set srcaddr "Approved_FortiManager"
set dstaddr "all"
set action accept
set service "FGFM"
set schedule "always"
next
edit 99
set intf "any"
set srcaddr "all"
set dstaddr "all"
set action deny
set service "ADMIN_HTTP_PORT" "ADMIN_HTTPS_PORT" "ADMIN_SSH_PORT" "ADMIN_TELNET_PORT" "SNMP_QUERY_PORT" "BGP" "RIP" "FGFM"
set schedule "always"
next
end

Recommended IPv6 pattern:
config firewall local-in-policy6
edit 1
set intf "mgmt"
set srcaddr "Trusted_Admin_Sources_IPv6"
set dstaddr "all"
set action accept
set service "ADMIN_HTTPS_PORT" "ADMIN_SSH_PORT" "SNMP_QUERY_PORT"
set schedule "always"
next
edit 2
set intf "wan1"
set srcaddr "Approved_BGP_Peers_IPv6"
set dstaddr "all"
set action accept
set service "BGP"
set schedule "always"
next
edit 3
set intf "wan1"
set srcaddr "Approved_RIPng_Peers"
set dstaddr "all"
set action accept
set service "RIPNG"
set schedule "always"
next
edit 4
set intf "mgmt"
set srcaddr "Approved_FortiManager_IPv6"
set dstaddr "all"
set action accept
set service "FGFM6"
set schedule "always"
next
edit 99
set intf "any"
set srcaddr "all"
set dstaddr "all"
set action deny
set service "ADMIN_HTTP_PORT" "ADMIN_HTTPS_PORT" "ADMIN_SSH_PORT" "ADMIN_TELNET_PORT" "SNMP_QUERY_PORT" "BGP" "RIPNG" "FGFM6"
set schedule "always"
next
end

Create custom service objects where needed for changed administrator ports, changed SNMP query ports, FGFM IPv6 TCP/542, RIPng UDP/521, or other services not available as built-in FortiGate service objects. Deny rules may be scoped to real Internet-facing interfaces or zones, provided they deny all untrusted source IPs for the protected service.

Certificate 'expired_cert_test' in VDOM 'root' has expired. Expired VPN certificates can prevent tunnel negotiation, client authentication, or other certificate-based VPN functions from working correctly.

Renew or replace the expired certificate. After importing the replacement certificate and private key, confirm that the related VPN configuration is updated and the tunnel or remote access service still works.

Example configuration:
config vpn certificate local
edit <entry-name>
set certificate "<BASE64_OR_PEM_CERTIFICATE>"
set private-key "<BASE64_OR_PEM_PRIVATE_KEY>"
next
end

This firewall policy permits cleartext or insecure legacy services that should be restricted.

ALL services are permitted, which includes cleartext and insecure legacy protocols.


Cleartext protocols can expose credentials, application data, file transfers, email content, or administrative sessions to interception or modification. Use encrypted alternatives wherever possible.

Remove or replace the detected cleartext services. Use SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and encrypted mail protocols where appropriate.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "<approved-encrypted-service>"
next
end

If a legacy cleartext protocol is still required, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy dependency can be removed.

This firewall policy permits cleartext or insecure legacy services that should be restricted.

ALL services are permitted, which includes cleartext and insecure legacy protocols.


Cleartext protocols can expose credentials, application data, file transfers, email content, or administrative sessions to interception or modification. Use encrypted alternatives wherever possible.

Remove or replace the detected cleartext services. Use SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and encrypted mail protocols where appropriate.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "<approved-encrypted-service>"
next
end

If a legacy cleartext protocol is still required, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy dependency can be removed.

This firewall policy permits cleartext or insecure legacy services that should be restricted.

ALL services are permitted, which includes cleartext and insecure legacy protocols.


Cleartext protocols can expose credentials, application data, file transfers, email content, or administrative sessions to interception or modification. Use encrypted alternatives wherever possible.

Remove or replace the detected cleartext services. Use SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and encrypted mail protocols where appropriate.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "<approved-encrypted-service>"
next
end

If a legacy cleartext protocol is still required, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy dependency can be removed.

This firewall policy permits cleartext or insecure legacy services that should be restricted.

FTP (TCP/21) is permitted. FTP does not protect credentials or transferred data with encryption.
Telnet (TCP/23) is permitted. Telnet transmits administrative sessions and credentials without encryption.
HTTP (TCP/80) is permitted across a non-Internet-outbound firewall policy. HTTP is unencrypted and should normally be replaced with HTTPS for traffic crossing network security boundaries.


Cleartext protocols can expose credentials, application data, file transfers, email content, or administrative sessions to interception or modification. Use encrypted alternatives wherever possible.

Remove or replace the detected cleartext services. Use SSH instead of Telnet, HTTPS instead of HTTP, SFTP or FTPS instead of FTP/TFTP, and encrypted mail protocols where appropriate.

Recommended configuration example:
config firewall policy
edit <policy-id>
set service "HTTPS" "<approved-encrypted-service>"
next
end

If a legacy cleartext protocol is still required, restrict the policy to the exact approved source, destination, interface path, and service. Enable logging, document the exception, and review it regularly until the legacy dependency can be removed.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This enabled inbound internet allow policy does not have an IPS sensor, antivirus profile, or application control list applied directly or through a firewall profile group. Inbound policies from WAN, internet, external, or outside interfaces expose services to untrusted traffic, so they should normally have suitable threat inspection unless a documented exception exists.

Apply appropriate threat inspection directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ips-sensor "default"
set av-profile "default"
set application-list "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Choose profiles appropriate to the exposed service. For some inbound services, IPS may be the most important control; for web or file-transfer services, antivirus and application control may also be appropriate. If inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, logging, monitoring, and regular review.

This firewall policy allows outbound Internet access using one or more overly broad traffic selectors.

Source address is overly broad: policy directly references all.
Destination address is overly broad: policy directly references all.
Service is overly broad: policy directly references service ALL.

Outbound Internet access should follow the principle of least privilege. Broad source networks, unrestricted Internet destinations, or service ALL can permit substantially more traffic than is required and can make compromised hosts, malware callbacks, unauthorized cloud access, or data exfiltration harder to control.

Named host objects, specific subnet objects, address groups containing specific destinations, and specific service objects are not considered broad by this rule unless they ultimately resolve to an unrestricted value.

Restrict only the broad element or elements identified in the finding. Existing source, destination, or service definitions that are already specific do not need to be changed.

Recommended configuration:
config firewall policy
edit <policy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-or-service-group>"
next
end

Use FortiGate logs, policy hit counts, application requirements, and approved destination information to determine the narrowest appropriate source, destination, and service definitions. Address groups containing approved vendor, cloud, FQDN, or host objects are appropriate where the individual members are specific. Avoid service ALL or unrestricted Internet destinations unless there is a documented operational requirement.

This firewall policy allows outbound Internet access using one or more overly broad traffic selectors.

Source address is overly broad: policy directly references all.
Destination address is overly broad: policy directly references all.
Service is overly broad: policy directly references service ALL.

Outbound Internet access should follow the principle of least privilege. Broad source networks, unrestricted Internet destinations, or service ALL can permit substantially more traffic than is required and can make compromised hosts, malware callbacks, unauthorized cloud access, or data exfiltration harder to control.

Named host objects, specific subnet objects, address groups containing specific destinations, and specific service objects are not considered broad by this rule unless they ultimately resolve to an unrestricted value.

Restrict only the broad element or elements identified in the finding. Existing source, destination, or service definitions that are already specific do not need to be changed.

Recommended configuration:
config firewall policy
edit <policy-id>
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-or-service-group>"
next
end

Use FortiGate logs, policy hit counts, application requirements, and approved destination information to determine the narrowest appropriate source, destination, and service definitions. Address groups containing approved vendor, cloud, FQDN, or host objects are appropriate where the individual members are specific. Avoid service ALL or unrestricted Internet destinations unless there is a documented operational requirement.

This firewall policy allows outbound Internet access using one or more overly broad traffic selectors.

Destination address is overly broad: policy directly references all.

Outbound Internet access should follow the principle of least privilege. Broad source networks, unrestricted Internet destinations, or service ALL can permit substantially more traffic than is required and can make compromised hosts, malware callbacks, unauthorized cloud access, or data exfiltration harder to control.

Named host objects, specific subnet objects, address groups containing specific destinations, and specific service objects are not considered broad by this rule unless they ultimately resolve to an unrestricted value.

Restrict only the broad element or elements identified in the finding. Existing source, destination, or service definitions that are already specific do not need to be changed.

Recommended configuration:
config firewall policy
edit <policy-id>
set dstaddr "<approved-destination-object>"
next
end

Use FortiGate logs, policy hit counts, application requirements, and approved destination information to determine the narrowest appropriate source, destination, and service definitions. Address groups containing approved vendor, cloud, FQDN, or host objects are appropriate where the individual members are specific. Avoid service ALL or unrestricted Internet destinations unless there is a documented operational requirement.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This enabled public inbound firewall policy does not have matching enabled DoS policy protection.

The rule checked for an enabled IPv4 DoS policy that covers the inbound interface, the externally visible destination, and the services published by this firewall policy. For VIP destinations, coverage is evaluated against the VIP external address because DoS processing occurs before destination NAT.

Public inbound services without appropriate DoS protection can be more exposed to connection floods, protocol anomaly traffic, scanning, and resource-exhaustion attacks.

Create or update an enabled DoS policy so that it covers the public inbound interface or zone, externally visible destination, and published service used by this firewall policy.

Recommended configuration:
config firewall DoS-policy
edit <dos-policy-id>
set name "<descriptive-name>"
set interface "<internet-interface-or-zone>"
set srcaddr "all"
set dstaddr "<public-destination-address-object>"
set service "<published-service-or-service-group>"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "udp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold <appropriate-threshold>
next
end
next
end

For a firewall policy publishing a VIP, the DoS destination should cover the VIP external address rather than only its mapped internal address. Tune anomaly types and thresholds for the expected traffic profile, confirm legitimate traffic is not disrupted, and review upstream DDoS protection, ISP filtering, CDN/WAF controls, IPS, logging, and monitoring as part of the exposed-service design.

This internet-facing firewall policy accepts traffic from private or locally scoped source address ranges. Private IPv4 ranges (RFC1918) and IPv6 Unique Local Addresses (RFC4193) should not normally arrive from the public internet, so allowing them on an external-facing policy can indicate missing anti-spoofing controls and may allow spoofed traffic to reach internal, DMZ, VPN, or published services.

Restrict internet-facing policies to legitimate public source ranges, approved partner ranges, or trusted remote access sources. Remove RFC1918 IPv4 ranges and IPv6 ULA ranges from source objects used on WAN-facing policies unless there is a documented routed-private or VPN design that requires them.

Recommended policy correction:
config firewall policy
edit <policy-id>
set srcaddr "<approved-public-or-remote-source>"
next
end

Also enable source address validation on WAN-facing interfaces where supported:
config system interface
edit "<wan-interface>"
set src-check enable
next
end

After applying the change, confirm that legitimate inbound traffic still matches the intended policy and that spoofed private-source traffic is denied and logged.

This internet-facing firewall policy accepts traffic from private or locally scoped source address ranges. Private IPv4 ranges (RFC1918) and IPv6 Unique Local Addresses (RFC4193) should not normally arrive from the public internet, so allowing them on an external-facing policy can indicate missing anti-spoofing controls and may allow spoofed traffic to reach internal, DMZ, VPN, or published services.

Restrict internet-facing policies to legitimate public source ranges, approved partner ranges, or trusted remote access sources. Remove RFC1918 IPv4 ranges and IPv6 ULA ranges from source objects used on WAN-facing policies unless there is a documented routed-private or VPN design that requires them.

Recommended policy correction:
config firewall policy
edit <policy-id>
set srcaddr "<approved-public-or-remote-source>"
next
end

Also enable source address validation on WAN-facing interfaces where supported:
config system interface
edit "<wan-interface>"
set src-check enable
next
end

After applying the change, confirm that legitimate inbound traffic still matches the intended policy and that spoofed private-source traffic is denied and logged.

This enabled inbound firewall policy allows sensitive management, file-sharing, directory, remote-access, or database services directly from a WAN, internet, or external source interface without using a VIP-published service path. Exposing services such as SSH, RDP, VNC, SMB, WinRM, LDAP, MySQL, MSSQL, FTP, or Telnet directly from untrusted networks increases the risk of brute-force attacks, credential theft, exploitation of exposed services, lateral movement, and unauthorized administrative access.

Restrict inbound exposure of sensitive services. Limit access to explicitly approved remote source addresses, publish only hardened services where required, and use a controlled access design such as VPN, ZTNA, bastion hosts, reverse proxy, or tightly scoped VIPs.

Recommended configuration example:
config firewall policy
edit <policy-id>
set srcaddr "<approved-remote-source>"
set service "<approved-service>"
set logtraffic all
next
end

For administrative access, avoid exposing management protocols directly to the internet. Use MFA-protected VPN or ZTNA access, named administrator accounts, trusted hosts, logging, IPS, application control, and regular review of the rule justification.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering incorrectly configured.

Internet-bound evidence:
- shared outbound policy classification confirmed internet destination

Expected:
- reputation-direction destination
- reputation-minimum 3 or higher

Why this matters:
- For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3.
- This helps restrict traffic to known malicious, high-risk, or unverified destinations before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering incorrectly configured.

Internet-bound evidence:
- shared outbound policy classification confirmed internet destination

Expected:
- reputation-direction destination
- reputation-minimum 3 or higher

Why this matters:
- For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3.
- This helps restrict traffic to known malicious, high-risk, or unverified destinations before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering incorrectly configured.

Internet-bound evidence:
- shared outbound policy classification confirmed internet destination

Expected:
- reputation-direction destination
- reputation-minimum 3 or higher

Why this matters:
- For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3.
- This helps restrict traffic to known malicious, high-risk, or unverified destinations before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering incorrectly configured.

Internet-bound evidence:
- shared outbound policy classification confirmed internet destination

Expected:
- reputation-direction destination
- reputation-minimum 3 or higher

Why this matters:
- For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3.
- This helps restrict traffic to known malicious, high-risk, or unverified destinations before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering incorrectly configured.

Internet-bound evidence:
- shared outbound policy classification confirmed internet destination

Expected:
- reputation-direction destination
- reputation-minimum 3 or higher

Why this matters:
- For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3.
- This helps restrict traffic to known malicious, high-risk, or unverified destinations before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This enabled internet-bound firewall policy has IPv4 IP reputation filtering incorrectly configured.

Internet-bound evidence:
- shared outbound policy classification confirmed internet destination

Expected:
- reputation-direction destination
- reputation-minimum 3 or higher

Why this matters:
- For outbound internet traffic, reputation filtering should evaluate the destination address and require a minimum reputation level of at least 3.
- This helps restrict traffic to known malicious, high-risk, or unverified destinations before users, servers, or applications connect to them.

Configure IPv4 destination-direction IP reputation filtering on this internet-bound firewall policy.

Recommended configuration:
config firewall policy
edit <policy-id>
set reputation-direction destination
set reputation-minimum 3
next
end

After applying the change, confirm that legitimate business destinations are not unintentionally blocked and review logs for reputation-based drops.

This DNS Filter profile does not have Botnet C&C domain blocking enabled. Without this setting, DNS lookups for known botnet command-and-control domains may not be blocked at the DNS resolution stage.

Enable Botnet C&C domain blocking on the DNS Filter profile.

Recommended configuration:
config dnsfilter profile
edit "DNS_FILTER_PROFILE_NAME"
set block-botnet enable
next
end

After applying the change, confirm that firewall policies allowing DNS traffic use a DNS Filter profile, and that DNS Filter logging is enabled where operationally required.

This enabled inbound internet web policy allows ALL without an effective SSL/SSH inspection profile and WAF profile.

Inbound internet evidence:
- isInternetInboundPolicy source classification

Why this matters:
- Inbound web services exposed from internet-facing sources should have suitable web-layer inspection.
- HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile.

Inbound internet evidence:
- isInternetInboundPolicy source classification

Why this matters:
- Inbound web services exposed from internet-facing sources should have suitable web-layer inspection.
- HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile.

Inbound internet evidence:
- isInternetInboundPolicy source classification

Why this matters:
- Inbound web services exposed from internet-facing sources should have suitable web-layer inspection.
- HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile.

Inbound internet evidence:
- isInternetInboundPolicy source classification

Why this matters:
- Inbound web services exposed from internet-facing sources should have suitable web-layer inspection.
- HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective SSL/SSH inspection profile and WAF profile.

Inbound internet evidence:
- isInternetInboundPolicy source classification

Why this matters:
- Inbound web services exposed from internet-facing sources should have suitable web-layer inspection.
- HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This enabled inbound internet web policy allows HTTPS without an effective WAF profile.

Inbound internet evidence:
- isInternetInboundPolicy source classification

Why this matters:
- Inbound web services exposed from internet-facing sources should have suitable web-layer inspection.
- HTTPS services should also have an effective SSL/SSH inspection profile so encrypted sessions do not bypass the intended inspection controls.

Apply suitable inspection to the inbound internet web policy, either directly on the policy or through a firewall profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set ssl-ssh-profile "certificate-inspection"
set waf-profile "default"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

For HTTP-only inbound services, SSL/SSH inspection may not apply, but WAF inspection should still be considered. For HTTPS services, use the SSL/SSH inspection profile appropriate to the deployment. If WAF or SSL inspection is intentionally excluded, document the exception and confirm compensating controls such as strict source restrictions, hardened backend services, IPS, application control, logging, monitoring, and regular review.

This firewall policy allows broad access between internal interfaces or internal security zones.

Broad element detected:
- source address

Why this matters:
- Internal firewall policies still need to follow least privilege.
- Broad east-west access can weaken segmentation between VLANs, users, servers, DMZs, or application zones.
- If a device is compromised, broad internal rules can make lateral movement easier.

This rule only treats the policy as broad when the source address, destination address, or service is actually broad, such as `all`, `all6`, `0.0.0.0/0`, `::/0`, or service `ALL`. Named host objects, named subnet objects, and custom service objects are not treated as broad unless they resolve to a broad object.

Review the policy and restrict the broad element identified above.

Use FortiGate logs, policy hit counts, and traffic analysis to identify the real source addresses, destination addresses, and services using this rule.

Recommended approach:
1. Replace broad source objects with approved source hosts, groups, users, or subnets.
2. Replace broad destination objects with approved destination hosts, groups, or application servers.
3. Replace service `ALL` with the specific required service or service group.
4. Keep the policy scoped to the required internal interfaces, VLANs, or zones.
5. Place the restrictive policy above any broader internal policy.
6. Monitor traffic before disabling or removing the broad rule.

Example configuration:
config firewall policy
edit <policy-id>
set srcintf "<source-internal-interface-or-zone>"
set dstintf "<destination-internal-interface-or-zone>"
set action accept
set srcaddr "<approved-source-object>"
set dstaddr "<approved-destination-object>"
set service "<approved-service-or-service-group>"
set schedule "always"
next
end

This IPsec phase 1 configuration allows one or more weak or legacy cryptographic proposals.

IPsec phase 1 proposals define the encryption and integrity algorithms that may be negotiated when establishing the VPN control channel. If weak proposals are left enabled, a peer may be able to negotiate outdated cryptography even when stronger options are also present.

Legacy algorithms such as DES, 3DES, SEED, MD5, and SHA-1 should not be used for new VPN deployments. These algorithms provide weaker protection than modern alternatives and may not meet current security, compliance, or vendor hardening expectations. VPN phase 1 should use approved modern proposals such as AES or ChaCha20-Poly1305 with SHA-256, SHA-384, SHA-512, or equivalent stronger PRF/integrity options.

Remove weak or legacy proposals from the IPsec phase 1 configuration.

Review the VPN peer requirements before making the change, especially for third-party or legacy site-to-site VPNs. Confirm that both ends of the tunnel support modern proposals, then update the phase 1 proposal list so that only approved cryptographic suites remain.

Recommended options normally include AES-128 or AES-256 with SHA-256 or stronger, AES-GCM with SHA-256 or stronger PRF, or ChaCha20-Poly1305 with SHA-256 or stronger PRF where supported. Avoid DES, 3DES, SEED, MD5, and SHA-1 based proposals.

After applying the change, re-establish the VPN tunnel and confirm that phase 1 negotiation succeeds using an approved proposal.

Example configuration:
config vpn ipsec phase1-interface
edit <entry-name>
set proposal aes256-sha256 aes128-sha256
next
end

VDOM 'root' allows weak SSL VPN cryptographic settings. The configured minimum TLS version is 'tls1-0' and the configured SSL VPN algorithm is 'medium'. Weak protocol or cipher settings can expose remote access VPN users and authentication traffic to obsolete cryptographic behaviour.

Configure SSL VPN to use TLS 1.2 or newer and high-strength cipher settings.

Recommended configuration:
config vpn ssl settings
set ssl-min-proto-ver tls1-2
set algorithm high
end

Also review any SSL VPN authentication rules and avoid rule-level cipher settings of 'any' or 'medium'. After applying the change, test approved FortiClient and browser-based access methods to confirm they still connect successfully.

VDOM 'root' uses a missing, default, factory, or self-signed SSL VPN server certificate on a WAN-facing listener. This can weaken user trust, increase certificate warning behaviour, and make it harder for users to verify that they are connecting to the legitimate remote access VPN service.

Install and select an approved SSL VPN server certificate issued for the VPN hostname.

Recommended configuration:
config vpn ssl settings
set servercert "<approved-vpn-server-certificate>"
set server-hostname "vpn.example.com"
end

After applying the change, confirm that the certificate chain is trusted by managed clients, the certificate name matches the VPN hostname, and SSL VPN users can connect without certificate warnings.

VDOM 'root' exposes SSL VPN on WAN-facing interface(s) wan1 without clear source-address restrictions. This may be intentional, but it increases the public attack surface for remote access authentication, vulnerability probing, credential stuffing, and brute-force attempts.

Restrict SSL VPN exposure to approved ingress interfaces and trusted source addresses where operationally possible.

Recommended configuration:
config vpn ssl settings
set source-interface "<approved-ingress-interface>"
set source-address "<trusted-remote-source>"
config authentication-rule
edit 1
set source-address "<trusted-remote-source>"
next
end
end

If broad internet exposure is required, document the exception and compensate with MFA, strong authentication, account lockout controls, geo/IP filtering where appropriate, logging, monitoring, and regular review of SSL VPN access.

The FortiGate administrator idle timeout is missing or set higher than 10 minutes, allowing inactive management sessions to remain open for longer than necessary. Long-lived idle sessions increase the risk of unauthorized access from an unattended workstation, shared admin jump host, browser left open, or compromised administrator endpoint.

Set the administrator idle timeout to 10 minutes or less.

Recommended configuration:
config system global
set admintimeout 10
end

After applying the change, confirm that administrator sessions expire after the expected idle period and that operational processes do not rely on unattended management sessions staying open.

Diffie-Hellman parameters are configured below the expected minimum strength. The current value is 1024 bits. FortiGate uses this setting for Diffie-Hellman exchange strength for HTTPS and SSH protocols, and values below 2048 bits do not meet the expected baseline.

Raise Diffie-Hellman parameters to at least 2048 bits, or higher if required by your approved cryptographic baseline.

Recommended checks:
- Use at least 2048-bit Diffie-Hellman parameters.
- Consider 3072 or 4096 bits where performance and policy requirements allow.
- Confirm administrator HTTPS and SSH access continue to work after the change.
- Document any legacy compatibility exception if a lower value is required.

Example configuration:
config system global
set dh-params 2048
end

Stronger example:
config system global
set dh-params 4096
end

Denied firewall traffic and/or local-in traffic visibility is not fully enabled or is not being sent to an enabled logging destination. Without these logs, denied connection attempts, traffic aimed directly at the FortiGate, management-plane probing, and policy troubleshooting evidence may be missing during security review or incident response.

Enable logging for implicit-deny firewall policy traffic and local-in/local-traffic events, and make sure at least one retained logging destination is enabled and configured.

Recommended global visibility configuration:
config log setting
set fwpolicy-implicit-log enable
set local-in-allow enable
set local-in-deny-unicast enable
set local-in-deny-broadcast enable
end

Example syslog destination and local-traffic filter:
config log syslogd setting
set status enable
set server "192.0.2.50"
end
config log syslogd filter
set local-traffic enable
end

If using FortiAnalyzer, FortiAnalyzer Cloud, disk, or memory logging instead, confirm that the destination is enabled and that local-traffic logging is not filtered out. After changing the settings, generate a test denied connection and a test local-in event, then confirm both appear in the approved logging destination.

NTP time synchronisation is disabled or not fully enabled, which can make FortiGate log timestamps and security event timelines unreliable.

Enable NTP time synchronisation using either FortiGuard or approved internal/external NTP servers.

Example configuration using FortiGuard:
config system ntp
set ntpsync enable
set type fortiguard
end

Example configuration using explicit NTP servers:
config system ntp
set ntpsync enable
set type custom
config ntpserver
edit 1
set server "192.0.2.10"
next
edit 2
set server "192.0.2.11"
next
end
end

After applying the change, confirm that the FortiGate has the correct time, timezone, and NTP synchronisation status.

The FortiGate DNS resolver configuration does not show a configured DNS server. DNS is required for hostname resolution, FortiGuard lookups, FQDN address objects, update checks, logging destinations, certificate-related services, and other security functions that depend on name resolution.

Configure at least one DNS server under system DNS settings. A primary DNS server should be configured, and a secondary DNS server should be configured where possible for resilience.

Recommended configuration:
config system dns
set primary 8.8.8.8
set secondary 8.8.4.4
end

Use DNS servers approved for the environment, such as internal enterprise DNS resolvers, approved security DNS resolvers, or the FortiGuard default DNS service where that is the intended design.

After applying the change, confirm that the FortiGate can resolve hostnames and that FortiGuard, FQDN address objects, updates, logging integrations, and other DNS-dependent services operate correctly.

FortiGuard antivirus definition scheduled updates are disabled. Without scheduled updates, antivirus and related FortiGuard security databases may become stale.

Enable scheduled FortiGuard updates and set the update frequency to automatic.

Recommended configuration:
config system autoupdate schedule
set status enable
set frequency automatic
end

After applying the change, confirm that the FortiGate can reach FortiGuard update services and that antivirus definitions update successfully.

The firewall is running FortiOS 7.2.11, but Fortinet currently recommends FortiOS 7.4.11 for FortiGate 90E.

Review the Fortinet release notes, supported upgrade path, known issues and change requirements. Plan an upgrade to FortiOS 7.4.11 unless Fortinet TAC or an approved internal exception requires a different release.

IPv4 implicit firewall policy deny logging is disabled.

IPv6 implicit firewall policy deny logging is also disabled.

Traffic denied by the IPv4 or IPv6 implicit firewall policies may therefore not be recorded. Implicit deny logging provides visibility into traffic that reaches the end of the firewall rulebase without matching an explicit policy. Missing implicit deny logging can reduce visibility into denied connection attempts, policy misconfiguration, scanning activity, unauthorized access attempts, and other unexpected traffic.

Enable IPv4 implicit firewall policy deny logging.

Recommended IPv4 configuration:
config log setting
set fwpolicy-implicit-log enable
end

Enable IPv6 implicit firewall policy deny logging.

Recommended IPv6 configuration:
config log setting
set fwpolicy6-implicit-log enable
end

After applying the changes, generate controlled denied IPv4 and IPv6 traffic and confirm that the implicit deny events appear in the approved logging destination.

This Application Control profile does not block applications detected on non-default ports. Applications using unexpected ports can indicate evasive behaviour, misconfiguration, or attempted policy bypass.

Enable default application port enforcement on the Application Control profile.

Recommended configuration:
config application list
edit "profile-name"
set enforce-default-app-port enable
next
end

After applying the change, confirm that firewall policies using this Application Control profile continue to allow expected applications on standard ports and block applications detected on non-default ports.

This custom Antivirus profile does not have outbreak prevention set to block for the following protocol sections:
- FTP
- SMTP

Outbreak prevention uses FortiGuard outbreak protection information to provide additional protection against newly identified malware and emerging threats before conventional antivirus signatures may be available.

Enable outbreak prevention blocking on the non-compliant protocol sections of this custom Antivirus profile.

Recommended configuration:
config antivirus profile
edit "CUSTOM-AV-TEST"
config ftp
set outbreak-prevention block
end
config smtp
set outbreak-prevention block
end
next
end

The accepted firewall policy does not have traffic logging enabled. Without logging on accepted policies, allowed sessions may not leave enough evidence for troubleshooting, security monitoring, incident investigation, user activity review, or validation of whether the rule is still required.

Enable traffic logging on accepted firewall policies.

Recommended configuration:
config firewall policy
edit <policy-id>
set logtraffic all
next
end

Where session start visibility is also required, enable start-of-session logging as well:
config firewall policy
edit <policy-id>
set logtraffic all
set logtraffic-start enable
next
end

If only end-of-session logging is required for a specific low-risk rule, use `set logtraffic all` and document the exception.

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 2 (Broad Outbound Internet Access - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 2 (Broad Outbound Internet Access - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 4 (Shadowed firewall policies - Test Rule 1).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 2 (Broad Outbound Internet Access - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 4 (Shadowed firewall policies - Test Rule 1).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

The firewall policy duplicates earlier enabled policy 1 (Any/Any/Any - Test Rule).

Merge duplicate policies into a single canonical rule and remove the extra entries after validating behavior.

Example configuration:
config firewall policy
edit <duplicate-policy-id>
set status disable
next
delete <duplicate-policy-id>
end

This enabled internet-bound firewall policy allows HTTP or HTTPS based web traffic without a web filtering profile.

Result:
- The policy does not have a direct webfilter-profile configured.
- If the policy uses a profile group, the referenced profile group does not include a webfilter-profile.

Why this matters:
- Without web filtering on outbound web access, users or systems may be able to reach malicious, newly registered, inappropriate, uncategorized, or policy-prohibited websites without category-based controls.

Apply an approved web filtering profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set webfilter-profile "<approved-web-filter-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set webfilter-profile "<approved-web-filter-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

If web filtering is intentionally excluded for a specific web policy, document the exception and ensure compensating controls such as strict destination scope, DNS filtering, application control, IPS, SSL inspection, logging, and monitoring are applied.

This enabled internet-bound firewall policy allows HTTP or HTTPS based web traffic without a web filtering profile.

Result:
- The policy does not have a direct webfilter-profile configured.
- If the policy uses a profile group, the referenced profile group does not include a webfilter-profile.

Why this matters:
- Without web filtering on outbound web access, users or systems may be able to reach malicious, newly registered, inappropriate, uncategorized, or policy-prohibited websites without category-based controls.

Apply an approved web filtering profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set webfilter-profile "<approved-web-filter-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set webfilter-profile "<approved-web-filter-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

If web filtering is intentionally excluded for a specific web policy, document the exception and ensure compensating controls such as strict destination scope, DNS filtering, application control, IPS, SSL inspection, logging, and monitoring are applied.

This enabled internet-bound firewall policy allows HTTP or HTTPS based web traffic without a web filtering profile.

Result:
- The policy does not have a direct webfilter-profile configured.
- If the policy uses a profile group, the referenced profile group does not include a webfilter-profile.

Why this matters:
- Without web filtering on outbound web access, users or systems may be able to reach malicious, newly registered, inappropriate, uncategorized, or policy-prohibited websites without category-based controls.

Apply an approved web filtering profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set webfilter-profile "<approved-web-filter-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set webfilter-profile "<approved-web-filter-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

If web filtering is intentionally excluded for a specific web policy, document the exception and ensure compensating controls such as strict destination scope, DNS filtering, application control, IPS, SSL inspection, logging, and monitoring are applied.

This enabled internet-bound firewall policy allows HTTP or HTTPS based web traffic without a web filtering profile.

Result:
- The policy does not have a direct webfilter-profile configured.
- If the policy uses a profile group, the referenced profile group does not include a webfilter-profile.

Why this matters:
- Without web filtering on outbound web access, users or systems may be able to reach malicious, newly registered, inappropriate, uncategorized, or policy-prohibited websites without category-based controls.

Apply an approved web filtering profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set webfilter-profile "<approved-web-filter-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set webfilter-profile "<approved-web-filter-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

If web filtering is intentionally excluded for a specific web policy, document the exception and ensure compensating controls such as strict destination scope, DNS filtering, application control, IPS, SSL inspection, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This inbound internet-facing firewall policy allows traffic without an application control profile.

Internet-source evidence:
- isInternetInboundPolicy source classification

Result:
- The policy does not have an application-list set directly.
- If the policy uses a profile group, the referenced profile group does not include an application-list.

Why this matters:
- Inbound policies from internet-facing sources are exposed to untrusted traffic.
- Missing application control reduces visibility and enforcement for application behaviour, risky protocols, evasive application usage, and traffic that may not be adequately controlled by port-based rules alone.

Enable UTM inspection and attach an approved application control profile either directly on the firewall policy or through the referenced profile group.

Recommended direct policy configuration:
config firewall policy
edit <policy-id>
set utm-status enable
set application-list "<approved-application-control-profile>"
next
end

Recommended profile group configuration:
config firewall profile-group
edit "<profile-group-name>"
set application-list "<approved-application-control-profile>"
next
end
config firewall policy
edit <policy-id>
set profile-type group
set profile-group "<profile-group-name>"
next
end

Use a profile appropriate to the published service or inbound access path. If application control is not technically suitable for a specific inbound rule, document the exception and ensure compensating controls such as IPS, web application protection, strict service definitions, source restrictions, logging, and monitoring are applied.

This DNS Filter profile does not log all DNS queries and responses. Without detailed DNS query logging, threat hunting, incident response, and investigation activity may have reduced DNS visibility.

Enable logging of all DNS queries and responses on the DNS Filter profile.

Recommended configuration:
config dnsfilter profile
edit "profile-name"
set log-all-domain enable
next
end

After applying the change, confirm that firewall policies using DNS Filter profiles are logging DNS query and response activity as expected.

This enabled allow policy permits DNS traffic but UTM inspection is not enabled, so DNS Filter inspection will not be applied.

Enable UTM inspection and apply a DNS Filter profile to policies that permit DNS traffic.

Recommended configuration:
config firewall policy
edit "<policy-id>"
set utm-status enable
set dnsfilter-profile "<dns-filter-profile>"
next
end

This should be applied to any policy that allows DNS traffic, including internal DNS forwarding policies and internet-bound DNS policies.

This enabled allow policy permits DNS traffic but UTM inspection is not enabled, so DNS Filter inspection will not be applied.

Enable UTM inspection and apply a DNS Filter profile to policies that permit DNS traffic.

Recommended configuration:
config firewall policy
edit "<policy-id>"
set utm-status enable
set dnsfilter-profile "<dns-filter-profile>"
next
end

This should be applied to any policy that allows DNS traffic, including internal DNS forwarding policies and internet-bound DNS policies.

This enabled allow policy permits DNS traffic but UTM inspection is not enabled, so DNS Filter inspection will not be applied.

Enable UTM inspection and apply a DNS Filter profile to policies that permit DNS traffic.

Recommended configuration:
config firewall policy
edit "<policy-id>"
set utm-status enable
set dnsfilter-profile "<dns-filter-profile>"
next
end

This should be applied to any policy that allows DNS traffic, including internal DNS forwarding policies and internet-bound DNS policies.

This enabled allow policy permits DNS traffic but UTM inspection is not enabled, so DNS Filter inspection will not be applied.

Enable UTM inspection and apply a DNS Filter profile to policies that permit DNS traffic.

Recommended configuration:
config firewall policy
edit "<policy-id>"
set utm-status enable
set dnsfilter-profile "<dns-filter-profile>"
next
end

This should be applied to any policy that allows DNS traffic, including internal DNS forwarding policies and internet-bound DNS policies.

This enabled allow policy permits DNS traffic but UTM inspection is not enabled, so DNS Filter inspection will not be applied.

Enable UTM inspection and apply a DNS Filter profile to policies that permit DNS traffic.

Recommended configuration:
config firewall policy
edit "<policy-id>"
set utm-status enable
set dnsfilter-profile "<dns-filter-profile>"
next
end

This should be applied to any policy that allows DNS traffic, including internal DNS forwarding policies and internet-bound DNS policies.

This enabled accepted firewall policy uses an overly broad service definition. Allowing ALL or a very large set of ports and protocols can expose more services than the business requirement needs, weaken segmentation, increase attack surface, and make it harder to understand what traffic the rule actually permits.

Restrict the firewall policy to the exact required services, ports, and protocols. Replace ALL or oversized service groups with a smaller approved service object or service group that matches the documented business requirement.

Recommended configuration:
config firewall policy
edit <policy-id>
set service "<required-service-or-service-group>"
next
end

If a broad service group is temporarily required, document the justification, limit the source and destination as tightly as possible, enable logging, apply the appropriate security profiles, and review the exception regularly until the service scope can be reduced.

This enabled accepted firewall policy uses an overly broad service definition. Allowing ALL or a very large set of ports and protocols can expose more services than the business requirement needs, weaken segmentation, increase attack surface, and make it harder to understand what traffic the rule actually permits.

Restrict the firewall policy to the exact required services, ports, and protocols. Replace ALL or oversized service groups with a smaller approved service object or service group that matches the documented business requirement.

Recommended configuration:
config firewall policy
edit <policy-id>
set service "<required-service-or-service-group>"
next
end

If a broad service group is temporarily required, document the justification, limit the source and destination as tightly as possible, enable logging, apply the appropriate security profiles, and review the exception regularly until the service scope can be reduced.

This enabled accepted firewall policy uses an overly broad service definition. Allowing ALL or a very large set of ports and protocols can expose more services than the business requirement needs, weaken segmentation, increase attack surface, and make it harder to understand what traffic the rule actually permits.

Restrict the firewall policy to the exact required services, ports, and protocols. Replace ALL or oversized service groups with a smaller approved service object or service group that matches the documented business requirement.

Recommended configuration:
config firewall policy
edit <policy-id>
set service "<required-service-or-service-group>"
next
end

If a broad service group is temporarily required, document the justification, limit the source and destination as tightly as possible, enable logging, apply the appropriate security profiles, and review the exception regularly until the service scope can be reduced.

No clear external configuration backup method was detected in the firewall configuration export. This does not prove backups are missing, but the exported configuration does not show FortiManager registration or an obvious on-box automation/scripted backup method that would preserve configuration history outside the firewall.

Confirm that configuration backups are scheduled and recoverable in FortiManager, FortiGate Cloud, automation stitches, a configuration management platform, or an external backup system.

Recommended checks:
- Confirm backups run on a defined schedule.
- Confirm backups are stored outside the firewall.
- Confirm backup access is restricted.
- Confirm restore testing is performed periodically.
- Confirm backup retention meets operational and compliance requirements.

Example FortiManager configuration:
config system central-management
set type fortimanager
set fmg "192.0.2.50"
end

Example on-box scripted backup:
config system auto-script
edit "nightly-config-backup"
set interval 86400
set repeat 0
set script "execute backup config ftp backup.conf 192.0.2.50 backupuser <password>"
next
end

If FortiManager or another external platform performs backups, document the backup schedule, storage location, retention period, and restore test evidence.

Firewall policy 2 (Broad Outbound Internet Access - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 3 (VIP Sensitive Services - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 4 (Shadowed firewall policies - Test Rule 1) appears shadowed by 2 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 2 (Broad Outbound Internet Access - Test Rule)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 5 (Shadowed firewall policies - Test Rule 2) appears shadowed by 3 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 2 (Broad Outbound Internet Access - Test Rule)
- policy 4 (Shadowed firewall policies - Test Rule 1)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 6 (Direct Internet to Cardholder Data Environment (CDE) - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 7 (Restrict cleartext services in firewall policies - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 8 (Require traffic logging on accepted firewall policies - Test Rule) appears shadowed by 3 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 2 (Broad Outbound Internet Access - Test Rule)
- policy 4 (Shadowed firewall policies - Test Rule 1)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 9 (Missing Anti-Spoofing Protection IPv4 - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 10 (Missing Anti-Spoofing Protection IPv6 - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 11 (Restrict permissive inbound management and database services - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 12 (TEMP vendor HTTPS access) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

Firewall policy 13 appears shadowed by 2 earlier enabled policies.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)
- policy 12 (TEMP vendor HTTPS access)

This policy may never match because multiple earlier enabled accept policies appear to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policies if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policies if the later policy is intentional and should take precedence.

Firewall policy 14 (PSIRT: Proxy-mode HTTP/2 deep-inspection buffer overflow - Test Rule) appears shadowed by 1 earlier enabled policy.

Shadowing policy found:
- policy 1 (Any/Any/Any - Test Rule)

This policy may never match because an earlier enabled accept policy appears to cover the same source, destination, service or internet-service selector, schedule, and interface path.

Review the rule order and remove, narrow, disable, or move the broader earlier policy if this later policy is still required.

Example remediation:
config firewall policy
edit <broader-policy-id>
set srcaddr <more-specific-source>
set dstaddr <more-specific-destination>
set service <more-specific-service>
next
end

Alternatively, move the specific policy above the broader policy if the later policy is intentional and should take precedence.

No entries found in looped configuration section: config vpn ipsec phase2-interface