FortiOS-7.4.0-New_Features_Guide801-850
FortiOS-7.4.0-New_Features_Guide801-850
--
OT Detect Definitions
---------
Version: 0.00000
Contract Expiry Date: Sat Sep 16 2023
Last Updated using manual update on Mon Jan 1 00:00:00 2001
Last Update Attempt: Mon Aug 14 15:42:43 2023
Result: No Updates
OT Patch Definitions
---------
Version: 0.00000
Contract Expiry Date: Sat Sep 16 2023
Last Updated using manual update on Mon Jan 1 00:00:00 2001
OT Threat Definitions
Users upgrading to 7.4.1 from previous FortiOS versions with an Industrial Security Service entitlement will continue to
receive the OT Security Service entitlement. The existing Industrial Attack Definitions have been renamed OT Threat
Definitions. These definitions include both application control and IPS signatures for OT applications and protocols.
4. The Confirm dialog opens, noting that This will enable operational technology signatures globally. Are you sure you
wish to proceed? Click OK.
5. Select the action from the dropdown for the Operational Technology category.
In FortiOS 7.4.1 and later, the Industrial category is renamed to Operational Technology.
When the automatic firmware updates setting is enabled, in addition to an automatic federated upgrade being performed
on the FortiGate, automatic federated upgrades are now performed on any managed FortiAPs and FortiSwitches. The
federated upgrades of these LAN edge devices adhere to the FortiOS-FortiAP and FortiOS-FortiSwitch compatibility
matrix information maintained on the FortiGuard Distribution Network (FDN).
Example 1: FortiAP
In this example, automatic firmware updates are enabled on a FortiGate that is running 7.4.0. The FortiGate and two
FortiAPs with older firmware are upgraded after the federated update.
The auto-upgrade time is scheduled daily, between 5:00 p.m. and 7:00 p.m.
Example 2: FortiSwitch
In this example, automatic firmware updates are enabled on a FortiGate that is running 7.4.1. Two FortiSwitches with
older firmware are upgraded after the federated update.
The auto-upgrade time is scheduled on Tuesday, between 11:00 a.m. and 12:00 p.m.
The Internet assigned numbers authority (IANA) timezone database is downloadable from the FortiGuard server,
instead of being embedded within the FortiOS image. This allows the FortiGate to automatically refresh its timezone
database, eliminating the need to wait for the next image release to access new or updated timezones.
For more information about this feature, see Streamline timezone updates with a downloadable database.
Certificates
This section includes information about certificate system related new features:
l Support Enrollment over Secure Transport for automatic certificate management 7.4.1 on page 809
The FortiGate supports Enrollment over Secure Transport (EST) and the RFC 7030 standards when generating a new
CSR request, performing automatic renewals, or manually regenerating a certificate. EST provides more security for
automatic certificate management than Simple Certificate Enrollment Protocol (SCEP), which is commonly used for
certificate enrollment.
Background
SCEP helps automate and simplify the process for obtaining a digital certificate from a certificate authority (CA).
However, SCEP does not natively support secure connections, and instead relies on the underlying transport protocol to
provide security. EST was developed, which uses TLS to establish a secure communication channel over which
subsequent certificate management protocol messages like initial certificate enroll and certificate renewal messages are
exchanged.
On the FortiGate, when generating a certificate signing request (CSR), you can use the SCEP method to send the
request to an SCEP server, or use EST to send the request to an EST server to be signed by a CA.
est-server <string> Enter the address and port for EST server (such as https://example.com:1234).
est-ca-id <string> Enter the CA identifier of the CA server for signing with EST.
est-http-username Enter the HTTP Authentication username for signing with EST.
<string>
est-http-password Enter the HTTP Authentication password for signing with EST.
<string>
est-client-cert Enter the certificate used to authenticate this FortiGate to the EST server.
<certificate>
est-server-cert Enter the EST server's certificate that has to be verifiable by the specified
<certificate> certificate on the FortiGate.
est-srp-username <string> Enter the EST SRP authentication username.
est-srp-password <string> Enter the EST SRP authentication password.
# execute vpn certificate local generate est {reqired_1} {reqired_2} {reqired_3} [options]
option 3 (required) URL and listening port of the remote EST responder.
option 4 (optional) Server certificate subject in the certificate enroll request. Separate fields by a
comma (,).
option 5 (optional) Subject Alternative Name (SAN). This can be an FQDN and/or IP. Use
DNS:<FQDN>,IP:<IP_address> for example. If the issuing CA does not support
SAN, this option will be ignored. Separate fields by a comma (,).
option 9 (optional) CA certificate used to verify the remote EST responder server certificate and
certificates issued by a remote PKI.
1. Verify that the FortiGate can communicate with remote EST responder (testrfc7030.com):
# execute ping testrfc7030.com
PING testrfc7030.com (54.70.32.33): 56 data bytes
64 bytes from 54.70.32.33: icmp_seq=0 ttl=31 time=13.6 ms
64 bytes from 54.70.32.33: icmp_seq=1 ttl=31 time=19.1 ms
64 bytes from 54.70.32.33: icmp_seq=2 ttl=31 time=16.5 ms
^C
--- testrfc7030.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 13.6/16.4/19.1 ms
3. Create a new server CSR file locally and send it to the remote EST responder:
# execute vpn certificate local generate est est-test101 ec-secp256r1
https://testrfc7030.com:8443 CN=firewall-portal1,DC=local,DC=COM DNS:firewall-
portal1.local.ca,IP:172.18.60.184 estuser estpwd G_CA_Cert_1
The CA certificate (G_CA_Cert_1) is used to verify the remote EST responder server
certificate and certificates issued by a remote PKI.
testrfc7030.com is a self-signed CA, which by default is not in the local trusted root store
and must be imported prior to enrollment.
If the CA that issues the server certificate is not in the local root store, an error would
appear in the debug messages:
# diagnose debug application est -1
# diagnose debug enable
...
[1795] est_curl_req: Error buf: SSL certificate problem: self-signed
certificate in certificate chain,
[2402] est_simple_enroll: Failed to get ca certs: -1.
...
4. If the enrollment was successful, in a few seconds, a Done message appears. Verify the debugs to view the
enrollment process.
a. The remote CA's certificate is retrieved and stored locally in the EST configuration after being verified with the
CA in the trusted root store:
[1962] __est_curl_set_auth: trace
[2046] __est_curl_set_auth: HTTP Authentication username is set
[2050] __est_curl_set_auth: HTTP Authentication password is set
[2075] __est_get_ca_certs: ============STARTED============
[1728] est_curl_req: URL: https://testrfc7030.com:8443/.well-known/est/cacerts
[1776] est_curl_req: HTTP GET
[143] __curl_ssl_ctx_finalizer: global CAs are loaded.
c. The CA certificate is imported. FortiOS sends a query to learn about the attributes supported by the CA in the
certificate request and will then create the CSR accordingly:
[1288] save_pkcs7_certs: CA certs imported!
[2101] __est_get_csr_attrs: ============STARTED============
[1728] est_curl_req: URL: https://testrfc7030.com:8443/.well-known/est/csrattrs
[1776] est_curl_req: HTTP GET
[1651] curl_header_debug_func: Header received:HTTP/1.1 200 OK
[1651] curl_header_debug_func: Header received:Status: 200 OK
[1651] curl_header_debug_func: Header received:Content-Type: application/csrattrs
[1651] curl_header_debug_func: Header received:Content-Transfer-Encoding: base64
[1651] curl_header_debug_func: Header received:Content-Length: 57
[1651] curl_header_debug_func: Header received:
[1787] est_curl_req: Response 200
[1788] est_curl_req: Buffer:MCYGBysGAQEBARYGCSqGSIb3DQEJAQYFK4EEACIGCWCGSAFlAwQCAg==
[1439] decode_csrattrs_callback: Decoding csrattrs, resp->len: 57
[1474] decode_csrattrs_callback: Object: 1.3.6.1.1.1.1.22 undefined
[1474] decode_csrattrs_callback: Object: 1.2.840.113549.1.9.1 emailAddress
[1474] decode_csrattrs_callback: Object: 1.3.132.0.34 secp384r1
[1474] decode_csrattrs_callback: Object: 2.16.840.1.101.3.4.2.2 sha384
d. The CSR information is generated, which is sent to the remote EST responder:
est_ctx: is_global:1
vfid:0
svr_original_url:https://testrfc7030.com:8443
svr_hostinfo:Exists
ca_identifier:(null)
http_username:estuser
http_password:estpwd
clt_cert:(null)
svr_cert:(null)
srp_username:(null)
srp_password:(null)
source_ip:(null)
need_pop:0
newcert_name:est-test101
passwd:(null)
rsa_keysize:0
ec_curvename:secp256r1
subject:CN=firewall-portal1,DC=local,DC=COM
sub_alt_name:DNS:firewall-portal1.local.ca,IP:172.18.60.184
svr_cert_x509:NULL
csr_attrs:Exists
csr:NULL
pkey:NULL
header_ptr:NULL
tmp_p10:NULL
[2259] __est_simple_enroll: ============STARTED============
g. The FortiGate decodes and displays the attributes of the certificate, then saves the certificate:
[1191] save_pkcs7_certs: Saving pkcs7 response
[505] est_print_pkcs7: Certs: (1 in total)
[507] est_print_pkcs7: Cert 1:
[427] est_print_x509: Version: 3 (0x2)
Serial Number: 476823 (0x74697)
Issuer: CN=estExampleCA
Subject: CN=firewall-portal1
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature
X509v3 Subject Key Identifier:
9B:F8:39:D5:21:E6:FF:49:FF:AC:02:57:5B:FC:4C:1A:8B:1E:5D:8F
X509v3 Authority Key Identifier:
1A:DF:39:84:C2:56:E6:6C:CF:2A:B4:26:A5:FD:0C:D2:43:F5:3D:3E
When the time for certificate renewal is up, the FortiGate will use the existing EST parameters to perform an automatic
renewal. This example demonstrates the renewal process through debugs.
enroll-protocol : est
est-server : https://testrfc7030.com:8443
est-ca-id :
est-http-username : estuser
est-http-password : estpwd
est-client-cert :
est-server-cert :
est-srp-username :
est-srp-password :
auto-regenerate-days: 0
auto-regenerate-days-warning: 0
Note that the current Valid to date and time is 2024-04-05 22:37:34 GMT, which is one year from the issue
date.
2. Start running debugs to track the progress of the renewal:
# diagnose debug application est -1
# diagnose debug enable
3. For demonstration purposes, update the auto-regenerate-days setting to 364 days to trigger the automatic
renewal on the FortiGate:
config vpn certificate local
edit est-test101
set auto-regenerate-days 364
next
end
header_ptr:NULL
tmp_p10:NULL
b. The FortiGate sends the current server certificate for authentication/authorization and not the
username/password used for initial enrollment:
[2453] est_simple_reenroll: Try to use est-test101 as client cert to authenticate
[1962] __est_curl_set_auth: trace
[2011] __est_curl_set_auth: Warning: cert est-test101 may not have the correct key
usage for TLS client authentication
[2014] __est_curl_set_auth: Will use cert est-test101 to prove my identity
...
[1651] curl_header_debug_func: Header received:
[1787] est_curl_req: Response 200
[1788] est_curl_req: Buffer:MCYGBysGAQEBARYGCSqGSIb3DQEJAQYFK4EEACIGCWCGSAFlAwQCAg==
[1439] decode_csrattrs_callback: Decoding csrattrs, resp->len: 57
[1474] decode_csrattrs_callback: Object: 1.3.6.1.1.1.1.22 undefined
[1474] decode_csrattrs_callback: Object: 1.2.840.113549.1.9.1 emailAddress
[1474] decode_csrattrs_callback: Object: 1.3.132.0.34 secp384r1
[1474] decode_csrattrs_callback: Object: 2.16.840.1.101.3.4.2.2 sha384
est_ctx: is_global:1
vfid:0
svr_original_url:https://testrfc7030.com:8443
svr_hostinfo:Exists
ca_identifier:
http_username:estuser
http_password:estpwd
clt_cert:est-test101
svr_cert:
srp_username:
srp_password:
source_ip:(null)
need_pop:0
newcert_name:est-test101
passwd:f51da8548af5fef820edfe6267b0c178e76f7c3eae40ee0900318fc77ab6bd
rsa_keysize:0
ec_curvename:(null)
subject:(null)
sub_alt_name:(null)
svr_cert_x509:NULL
csr_attrs:Exists
csr:NULL
pkey:NULL
header_ptr:NULL
tmp_p10:NULL
[2274] __est_simple_reenroll: ============STARTED============
|||
private-key : *
certificate :
Subject: CN = firewall-portal1
Issuer: CN = estExampleCA
Valid from: 2023-04-06 22:55:09 GMT
Valid to: 2024-04-05 22:55:09 GMT
Fingerprint: D9:51:6C:EF:04:E9:79:8D:A0:EE:10:23:4A:F4:46:B7
Root CA: No
Version: 3
Serial Num:
07:46:a5
Extensions:
Name: X509v3 Basic Constraints
Critical: no
Content:
Note that the Valid to date and time is now 2024-04-05 22:55:09 GMT.
Note that manually regenerating the certificate will not generate a new server key pair.
sub_alt_name:(null)
svr_cert_x509:NULL
csr_attrs:NULL
csr:NULL
pkey:NULL
header_ptr:NULL
tmp_p10:NULL
[2453] est_simple_reenroll: Try to use est-test101 as client cert to authenticate
[1962] __est_curl_set_auth: trace
...
state : OK
range : global
source : user
source-ip : 0.0.0.0
ike-localid-type : asn1dn
enroll-protocol : est
est-server : https://testrfc7030.com:8443
est-ca-id :
est-http-username : estuser
est-http-password : estpwd
est-client-cert :
est-server-cert :
est-srp-username :
est-srp-password :
auto-regenerate-days: 0
auto-regenerate-days-warning: 0
The Subject Key Identifier is the same, so no new key pair was generated.
Security
This section includes information about security system related new features:
l Enhance BIOS-level signature and file integrity checking on page 820
l Real-time file system integrity checking on page 825
l Add built-in entropy source 7.4.1 on page 827
l Unauthorized firmware modification attempt reporting 7.4.1 on page 828
l Enhance file integrity check to perform verification during system bootup 7.4.4 on page 829
l Enhance real-time file system integrity checking 7.4.4 on page 830
l BIOS security Low and High level classification 7.4.6 on page 830
l Enhanced administrator password security 7.4.7 on page 830
The BIOS-level signature and integrity checking has been enhanced by enforcing each FortiOS GA firmware image, AV
engine file, and IPS engine file to be dually-signed by the Fortinet CA and a third-party CA. The BIOS verifies that each
file matches their secure hash as indicated by their certificates. Users are warned when there is a failed integrity check,
and the system may be prevented from booting depending on the severity and the BIOS security level.
Signature checking occurs when the FortiOS firmware, AV, and IPS engine files are uploaded. This allows the FortiGate
to warn users of potential risks involved with uploading an unauthenticated file.
The outcome of the signature and integrity check depends on the security level configured in BIOS and the certificate
authority that signed the file.
The following table summarizes the use cases and the potential outcome based on the security level.
The following examples outline the different use cases when upgrading firmware and AV files on a FortiGate model that
supports BIOS security levels, and a FortiGate model that does not support BIOS security levels.
For more information, see the Firmware and Registration section and Manual updates in the FortiOS Administration
Guide.
The following use cases are applicable when upgrading firmware and AV files on a FortiGate with BIOS security levels.
Firmware is upgraded using the System > Firmware & Registration page, and AV files are upgraded using the System
> FortiGuard page. Fictitious build numbers are used to demonstrate the functionality of this feature.
Level 2
When upgrading from 7.2.4 to 7.4.0 with a dually-signed firmware image, FortiOS verifies the certificates and accepts
the image. The following CLI output shows the messages displayed when a FortiGate is upgraded.
FortiGate_101F (global) # get system status
Version: FortiGate-101F v7.2.4,build1396,230131 (GA.F)
Firmware Signature: certified
Virus-DB: 1.00000(2018-04-09 18:07)
…
FortiGate_101F (global) # Image verification OK!
Firmware upgrade in progress ...
Done.
System is starting...
When upgrading from 7.2.4 to 7.4.0 with an unsigned firmware image in the GUI, FortiOS is unable to verify the
certificates and rejects the image. A notification is displayed that This firmware image didn't pass the signature
verification.
When running 7.4.0 and uploading a dually-signed AV engine file on the System > FortiGuard page, FortiOS verifies the
certificates and accepts the file. A notification is displayed (Successfully upgraded database).
When running 7.4.0 and uploading an unsigned AV engine file on the System > FortiGuard page, FortiOS is unable to
verify the certificates and rejects the file. A notification is displayed that the device Failed to upgrade database.
Level 1
When upgrading from 7.2.4 to 7.4.0 with a dually-signed firmware image, FortiOS verifies the certificates and accepts
the image. No warning is displayed during the upgrade, or while the system is running in 7.4.0.
When upgrading from 7.2.4 to 7.4.0 with an unsigned firmware image in the GUI, FortiOS is unable to verify the
certificates and the image fails verification. The upgrade will still occur. However, during the upgrade process, a warning
dialog is displayed indicating that This firmware failed signature validation. The user can click Continue to upgrade the
firmware.
When the user logs in to the FortiGate running 7.4.0, a warning dialog is displayed indicating that the Installed Firmware
is Not Signed by Fortinet. The user can click I Understand The Risk to log in.
When the FortiGate is running unsigned firmware, warnings appear in the GUI and CLI.
l Top banner: the unsigned firmware version is highlighted in red. Hovering over the unsigned firmware version
displays a tooltip that the Installed firmware is not signed by Fortinet.
l Dashboard > Status > System Information widget: the unsigned firmware version is highlighted in red. Hovering
over the unsigned firmware version displays a tooltip that the Installed firmware is not signed by Fortinet.
When running 7.4.0 and uploading an unsigned AV engine file on the System > FortiGuard page, FortiOS is unable to
verify the certificates and the file fails verification. A warning dialog is displayed indicating that This package file has no
signature for validation, but the user can click OK to use the file.
Level 0
When upgrading from 7.2.4 to 7.4.0 with a dually-signed firmware image, FortiOS verifies the certificates and accepts
the image. No verification is performed.
When upgrading from 7.2.4 to 7.4.0 with an unsigned firmware image in the GUI, FortiOS does not verify the certificates.
No warnings are displayed that the firmware is unverified.
When running 7.4.0 and uploading an unsigned AV engine file on the System > FortiGuard page, FortiOS does not verify
the certificates. No warnings are displayed that the file is unverified.
The following use cases are applicable when upgrading firmware and AV files on a FortiGate without BIOS security
levels. Firmware is upgraded using the System > Firmware & Registration page, and AV files are upgraded using the
System > FortiGuard page. A FortiGate 60E is used in these examples and acts like it has security level 1.
When upgrading from 7.2.4 to 7.4.0 with a dually-signed firmware image, FortiOS verifies the certificates and accepts
the image.
When upgrading from 7.2.4 to 7.4.0 with an unsigned firmware image in the GUI, FortiOS is unable to verify the
certificates and the image fails verification. A warning dialog is displayed indicating that This firmware failed signature
validation, but the user can click Continue to use the firmware.
When running 7.4.0 and uploading an unsigned AV engine file on the System > FortiGuard page, FortiOS is unable to
verify the certificates and the file fails verification. A warning dialog is displayed indicating that This package file has no
signature for validation, but the user can click OK to use the file.
How it works
When the FortiGate boots, the system performs a BIOS level integrity check on important internal files, the AV engine
file, and the IPS engine file. These files are signed by the process described in Enhance BIOS-level signature and file
integrity checking on page 820, and the BIOS verifies their signature against their certificates.
Once these files are verified to be authentic, the BIOS can boot the root filesystem and other executables and libraries.
Once loaded, real-time protection begins. The important executables and binaries are protected from write access and
any modifications. It also blocks the kernel from loading any modules. Any unauthorized loading of modules is blocked. If
violations are found, logs are triggered.
A hash of all executable binaries and libraries is taken and stored in memory. If there is a hash mismatch when
attempting to run a binary, that binary is blocked from running, and the system is rebooted. A log will be generated with
ID 20234.
If there is a missing hash when attempting to run a binary, then the system is rebooted. A log will be generated with ID
20223.
The system also runs a periodic check to verify the integrity of important binaries and AV and IPS engines.
Log summary
The following logs are recorded when specific actions take place.
Log Description
20230 - LOG_ID_SYS_ The root filesystem is read only. Any modification triggers this log.
SECURITY_WRITE_
VIOLATION 432
Log Description
20232 - LOG_ID_SYS_ Only the kernel can load modules. Any unusual loading of modules triggers this
SECURITY_LOAD_MODULE_ log.
VIOLATION 433
20233 - LOG_ID_SYS_ File hashes are generated for legitimate files during bootup. If a hash cannot be
SECURITY_FILE_HASH_ found, the file may be suspicious as it could be a new routine inserted by an
MISSING 434 attacker. The binary is blocked.
20234 - LOG_ID_SYS_ File hashes are generated for legitimate files during bootup. If a hash does not
SECURITY_FILE_HASH_ match when the file is exercised, it is an indication that it could have been
MISMATCH 434 modified by an attacker. The system is rebooted.
Detection examples
Corrective action
In the previous examples where a mismatched or missing hash occurs, alert technical support straight away so that they
may gather information to start a forensic analysis with our internal PSIRT team. There are two possible outcomes:
1. The firewall is reporting a false positive, in which a bug causes a mismatched or missing hash.
Once verified by technical support, the corrective action may to be upgrade to a newer build where the bug is fixed
2. An actual compromise has occurred, or is occurring.
The system could be blocking an offending binary that causes the system to malfunction, or the system could reboot
to protect itself from compromise.
In either case, contact technical support for further forensic analysis. If an IoC is detected and it is determined that the
persistent threat resides on the FortiGate, a reflash and reload of the firmware may be recommended.
FortiOS includes a built-in entropy source, which eliminates the need for a physical USB entropy token when booting up
in FIPS mode on any platform. This enhancement continues to meet the requirements of FIPS 140-3 Certification by
changing the source of entropy to CPU jitter entropy.
Initializing firewall...
System is starting...
3 logs found.
3 logs returned.
This enhancement improves upon the Real-time file system integrity checking feature by implementing an automatic
reporting mechanism in the event of a firmware modification attempt. In the rare event that unauthorized modification is
detected in the firmware, the system will immediately log and report the modification attempt to FortiGuard through a
secure channel. Payloads are encrypted to ensure the security of the transferred information. Information about the
attempted modification of firmware helps Fortinet Inc. proactively investigate the incident and protect future malicious
attempts at compromising the system.
After reporting the modification attempt, the FortiGate real-time file system integrity checking feature continues with the
required actions based on the assessed threat. This may involve reverting the change and rebooting the firewall to
mitigate the threat.
Example
This example demonstrates when an attempt to alter files in the 'bin' directory was made by a threat actor.
Captured log:
The FortiGate sends an encrypted report to FortiGuard with information about the affected platform and the Modification
Attempt such as:
l FortiGate serial number
l Model number
l FortiOS firmware
l Type of modification attempt (such as Write violation)
l File path (such as /bin/lspci)
l File size
l Time of access and modification
Enhance file integrity check to perform verification during system bootup - 7.4.4
This enhancement improves upon previous BIOS-level and real-time file integrity checks by requiring the kernel to verify
the signed hashes of important file-system and object files during bootup. This prevents unauthorized changes to file-
systems to be mounted and other unauthorized objects to be loaded into user space on bootup.
This verification does not depend on the security level of the device. The verification will always run when the firmware
image type is a GA, SA, Beta, or Top3 image. If the signed hash verification fails, the system will halt during bootup.
This enhancement supplements previous security measures to validate the firmware, AV, and IPS packages in the BIOS
(see Enhance BIOS-level signature and file integrity checking), as well as performing real-time binary and executable
integrity checks in user space (see Real-time file system integrity checking).
Example
Upon detection of an altered IPS library file upon bootup, the system will halt as follows:
FortiGate-60E (18:03-01.27.2017)
Ver:05000012
Serial number: FGT60ETK1804xxxx
CPU: 1000MHz
Total RAM: 2 GB
Initializing boot device...
Initializing MAC... nplite#0
Please wait for OS to boot, or press any key to display configuration menu......
Booting OS...
Reading boot image... 2891501 bytes.
Initializing firewall...
fos_ima: System Integrity check failed....
CPU3: stopping
CPU1: stopping
CPU0: stopping
The exact display in the CLI may vary depending on the model of device, security level, or
reasons for the failed verification.
In this enhancement, a hash of all executable binary files and shared libraries are taken during image build time. The file
containing these hashes, called the executable hash, is also hashed. This new hash is signed together with other
important files like the FortiOS firmware, AV and IPS engine files. This hash will follow the BIOS-level signature and
integrity check during the boot process, to prevent any unauthorized changes from being loaded.
Once the integrity of the hash is verified, the corresponding hashes of every executable and shared library can be
extracted from the executable hash and loaded into memory. When each executable and shared library is initialized, it
will be verified against its respective hashes to ensure integrity. If any mismatch is found, the real-time file system
integrity checking action will be taken, either by printing error messages or rebooting the system.
Additionally, files that are not in the list of executable and shared library will have executable permissions removed.
Permissions for changing the executability of any files is also locked.
The BIOS security level has been updated from levels 0/1/2 to levels Low and High. Level High will correspond to
previous behaviors in level 2, and level Low will correspond to behaviors in level 1. A BIOS that still uses levels 0 will now
behave like level Low.
For more information about this feature, see BIOS security Low and High level classification.
The PBKDF2 hashing scheme with randomized salts is now used to store system administrator passwords on the
FortiGate to enhance security. Previously the SHA256 hashing algorithm was used.
With this change, a new command is available to maintain FortiOS downgrade:
For more information about this feature, see Enhanced administrator password security.
Security Fabric
This section includes information about Security Fabric related new features:
l Fabric settings and connectors on page 832
l External SDN connectors on page 845
l Security ratings on page 846
l Automation on page 850
l Asset Identity Center on page 857
This section includes information about Security Fabric settings and Fabric connector related new features:
l MAC address threat feed on page 832
l Configuring FortiClient EMS and FortiClient EMS Cloud on a per-VDOM basis on page 834
l Update FortiVoice connector features 7.4.1 on page 836
l Support for FortiVoice tag dynamic address in NAC policies 7.4.4 on page 839
l External resource entry limit enhancements 7.4.4 on page 841
l Support multi-tenant FortiClient Cloud fabric connectors 7.4.4 on page 843
l Automatic serial number retrieval from FortiManager 7.4.4 on page 845
A MAC address threat feed is a dynamic list that contains MAC addresses, MAC ranges, and MAC OUIs. The list is
periodically updated from an external server and stored in text file format on an external server. After the FortiGate
imports this list, it can be used as a source in firewall policies, proxy policies, and ZTNA rules. For policies in transparent
mode or virtual wire pair policies, the MAC address threat feed can be used as a source or destination address.
Text file example:
01:01:01:01:01:01
01:01:01:01:01:01-01:01:02:50:20:ff
8c:aa:b5
The file contains one MAC address, MAC range, or MAC OUI per line.
Example configuration
In this example, a list of MAC addresses is imported using the MAC address threat feed. The newly created threat feed is
then used as a source in a firewall policy with the action set to accept. Any traffic from the client MAC addresses that
match the defined firewall policy will be allowed.
1. Go to Policy & Objects > Firewall Policy and create a new policy, or edit an existing one.
2. Configure the policy fields as required.
3. In the Source field, click the + and select MAC_List from the list (in the MAC ADDRESS FEED section).
4. Set Action to ACCEPT.
5. Click OK.
FortiClient EMS and FortiClient EMS Cloud can be added on a per-VDOM basis. Enabling override is necessary to add
an EMS server for each VDOM.
config endpoint-control settings
set override {enable | disable}
end
If override is enabled for a VDOM, the global configuration will not affect the VDOM. Override must be configured for
each VDOM that connects to an EMS server.
FortiClient Cloud can be overridden in FortiOS 7.4.4 and later. See Support multi-tenant
FortiClient Cloud fabric connectors 7.4.4 on page 843 for more information.
This functionality can be applied to MSSP (managed security service provider) configurations, and each VDOM has its
own FortiClient EMS card for the EMS server or instance. For example:
l Separate on-premise FortiClient EMS instances
2. Navigate to the desired VDOM, then go to Security Fabric > Fabric Connectors and double-click the FortiClient EMS
card.
3. Configure the EMS server settings as needed (see Configuring FortiClient EMS in the FortiOS Administration Guide
for detailed steps).
FortiVoice endpoint details are displayed in the device tooltips that can be accessed on the FortiView monitor and log
pages. Users can view the display name and extension number of each FortiFone, making it easier to identify and
manage endpoint phones.
Sample tooltips
Registered FortiFones are visible on the Security Fabric > Asset Identity Center page.
When a FortiVoice-supplied MAC or IP address is used in a firewall policy, a FortiVoice tag (MAC/IP) dynamic address is
automatically created on the FortiGate that contains all the provisioned FortiFones registered with FortiVoice. The
dynamic address can be used in firewall policies to restrict rules to authorized FortiFones only. This is useful for large
voice deployments that require security and efficiency.
Example
In this example, two FortiFones are registered to FortiVoice and are assigned names and extension numbers. A
FortiVoice Fabric connector has been authorized to join the Security Fabric. The dynamic FortiVoice tags are applied to
a firewall policy.
1. Configure and authorize the FortiVoice Fabric connector (see Configuring FortiVoice for more information).
2. Go to Policy & Objects > Addresses to view the newly created dynamic firewall address objects:
a. Expand the FortiVoice Tag (IP Address) section.
3. Go to Policy & Objects > Firewall Policy and click Create new or edit an existing policy.
4. In the Source field, click the + and add the FOV-500000002732_Registered_Phones and MAC_FOV-
500000002732_Registered_Phones addresses.
5. In the Destination field, click the + and add the FOV-500000002732_Registered_Phones address.
FortiVoice tag dynamic addresses can now be applied to a NAC policy. New commands are available:
config user nac-policy
edit <name>
set category fortivoice-tag
set fortivoice-tag <string>
next
end
set category {device | Set category to the fortivoice-tag option to use the fortivoice-tag
firewall-user | ems- command.
tag | fortivoice-tag
| vulnerability}
set fortivoice-tag Specify the name of the FortiVoice tag to use for NAC policy matching.
<string>
FortiFones that match the NAC policy can be assigned and isolated to a NAC VLAN. See FortiVoice tag dynamic
address for more information.
Example
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
FortiFone is also shown on Dashboards > Assets & Identities in the Matched NAC Devices widget.
6. Go to WiFi & Switch Controller > FortiSwitch Ports and locate the port that the FortiFone is connected to. The port
has been dynamically assigned vlan12.
The external resource entry limit is now global, and file size restrictions change according to the device model. This
allows for a more flexible and optimized use of resources, tailored to the specific capabilities and requirements of the
different device models.
If VDOMs are enabled, global entries are counted first, then VDOM entries in alphabetical order based on the VDOMs'
names.
If more than the maximum number of entries are added, the most recently added entries are truncated, unless the order
is manually changed. The entry order can be changed using the move CLI command. For example:
config system external-resource
move "entry2" before "entry1"
end
The following table lists the maximum number of each type of entry and the file size limit for each model range:
l The root VDOM is alphabetically before the vd1 and vd2 VDOMs, so its entry is kept:
FGT (root)# diagnose sys external-resource stats
name: g-category-push; uuid_idx: 606; type: category; update_method: push; total lines:
1; valid lines: 1; error lines: 0; used: no; buildable: 1; total in count file: 1;
name: r-category-push; uuid_idx: 746; type: category; update_method: push; total lines:
1; valid lines: 1; error lines: 0; used: no; buildable: 1; total in count file: 1;
l The vd1 VDOM is next alphabetically. The maximum number of entries is 300000, so 299998 entries from the
v-category-3000000 threat feed are kept, and no entries from the v-category-push feed:
FGT (vd1)# diagnose sys external-resource stats
name: g-category-push; uuid_idx: 606; type: category; update_method: push; total lines:
1; valid lines: 1; error lines: 0; used: no; buildable: 1; total in count file: 1;
name: v-category-300000; uuid_idx: 863; type: category; update_method: feed; truncated
total lines: 300000; valid lines: 299999; error lines: 1; used: no; buildable: 299998;
total in count file: 300000;
name: v-category-push; uuid_idx: 868; type: category; update_method: push; total lines:
1; valid lines: 1; error lines: 0; used: yes; buildable: 0; total in count file: 1;
l The vd2 VDOM is last alphabetically and the maximum number of entries has already been reached, so all of its
entries are truncated:
FGT (vd2)# diagnose sys external-resource stats
name: g-category-push; uuid_idx: 606; type: category; update_method: push; total lines:
1; valid lines: 1; error lines: 0; used: no; buildable: 1; total in count file: 1;
name: z-category-push; uuid_idx: 989; type: category; update_method: push; total lines:
1; valid lines: 1; error lines: 0; used: no; buildable: 0; total in count file: 1;
Before this enhancement, a FortiGate can only connect to the FortiClient Cloud instance that is registered under the root
FortiCloud account. FortiGate now supports connecting to a FortiClient Cloud instance registered under a sub-OU in
FortiCloud. Furthermore, a FortiGate can override FortiClient Cloud access key setting on a per-VDOM basis. With
these enhancements, a FortiGate can support FortiClient Cloud in multi-tenancy scenarios.
l The FortiGate will perform an entitlement check on the registered FortiCloud Account to verify a FortiClient Cloud
entitlement exists on the root FortiCloud account. If the FortiGate has no FortiClient Cloud entitlement, you cannot
select the FortiClient EMS Cloud type or input an access key.
l Using the FortiClient Cloud access key, a FortiGate can connect to a FortiClient Cloud instance belonging to a sub-
OU in the same FortiCloud account or a different FortiCloud account.
l Within the same VDOM, the FortiGate can have an EMS connector connecting to multiple FortiClient Cloud
instances.
CLI syntax
key Enter the access key found in the FortiClient Cloud instance.
Example
In this example, a FortiGate will connect to different FortiClient Cloud instances between the Global EMS connector, root
and vdom1.
1. Obtain the access by from FortiClient Cloud by going to FortiCloud > FortiClient Cloud.
2. Click Access Key and switch to the FortiGate Access Key tab.
3. Click Create New Key to generate a new key.
next
end
From the CLI, run the following commands. A successful connection will look like the following.
# diagnose endpoint filter show-large-data yes
# diagnose debug application fcnacd -1
# diagnose debug enable
…
[ec_ez_worker_base_prep_resolver:382] Outgoing interface index 0 for 1 (cloud_vdom1).
[ec_ez_worker_prep_data_url:190] Full URL: https://sf.00000-XXXXXXXXXXXXXXXXXXXX.fortinet-
ca2.fortinet.com/api/v1/system/serial_number
[ec_ez_worker_base_prep_ssl:429] verify peer method: 3, current ssl_cb: (nil), new ssl_cb:
0x55c1163571b0
[ec_ems_context_submit_work:642] Call submitted successfully.
obj-id: 0, desc: REST API to get EMS Serial Number., entry: api/v1/system/serial_number.
[__match_server_cert_key:462] verify_peer_method: 3
Starting with version 7.4.4, FortiGate devices can now automatically retrieve the FortiManager serial number by
establishing a connection with FortiManager. This enhancement eliminates the need for manual serial number entry,
even when configuring with the CLI. This update ensures that CLI functionality is now aligned with the GUI, which
already supports automatic serial number retrieval.
For more information about this feature, see Automatic serial number retrieval from FortiManager.
This section includes information about external SDN connector related new features:
l Support IPv6 dynamic addresses retrieved from Cisco ACI SDN connector on page 846
Support IPv6 dynamic addresses retrieved from Cisco ACI SDN connector
IPv6 dynamic addresses can be retrieved from Cisco ACI SDN connectors. IPv6 addresses imported from Cisco ACI to
the Fortinet SDN Connector VM can be imported into the FortiGate as IPv6 dynamic addresses. The Fortinet SDN
Connector VM must be running version 1.1.10 or later.
config firewall address6
edit <name>
set type dynamic
set sdn <ACI_connector>
next
end
For more information about this feature, see Support IPv6 dynamic addresses retrieved from Cisco ACI SDN connector.
Security ratings
This section includes information about security rating related new features:
l Support CIS compliance standards within security ratings 7.4.1 on page 846
l Add prompt for one-time upgrade when a critical vulnerability is detected upon login 7.4.1 on page 848
CIS security control mappings have been added to the Security Rating page. Users can view ratings by CIS compliance
and view the description for each CIS control. The FortiGate must have a valid Attack Surface Security Rating license to
view security ratings grouped by CIS.
On FortiGates without valid Attack Surface Security Rating license, the CIS option in the dropdown is grayed out.
3. Select a security rule. In the Compliance Information section (to the right), click the + to expand and view more
details about related CIS compliance for the rule.
Add prompt for one-time upgrade when a critical vulnerability is detected upon
login - 7.4.1
When FortiOS detects a critical vulnerability, a prompt appears for a one-time upgrade after logging into the FortiGate. A
warning message is displayed in the GUI about the critical vulnerability and allows the administrator to either upgrade or
skip it. This ensures that the administrator is aware of any potential security risks and can take immediate action to
address them.
Clicking the hyperlinked vulnerability name opens the Security Fabric > Security Rating page, which displays more
information about the vulnerability.
Clicking the Upgrade button opens the System > Firmware & Registration page where the administrator can upgrade the
device.
Clicking the Skip upgrade & I understand the risk button continues the log in process as usual.
Diagnostics
Automation
Automation triggers and actions have been simplified to allow for better management with the following improvements:
l Hide simple triggers and actions that should be reused from the creation pages.
l Add a shortcut on the System Events > Logs page to create an automation trigger based on the event log.
l Add FortiCare email option for Email actions.
When upgrading from FortiOS 7.2, all existing automation triggers, actions, and stitches are
preserved.
Static automation triggers and actions that require only a name, description, and one setting are added by default, such
as the Configuration Change trigger and IP Ban action. Static triggers and actions can be edited, but they cannot be
deleted.