Logging and Monitoring

DO NOT REPRINT
© FORTINET

Good job! You now understand how to troubleshoot communication issues.

Now, you will learn how you can protect your log data.

FortiGate Security 7.0 Study Guide 301

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in using various methods to protect your logs, you will be able to meet
organizational or legal requirements for logs.

FortiGate Security 7.0 Study Guide 302

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

You can also protect your log data by performing log backups, which is to say copying log files from the
database to a specified location.

The execute backup disk alllogs command backs up all logs to FTP, TFTP, or USB, while execute
backup disk log <log type> backs up specific log types (such as web filter or IPS) to FTP, TFTP, or
USB. These logs are stored in LZ4 format. You can restore FortiGate backup logs to a FortiAnalyzer device
and then view on both FortiGate and FortiAnalyzer devices.

You can also back up logs to USB using the GUI. The GUI menu item appears when you insert a USB drive
into a FortiGate USB port.

FortiGate Security 7.0 Study Guide 303

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Using the config log disk setting command, you can configure logs to roll (which is similar to zipping
a file) to lower the space requirements needed to contain them so they don’t get overwritten. By default, logs
roll when they reach 20 MB in size. You can also configure a roll schedule and time.

Using the same CLI command, you can also configure rolled logs to upload to an FTP server to save disk
space. You can configure which types of log files to upload, when, and whether to delete files after uploading.

FortiGate Security 7.0 Study Guide 304

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

You can also download a copy of the logs from FortiGate and save them on a server or on a computer to view
and access later. This ensures that you still have a copy when the originals are eventually overwritten on
FortiGate.

You can download logs by clicking the download icon on the associated log type page (for example, Forward
Traffic or Web Filter). This downloads only the logs in the results table—not all logs on disk. As such, you
can add log filters if you want to download only a subset of logs. When you download the log messages on the
GUI, you are downloading log messages in the raw format.

FortiGate Security 7.0 Study Guide 305

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 306

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson. Now, you will review the topics that you covered in this
lesson.

FortiGate Security 7.0 Study Guide 307

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

This slide shows the topics that you covered in this lesson.

By mastering the topics covered in this lesson, you learned to configure local and remote logging, view logs,
search logs, and protect your log data.

FortiGate Security 7.0 Study Guide 308

 Certificate Operations

DO NOT REPRINT
© FORTINET

In this lesson, you will learn why FortiGate uses digital certificates, how to configure FortiGate to use
certificates (including using certificates to inspect the contents of encrypted traffic), and how FortiGate
manages certificates.

FortiGate Security 7.0 Study Guide 309

 Certificate Operations

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiGate Security 7.0 Study Guide 310

 Certificate Operations

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating an understanding of how FortiGate uses certificates, you will be better able to judge how
and when certificates could be used in your own networks.

FortiGate Security 7.0 Study Guide 311

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate uses digital certificates to enhance security.

FortiGate uses digital certificates for inspection. The device can generate certificates on demand for the
purpose of inspecting encrypted data that is transferred between two devices; essentially, a man-in-the-middle
(MITM) attack. FortiGate can also inspect certificates to identify people and devices (in the network and on the
internet), before it permits a person or device to make a full connection to the entity that it is protecting. If
FortiGate trusts the certificate, it permits the connection. But if FortiGate does not trust the certificate, it can
prevent the connection. How you configure FortiGate determines the behavior; however, other policies that
are being used may also affect whether connection attempts are accepted or rejected.

FortiGate uses digital certificates to enforce privacy. Certificates, and their associated private keys, ensure
that FortiGate can establish a private SSL connection to another device, such as FortiGuard, a web browser,
or a web server.

FortiGate also uses certificates for authentication. Users who have certificates issued by a known and trusted
CA can authenticate on FortiGate to access the network or to establish a VPN connection. Administrator
users can use certificates as a second-factor authentication to log in to FortiGate.

FortiGate Security 7.0 Study Guide 312

 Certificate Operations

DO NOT REPRINT
© FORTINET

What is a digital certificate?

A digital certificate is a digital document produced and signed by a CA. It identifies an end entity, such as a
person (example, Joe Bloggins), a device (example, webserver.acme.com), or thing (example, a certificate
revocation list). FortiGate identifies the device or person by reading the value in the Subject field, which is
expressed as a distinguished name (DN). FortiGate could also use alternate identifiers, shown in the Subject
Alternative Name field, whose values could be a network ID or an email address, for example. FortiGate can
use the Subject Key Identifier and Authority Key Identifier values to determine the relationship between
the issuer of the certificate (identified in the Issuer field) and the certificate. FortiGate supports the X.509v3
certificate standard, which is the most common standard for certificates.

FortiGate Security 7.0 Study Guide 313

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate runs the following checks before it trusts the certificate:

• Checks the CRLs locally (on FortiGate) to verify if the certificate has been revoked by the CA. If the serial
number of the certificate is listed on the CRL, then the certificate has been revoked and it is no longer
trusted. FortiGate also supports Online Certificate Status Protocol (OCSP), where FortiAuthenticator acts
as the OCSP responder.
• Reads the value in the Issuer field to determine if it has the corresponding CA certificate. Without the CA
certificate, FortiGate does not trust the certificate. FortiOS uses the Mozilla CA certificate store. You can
view the list by clicking Security Profiles > SSL Inspection > View Trusted CA List > Factory Bundles.
• Verifies that the current date is between the Valid From and Valid To values. If it is not, the certificate is
rendered invalid.
• Validates the signature on the certificate. The signature must be successfully validated. Because a valid
signature is a critical requirement for trusting a certificate, it may be useful to review how FortiGate verifies
digital signatures.

FortiGate Security 7.0 Study Guide 314

 Certificate Operations

DO NOT REPRINT
© FORTINET

Before it generates a digital signature, the CA runs the content of the certificate through a hash function,
which produces a hash result. The hash result, which is a mathematical representation of the data, is referred
to as the original hash result. The CA encrypts the original hash result using its private key. The encrypted
hash result is the digital signature.

When FortiGate verifies the digital signature, it runs the certificate through a hash function, producing a fresh
hash result. FortiGate must use the same hash function, or hashing algorithm, that the CA used to create the
digital signature. The hashing algorithm is identified in the certificate.

In the second part of the verification process, FortiGate decrypts the encrypted hash result (or digital
signature) using the CA public key, and applying the same algorithm that the CA used to encrypt the hash
result. This process verifies the signature. If the key cannot restore the encrypted hash result to its original
value, then the signature verification fails.

In the third, and final, part of the verification process, FortiGate compares the fresh hash result to the original
hash result. If the two values are identical, then the integrity of the certificate is confirmed. If the two hash
results are different, then the version of the certificate that FortiGate has is not the same as the one that the
CA signed, and data integrity fails.

FortiGate Security 7.0 Study Guide 315

 Certificate Operations

DO NOT REPRINT
© FORTINET

Certificate-based user authentication uses an end-entity certificate to identify the user. This certificate
contains the user public key and the signature of the CA that issued the certificate. The authentication server
(for example, FortiGate) must have the CA certificate whose private key signed the user certificate. FortiGate
verifies that the certificate signature is valid, that the certificate has not expired, and that the certificate hasn’t
been revoked. If any of these verifications fail, the certificate-based user authentication fails.

You can configure FortiGate to require that administrators use certificates for second-factor authentication.
The process for verifying administrator certificates is the same.

FortiGate Security 7.0 Study Guide 316

 Certificate Operations

DO NOT REPRINT
© FORTINET

As you can see in the example shown on this slide, trust in the web model is determined by whether or not
your certificate store possesses the CA certificate that is required to verify the signature on the SSL certificate.
Certificate stores come prepopulated with root and subordinate CA certificates. You can choose to add or
remove the certificates, which will affect which websites you trust.

By default, FortiGate uses a self-signed certificate to authenticate itself to HTTPS clients.

You can configure self-signed certificates to establish SSL sessions, just like those certificates issued by
Verisign, Entrust Datacard, and other certificate vendors. But, because self-signed certificates do not come
prepopulated in client certificate stores, your end users get a security warning. You can choose to add the
self-signed certificate to clients, or to purchase an SSL certificate from an approved CA vendor for your
FortiGate device.

FortiGate Security 7.0 Study Guide 317

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate uses SSL to ensure that data remains private when connecting with servers, such as FortiGuard,
and with clients, such as a web browser. Another feature of SSL is that FortiGate can use it to identify one or
both parties using certificates. SSL uses symmetric and asymmetric cryptography to establish a secure
session between two points.

It is beneficial to understand the high-level process of an SSL handshake, in order to understand how
FortiGate secures private sessions.

An important attribute of symmetric cryptography is that the same key is used to encrypt and decrypt data.
When FortiGate establishes an SSL session between itself and another device it must share, the symmetric
key (or rather the value required to produce it), so that data can be encrypted by one side, sent, and
decrypted by the other side.

Asymmetric cryptography uses a pair of keys: one key performs one function and the other key performs the
opposite function. When FortiGate connects to a web server, for example, it uses the web server public key to
encrypt a string known as the premaster secret. The web server private key decrypts the premaster secret.

FortiGate Security 7.0 Study Guide 318

 Certificate Operations

DO NOT REPRINT
© FORTINET

Now, you will learn more about the process of establishing an SSL session.

In the first step of the example shown on this slide, FortiGate connects to a web server that is configured for
SSL. In the initial hello message, the browser provides critical information that is needed to communicate with
the web server. This information includes the SSL version number and the names of the cryptographic
algorithms that it supports.

In the second step, the web server receives the message from FortiGate and chooses the first suite of
cryptographic algorithms included in the message, and verifies that it is also supported by the web server. The
web server replies with the chosen SSL version and cipher suite, and then sends its certificate to FortiGate.
Note that the certificate information is passed as cleartext over the public network. The information contained
in a certificate is typically public, so this is not a security concern.

In the third step, FortiGate validates the web server certificate. The checklist shown on this slide represents
the checks that FortiGate performs on the certificate to ensure that it can be trusted. If FortiGate determines
that the certificate can be trusted, then the SSL handshake continues.

FortiGate Security 7.0 Study Guide 319

 Certificate Operations

DO NOT REPRINT
© FORTINET

In the fourth step, FortiGate generates a value known as the premaster secret. FortiGate uses the server
public key, which is in the certificate, to encrypt the premaster secret. FortiGate then sends the encrypted
premaster secret to the web server. If a third-party intercepted the premaster secret, they would be unable to
read it, because they do not have the private key.

In the fifth step, the web server uses its private key to decrypt the premaster secret. Now, both FortiGate and
the web server share a secret value that is known by only these two devices.

FortiGate Security 7.0 Study Guide 320

 Certificate Operations

DO NOT REPRINT
© FORTINET

In the sixth step, both FortiGate and the web server derive the master secret based on the premaster secret.

In the seventh step, based on the master secret value, FortiGate and the web server generate the session
key. The session key is a symmetric key. It is required to encrypt and decrypt the data. Because both sides
have the session key, both sides can encrypt and decrypt data for each other.

In the eighth and final step before these two entities establish the secure connection, both FortiGate and the
web server send each other a summary (or digest) of the messages sent so far. The digests are encrypted
with the session key. The digests ensure that none of the messages exchanged during the creation of the
session have been intercepted or replaced. If the digests match, the secure communication channel is
established.

The SSL handshake is now complete. Both FortiGate and the web server are ready to communicate securely,
using the session keys to encrypt and decrypt the data they send over the network or internet.

FortiGate Security 7.0 Study Guide 321

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 322

 Certificate Operations

DO NOT REPRINT
© FORTINET

Good job! You now understand why and how FortiGate uses certificates to authenticate devices and people.
You also understand how FortiGate uses certificates to ensure the privacy of data as it flows from FortiGate to
another device, or from another device to FortiGate.

Now, you will learn about how to inspect encrypted data.

FortiGate Security 7.0 Study Guide 323

 Certificate Operations

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding and configuring full SSL inspection and certificate inspection,
you will be able to implement one of these SSL inspection solutions in your network.

FortiGate Security 7.0 Study Guide 324

 Certificate Operations

DO NOT REPRINT
© FORTINET

(slide contains animation)

While there are benefits to using HTTPS, there are risks associated with its use as well, because encrypted
traffic can be used to get around normal defenses. For example, if a session is encrypted when you download
a file containing a virus, the virus might get past your network security measures.

In the example shown on this slide, Bob connects to a site with a certificate issued by a legitimate CA.
Because the CA is an approved CA, the CA verification certificate is in Bob’s certificate store, and Bob’s
browser is able to establish an SSL session with the example.com site. However, unknown to Bob, the
example.com site has been infected with a virus. The virus, cloaked by encryption, passes through FortiGate
undetected and enters Bob’s computer. The virus is able to breach security because full SSL inspection is not
enabled.

You can use full SSL inspection, also known as deep inspection, to inspect encrypted sessions.

FortiGate Security 7.0 Study Guide 325

 Certificate Operations

DO NOT REPRINT
© FORTINET

During the exchange of hello messages at the beginning of an SSL handshake, FortiGate parses server name
indication (SNI) from client Hello, which is an extension of the TLS protocol. The SNI tells FortiGate the
hostname of the SSL server, which is validated against the DNS name before receipt of the server certificate.
If there is no SNI exchanged, then FortiGate identifies the server by the value in the Subject field or SAN
(subject alternative name) field in the server certificate.

When you use certificate inspection, FortiGate inspects only the header information of the packets. You use
certificate inspection to verify the identity of web servers. You can also use it to make sure that the HTTPS
protocol isn't used as a workaround to access sites you have blocked using web filtering.

The only security feature that you can apply using SSL certificate inspection mode is web filtering. However,
since only the packet is inspected, this method does not introduce certificate errors and can be a useful
alternative to full SSL inspection when you use web filtering.

Certificate inspection offers some level of security, but it does not allow FortiGate to inspect the flow of
encrypted data between the outside server and the internal client.

FortiGate Security 7.0 Study Guide 326

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate has a read-only preconfigured profile for SSL certificate inspection named certificate-inspection. If
you want to enable SSL certificate inspection, select this profile when configuring a firewall policy.

Alternatively, you can create your own profile for SSL certificate inspection by following the steps below:

1. On the FortiGate GUI, click Security Profiles > SSL/SSH Inspection.

2. Click Create New to create a new SSL/SSH inspection profile.
3. Select Multiple Clients Connecting to Multiple Servers, and click SSL Certificate Inspection.

FortiGate Security 7.0 Study Guide 327

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate must act as a CA in order for it to perform full SSL inspection. The internal CA must generate an
SSL private key and certificate each time an internal user connects to an external SSL server. The key pair
and certificate are generated immediately so the user connection with the web server is not delayed.

Although it appears as though the user browser is connected to the web server, the browser is connected to
FortiGate. FortiGate is acting as a proxy web server. In order for FortiGate to act in these roles, its CA
certificate must have the basic constraints extension set to cA=True and the value of the keyUsage extension
set to keyCertSign.

The cA=True value identifies the certificate as a CA certificate. The keyUsage=keyCertSign value indicates
that the certificate corresponding private key is permitted to sign certificates. For more information, see RFC
5280 Section 4.2.1.9 Basic Constraints.

All FortiGate devices that support full SSL inspection can use the self-signed Fortinet_CA_SSL certificate that
is provided with FortiGate, or an internal CA, to issue FortiGate a CA certificate. When FortiGate uses an
internal CA, FortiGate acts as a subordinate CA. Note that your client machines and devices must import the
root CA certificate, in order to trust FortiGate and accept an SSL session. You must install the chain of CA
certificates on FortiGate. FortiGate sends the chain of certificates to the client, so that the client can validate
the signatures and build a chain of trust.

FortiGate Security 7.0 Study Guide 328

 Certificate Operations

DO NOT REPRINT
© FORTINET

Some FortiGate devices offer a mechanism to inspect encrypted data that flows between external SSL
servers and internal clients. Without full SSL inspection, FortiGate cannot inspect encrypted traffic, because
the firewall does not have the SSL key that is required to decrypt the data, and that was negotiated between
client and server during the SSL handshake.

There are two possible configurations for full SSL inspection: one for outbound traffic and one for inbound
traffic.

If the connection request is outbound (initiated by an internal client to an external server), you must select the
option, Multiple Clients Connecting to Multiple Servers. Then, you must select the CA certificate that will
be used to sign the new certificates. In the example shown on this slide, it is the built-in FortiGate_CA_SSL
certificate, which is available on FortiGate devices that support SSL inspection. You will also learn about
configuring full SSL inspection for inbound traffic in this lesson.

FortiGate Security 7.0 Study Guide 329

 Certificate Operations

DO NOT REPRINT
© FORTINET

In step 1, an internal web browser connects to an SSL-enabled web server. Normally, when a browser
connects to a secure site, the web server sends its certificate to the browser. However, in step 2, FortiGate
intercepts the web server certificate. In step 3, the FortiGate internal CA generates a new key pair and
certificate. The new certificate subject name must be the DNS name of the website (for example, ex.ca). In
steps 4 and 5, the new key pair and certificate are used to establish a secure connection between FortiGate
and the web browser. A new temporary key pair and certificate are generated each time a client requests a
connection with an external SSL server.

Outward facing and included in step 5, FortiGate uses the web server certificate to initiate a secure session
with the web server. In this configuration, FortiGate can decrypt the data from both the web server and the
browser, in order to scan the data for threats before re-encrypting it and sending it to its destination. This
scenario is, essentially, an MITM attack.

FortiGate Security 7.0 Study Guide 330

 Certificate Operations

DO NOT REPRINT
© FORTINET

The browser presents a certificate warning when you attempt to access an HTTPS site that uses an untrusted
certificate. Untrusted certificates include self-signed SSL certificates, unless the certificate is imported into the
browser-trusted certificate store. FortiGate has its own configuration setting on the SSL/SSH Inspection
page, which includes options to Allow, Block, or Ignore untrusted SSL certificates.

When you set the Untrusted SSL certificates setting to Allow and FortiGate detects an untrusted SSL
certificate, FortiGate generates a temporary certificate signed by the built-in Fortinet_CA_Untrusted
certificate. FortiGate then sends the temporary certificate to the browser, which presents a warning to the user
indicating that the site is untrusted. If FortiGate receives a trusted SSL certificate, then it generates a
temporary certificate signed by the built-in Fortinet_CA_SSL certificate and sends it to the browser. If the
browser trusts the Fortinet_CA_SSL certificate, the browser completes the SSL handshake. Otherwise, the
browser also presents a warning message informing the user that the site is untrusted. In other words, for this
function to work as intended, you must import the Fortinet_CA_SSL certificate into the trusted root CA
certificate store of your browser. The Fortinet_CA_Untrusted certificate must not be imported.

When the setting is set to Block and FortiGate receives an untrusted SSL certificate, FortiGate blocks the
connection outright, and the user cannot proceed.

When the setting is set to Ignore, FortiGate sends the browser a temporary certificate signed by the
Fortinet_CA_SSL certificate, regardless of the SSL certificate status—trusted or untrusted. FortiGate then
proceeds to establish SSL sessions.

FortiGate Security 7.0 Study Guide 331

 Certificate Operations

DO NOT REPRINT
© FORTINET

The scenario shown on this slide describes how FortiGate handles a trusted external site regardless of the
Untrusted SSL Certificate setting.

In step 1, the browser initiates a connection with an external site that is trusted by FortiGate. In step 2, the
trusted server sends its SSL certificate to FortiGate. In step 3, FortiGate trusts the certificate because it has
the corresponding CA certificate in its trusted certificate store. FortiGate can validate the signature on the SSL
certificate. In step 4, because FortiGate trusts the SSL certificate, it generates a temporary certificate signed
by the Fortinet_CA_SSL certificate. FortiGate sends the temporary certificate to the browser. Finally, in step 5,
the browser trusts the temporary certificate because the Fortinet_CA_SSL certificate is in its trusted root CA
store. After the browser finishes validating the certificate, it completes the SSL handshake with FortiGate.
Next, FortiGate continues the SSL handshake with the trusted server.

FortiGate Security 7.0 Study Guide 332

 Certificate Operations

DO NOT REPRINT
© FORTINET

The scenario shown on this slide describes how FortiGate handles an untrusted external site when Untrusted
SSL Certificate is set to Allow.

In step 1, the browser initiates a connection with an external site that is not trusted by FortiGate. In step 2, the
untrusted server sends its self-signed SSL certificate to FortiGate. In step 3, FortiGate does not find a copy of
the certificate in its trusted certificate store and, therefore, does not trust the SSL certificate. In step 4,
because FortiGate does not trust the SSL certificate, it generates a temporary certificate signed by the
Fortinet_CA_Untrusted certificate. This temporary certificate is sent to the browser. In step 5, the browser
does not trust the temporary certificate because it does not have the Fortinet_CA_Untrusted certificate in its
trusted root CA store. The browser displays a warning alerting the user that the certificate is untrusted. If the
user decides to ignore the warning and proceed, the browser completes the SSL handshake with FortiGate.
Next, FortiGate continues the SSL handshake with the untrusted server.

The user may have the option to write this temporary certificate to the browser trusted certificate store.
However, this has no impact in the future. The next time the user connects to the same untrusted site, a new
temporary certificate is produced for the session.

FortiGate Security 7.0 Study Guide 333

 Certificate Operations

DO NOT REPRINT
© FORTINET

The scenario shown on this slide describes how FortiGate handles an untrusted external site when Untrusted
SSL Certificate is set to Block.

In step 1, the browser initiates a connection with an external site that is not trusted by FortiGate. In step 2, the
untrusted server sends its self-signed SSL certificate to FortiGate. In step 3, FortiGate does not find the
certificate in its trusted certificate store and, therefore, does not trust the SSL certificate. In step 4, because
FortiGate does not trust the SSL certificate, it stops the session. In step 5, FortiGate notifies the browser that
the site is blocked.

FortiGate Security 7.0 Study Guide 334

 Certificate Operations

DO NOT REPRINT
© FORTINET

The scenario shown on this slide describes how FortiGate handles an untrusted external site when Untrusted
SSL Certificate is set to Ignore.

In step 1, the browser initiates a connection with an external site that is not trusted by FortiGate. In step 2, the
untrusted server sends its self-signed SSL certificate to FortiGate. Because the setting is set to Ignore,
FortiGate does not check the certificate store. In step 3, FortiGate generates a temporary certificate signed by
Fortinet_CA_SSL certificate, and sends the certificate to the browser. In step 4, the browser trusts the
certificate because Fortinet_CA_SSL certificate is in its trusted root CA store. After the browser finishes
checking the certificate, it completes the SSL handshake with FortiGate. Next, FortiGate continues the SSL
handshake with the trusted server.

A connection to a trusted site is handled the same way.

FortiGate Security 7.0 Study Guide 335

 Certificate Operations

DO NOT REPRINT
© FORTINET

Within the full SSL inspection profile, you can also specify which SSL sites, if any, you want to exempt from
SSL inspection. You may need to exempt traffic from SSL inspection if it is causing problems with traffic, or for
legal reasons.

Performing SSL inspection on a site that is enabled with HTTP public key pinning (HPKP), for example, can
cause problems with traffic. Remember, the only way for FortiGate to inspect encrypted traffic is to intercept
the certificate coming from the server, and generate a temporary one. After FortiGate presents the temporary
SSL certificate, browsers that use HPKP refuse to proceed. The SSL inspection profile, therefore, allows you
to exempt specific traffic.

Laws protecting privacy might be another reason to bypass SSL inspection. For example, in some countries, it
is illegal to inspect SSL bank-related traffic. Configuring an exemption for sites is simpler than setting up
firewall policies for each individual bank. You can exempt sites based on their web category, such as finance
or banking, or you can exempt them based on their address. Alternatively, you can enable Reputable
websites, which excludes an allowlist of reputable domain names maintained by FortiGuard from full SSL
inspection. This list is periodically updated and downloaded to FortiGate devices through FortiGuard.

FortiGate Security 7.0 Study Guide 336

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate can detect certificates that are invalid for the following reasons:
• Expired: The certificate is expired.
• Revoked: The certificate has been revoked based on CRL or OCSP information.
• Validation timeout: The certificate could not be validated because of a communication timeout.
• Validation failed: The certificate could not be validated because of a communication error.

When a certificate fails for any of the reasons above, you can configure any of the following actions:
• Keep untrusted & Allow: FortiGate allows the website and lets the browser decide the action to take.
FortiGate takes the certificate as trusted.
• Block: FortiGate blocks the content of the site.
• Trust & Allow: FortiGate allows the website and takes the certificate as trusted.

The certificate check feature can be broken down into two major checks, which are done in parallel:
• FortiGate checks if the certificate is invalid because of the four reasons described on this slide.
• FortiGate performs certificate chain validation based on the CA certificates installed locally and the
certificates presented by the SSL server. This is described in this lesson.

Based on the actions configured and the check results, FortiGate presents the certificate as either trusted
(signed by Fortinet_CA_SSL) or untrusted (signed by Fortinet_CA_Untrusted), and either allows the content
or blocks it. You can also track certificate anomalies by enabling the Log SSL anomalies option.

FortiGate Security 7.0 Study Guide 337

 Certificate Operations

DO NOT REPRINT
© FORTINET

You can enable SSH deep scan when you select Multiple Clients Connecting to Multiple Servers. When
you enable SSH deep scan, FortiGate does an MITM attack for SSH traffic. A process similar to the one done
for full SSL inspection takes place. FortiGate intercepts the SSH key sent by the server, generates a new one,
and sends it to the client. If the SSH client had stored the original host key, then it detects a change in the host
key and warns the user. The user can then replace the original host key with the new host key generated by
FortiGate.

By default, SSH deep scan listens on TCP port 22. You can specify a different port number, or select Any in
the SSH port field. When you do this, FortiGate scans all connections to identify SSH traffic using different
ports. Specifying a port for SSH traffic is not as comprehensive as searching all ports, but it is easier on the
performance of the firewall.

Finally, note that SSH deep scan is a proxy-based inspection feature only. In addition, the only security
features that use SSH deep scan are antivirus and data leak prevention.

FortiGate Security 7.0 Study Guide 338

 Certificate Operations

DO NOT REPRINT
© FORTINET

In the example shown on this slide, FortiGate is protecting a web server. This is the second configuration
option for full SSL inspection. When configuring the SSL inspection profile for this server, you must select
Protecting SSL Server, import the server key pair to FortiGate, and then select the certificate from the
Server Certificate drop-down list.

When Alice attempts to connect to the protected server, FortiGate becomes a surrogate web server by
establishing the secure connection with the client using the server key pair. FortiGate also establishes a
secure connection with the server, but acting as a client. This configuration allows FortiGate to decrypt the
data from either direction, scan it, and if it is clean, re-encrypt it and send it to the intended recipient.

You must install the server certificate and private key plus the chain of certificates required to build the chain
of trust. FortiGate sends the chain of certificates to the browser for this purpose.

FortiGate Security 7.0 Study Guide 339

 Certificate Operations

DO NOT REPRINT
© FORTINET

By creating a full SSL inspection profile on inbound traffic, you can configure the profile to use multiple web
sites if they are approachable by the same external IP address. When FortiGate receives client and server
hello messages, it selects the certificate to perform the full SSL inspection based on server name indication
(SNI) value against the common name (CN) on the certificate part of the inspection profile. If a certificate CN
matches the SNI on the request, FortiGate then selects this certificate to replace the original certificate and
uses it to inspect the traffic.

If the SNI does not match the CN in the certificate list in the SSL profile, then FortiGate selects the first server
certificate in the list.

FortiGate Security 7.0 Study Guide 340

 Certificate Operations

DO NOT REPRINT
© FORTINET

After you create and configure an SSL inspection profile, you must assign it to a firewall policy so FortiGate
knows how to inspect encrypted traffic. Most of the internet traffic is being encrypted nowadays. For this
reason, you usually want to enable SSL inspection to protect your network from security threats transported
over encrypted traffic. If you don’t want to enable SSL or SSH inspection, select the no-inspection profile
from the drop-down list. If SSL inspection is not enabled in a policy, FortiGate will not scan SSL or SSH
encrypted traffic matching that policy.

If you select a profile with full SSL inspection enabled, the option Decrypted Traffic Mirror appears. Enable
this option if you want FortiGate to send a copy of the decrypted SSL traffic to an interface. When you enable
Decrypted Traffic Mirror, FortiGate displays a window with the terms of use for this feature. The user must
agree with the terms before they can use the feature.

FortiGate Security 7.0 Study Guide 341

 Certificate Operations

DO NOT REPRINT
© FORTINET

When doing full SSL inspection using the FortiGate self-signed CA, your browser displays a certificate
warning each time you connect to an HTTPS site. This is because the browser is receiving certificates signed
by FortiGate, which is a CA it does not know and trust. The browser also displays a certificate warning when
performing SSL certificate inspection and an HTTPS website is blocked by FortiGate. Because FortiGate
needs to present a replacement message to the browser, FortiGate performs MITM and signs the certificate
with its self-signed CA as well.

You can avoid this warning by doing one of the following:

• Download the Fortinet_CA_SSL certificate and install it on all the workstations as a trusted root authority.
• Use an SSL certificate issued by a CA and ensure the certificate is installed in the necessary browsers.

You must install the SSL certificate on FortiGate and configure the device to use that certificate for SSL
inspection. If the SSL certificate is signed by a subordinate CA, ensure that the entire chain of certificates—
from the SSL certificate to the root CA certificate—is installed on FortiGate. Verify that the root CA is installed
on all client browsers. This is required for trust purposes. Because FortiGate sends the chain of certificates to
the browser during the SSL handshake, you do not have to install the intermediate CA certificates on the
browsers.

FortiGate Security 7.0 Study Guide 342

 Certificate Operations

DO NOT REPRINT
© FORTINET

Some security measures have been introduced by the IETF to mitigate MITM attacks. Some of these
measures cause problems when you implement outbound full SSL inspection.

HTTP strict transport security (HSTS) and HTTP public key pinning (HPKP) are security features designed to
thwart MITM attacks. HSTS is “a mechanism enabling websites to declare themselves accessible only
through secure connections …”, according to RFC 6797 of the IETF. In other words, a user from a web
browser would be forced to use HTTPS when connecting to a website with this policy; there would be no
option to connect using HTTP. HPKP is a security feature imposed by the web server that associates one or
more public keys with the website for a specified period of time. The public key doesn’t have to be the web
server public key, it could be one of the intermediate or root CA public keys, as long as it exists in the
certificate chain. When the web browser visits an HPKP-enabled website, hashes of the public keys
associated with a website are cached on the client machine.

Going forward, each time the web browser connects to the web server, it compares one or more of the keys
presented with the cached key fingerprints. If the browser cannot match at least one of the keys, the SSL
handshake terminates. This is a problem for outbound full SSL inspection. FortiGate generates a new
certificate and public key to establish an SSL session with the web browser. FortiGate cannot provide an
authentic certificate chain, so the connection would be rejected by the browser. Predictably, this could prevent
users from connecting to many legitimate sites.

FortiGate Security 7.0 Study Guide 343

 Certificate Operations

DO NOT REPRINT
© FORTINET

The options available to circumvent HPKP are limited. One option is to exempt SSL inspection for those sites.
Another option is to use SSL certificate inspection instead. A third option is to use a browser that does not
support HPKP, like Chrome, Internet Explorer, or Edge. Last, in some browsers it is possible to disable HPKP.

FortiGate Security 7.0 Study Guide 344

 Certificate Operations

DO NOT REPRINT
© FORTINET

More and more applications are using SSL to securely exchange data over the internet. While most of the
content in this lesson centers around the operation and impact of SSL inspection on browsers, the same
applies to other applications using SSL as well. After all, the browser is just another application using SSL on
your device.

For this reason, when you enable SSL inspection on FortiGate, you need to consider the potential impact on
your SSL-based applications. For example, Microsoft Outlook 365 for Windows reports a certificate error
when you enable full SSL inspection because the CA certificate used by FortiGate is not trusted. To solve this
issue, you can import the CA certificate into your Windows certificate store as a trusted root certificate
authority. Because Microsoft Outlook 365 trusts the certificates in the Windows certificate store, then the
application won’t report the certificate error anymore. Another option is to exempt your Microsoft Exchange
server addresses from SSL inspection. While this prevents the certificate error, you are no longer performing
SSL inspection on email traffic.

There are other applications that have built-in extra security checks that prevent MITM attacks, such as HPKP
or certificate pinning. For example, Dropbox uses certificate pinning to ensure that no SSL inspection is
possible on user traffic. As a result, when you enable full SSL inspection on FortiGate, your Dropbox client
stops working and reports that it can’t establish a secure connection. In the case of Dropbox, the only way to
solve the connection error is by exempting the domains Dropbox connects to from SSL inspection.

In addition, remember that SSL is leveraged by different protocols, not just HTTP. For example, there are
other SSL-based protocols such as FTPS, POP3S, SMTPS, STARTTLS, LDAPS, and SIP TLS. If you have
an application using any of these SSL-based protocols, and you have turned on SSL inspection along with a
security profile that inspects those protocols, then the applications may report an SSL or certificate error. The
solution depends on the security measures adopted by the application.

FortiGate Security 7.0 Study Guide 345

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 346

 Certificate Operations

DO NOT REPRINT
© FORTINET

Good job! You now can describe certificate and deep inspection, and you can configure FortiGate to use
either one of these options.

Now, you will learn how to manage digital certificates on FortiGate.

FortiGate Security 7.0 Study Guide 347

 Certificate Operations

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in generating certificate requests, importing CRLs, and backing up and
restoring certificates, you will be able to manage certificates on FortiGate.

FortiGate Security 7.0 Study Guide 348

 Certificate Operations

DO NOT REPRINT
© FORTINET

The process of obtaining a digital certificate for FortiGate begins with creating a certificate signing request
(CSR). The process is as follows:
1. FortiGate generates a CSR. A private and public key pair is created for FortiGate. The CSR is signed by
the FortiGate private key.
2. FortiGate submits the CSR to a CA. The CSR includes the FortiGate public key and specific information
about FortiGate (IP address, distinguished name, email address, and so on). Note that the private key
remains confidential on FortiGate.
3. The CA verifies that the information in the CSR is valid, and then creates a digital certificate for FortiGate.
The certificate is digitally signed using the CA private key. The CA also publishes the certificate to a
central repository. The certificate binds the public key to FortiGate.
4. The certificate is returned to install on FortiGate.

FortiGate Security 7.0 Study Guide 349

 Certificate Operations

DO NOT REPRINT
© FORTINET

You can generate a CSR on the Certificates page of the GUI by clicking Generate. Enter all of the required
information, such as the IP address (or FQDN) and company name. Ensure the key type and size fit your
requirements. You can submit the CSR to a CA using either of the following methods:
• Select File Based to generate the CSR as a .csr file, which is then sent to the CA.
• Select Online SCEP to submit the CSR to the CA online using the Simple Certificate Enrollment Protocol
(SCEP). For example, if you are using FortiAuthenticator as your CA, you can enable and configure SCEP
on FortiAuthenticator and use this method.

FortiGate Security 7.0 Study Guide 350

 Certificate Operations

DO NOT REPRINT
© FORTINET

If you are using the file-based method, the CSR is added to your list of certificates on the Certificates page.
Select the CSR and click Download. The administrator can now submit the file (.csr), which is a PKCS#10
request, to the CA. PKCS#10 is the most common format for a certificate request. The CA uses this file to
generate a signed certificate.

If using the online SCEP method, enter the CA server URL used for SCEP and the challenge password
provided by the CA administrator. The CSR is automatically submitted online.

After the CSR is submitted using either method, FortiGate shows the certificate status as Pending until the
certificate is returned by the CA and imported into FortiGate. At this point, the status changes to Valid and the
digital certificate can be used.

Note that if you delete the CSR, you cannot install the certificate and you must start over.

FortiGate Security 7.0 Study Guide 351

 Certificate Operations

DO NOT REPRINT
© FORTINET

The file-based method of submitting a CSR is a manual process. The SCEP process, which occurs
automatically online, requires no manual file import.

You can import the certificate from the Certificates page. Click Import and select Local Certificate. On the
Import Certificate dialog, in the Type field, select Local Certificate and browse to the CER file provided by
the CA.

After you import the certificate, the status changes from Pending to Valid. Note that it is possible to add a
certificate that FortiGate uses in SSL communications without generating and signing a CSR. The CA can
create a certificate for your FortiGate without a CSR (though the CA is responsible for providing all the
certificate details for your FortiGate device). In this way, you can add a certificate using the following methods:

• Upload a PKCS#12 file, which is a single file that includes the signed certificate file and the key file
• Upload both a certificate file and the key file

An administrator user with the super_admin profile can put a password on a certificate and control access to
its private key.

FortiGate Security 7.0 Study Guide 352

 Certificate Operations

DO NOT REPRINT
© FORTINET

You can also import local certificate which gets provisioned by an external service using the ACME protocol.
Defined in RFC 8555, automated local certificate import can use the public Let’s Encrypt CA to provide free
SSL server certificates. You can configure FortiGate to use a certificate managed by Let’s Encrypt and other
certificate management services that use the ACME protocol.

Importing ACME certificates must meet the following criteria:

• FortiGate must have a public IP address and a hostname FQDN that resolves to the same public IP
address.
• The public facing interface that ACME can access must have no virtual IP configured to forward port 80
(HTTP) or 443 (HTTPS). The interface has to listen for ACME update requests.
• SAN field is automatically filed with the FortiGate FQDN. It cannot be edited or allowed to have multiple
SANs or wildcards.

FortiGate Security 7.0 Study Guide 353

 Certificate Operations

DO NOT REPRINT
© FORTINET

When FortiGate is validating a certificate, it checks that the certificate serial number is not listed in a CRL
imported to FortiGate.

You can import a CRL from the Certificates page by clicking Import > CRL. In the Import CRL dialog, you
can select one of these four import options: HTTP, LDAP, SCEP, and File Based. The first three options
point to external repositories and require you to connect to the repositories to upload the CRL to FortiGate.
The last option, File Based, requires you to have the CRL file locally stored before you can upload the CRL to
FortiGate.

Before the CRL expires, FortiGate automatically retrieves the latest iteration using the protocol specified in the
configuration.

FortiGate Security 7.0 Study Guide 354

 Certificate Operations

DO NOT REPRINT
© FORTINET

When you back up the FortiGate configuration, the keys and certificates are backed up as well.

FortiGate also provides the option to store digital certificates as a PKCS#12 file, which includes the private
and public keys as well as the certificate. You can restore the PKCS#12 file to a FortiGate device of any
model or firmware version, or to a non-FortiGate device.

You can perform the backup and restore on the CLI only, which requires the use of a TFTP server.

FortiGate Security 7.0 Study Guide 355

 Certificate Operations

DO NOT REPRINT
© FORTINET

You can configure a CA and local certificate globally or for a VDOM. If you upload a certificate to a VDOM, it
is accessible only inside that VDOM. If you upload a certificate globally, it is accessible to all VDOMs and
globally.

Global and VDOM-based certificate configuration includes the ability to view certificate details, as well as to
download, delete, and import certificates.

Note that some of the FortiGate certificates have specific signature algorithms and key lengths in their names,
such as Elliptic Curve Digital Signature Algorithm 256 (ECDSA256) and RSA2048. Policy and technical
requirements may determine which certificates you use.

FortiGate Security 7.0 Study Guide 356

 Certificate Operations

DO NOT REPRINT
© FORTINET

If you are using an SSL certificate issued by a private CA, you must install the CA certificate in the list of
trusted CAs. If you fail to do this, a warning message appears in your web browser any time you access an
HTTPS website. Encrypted communications might also fail, simply because the CA that issued and signed the
certificate is untrusted.

Once you download the SSL certificate from FortiGate, you can install it on any web browser or operating
system. Not all browsers use the same certificate repository. For example, Firefox uses its own repository,
while Internet Explorer and Chrome store certificates in a system-wide repository. In order to avoid certificate
warnings, you need to install the SSL certificate as a trusted root CA.

When you install the certificate, make sure that you save it to the certificate store for root authorities.

FortiGate Security 7.0 Study Guide 357

 Certificate Operations

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 358

 Certificate Operations

DO NOT REPRINT
© FORTINET

Congratulations! You have completed this lesson.

Now, you will review the objectives that you covered in this lesson.

FortiGate Security 7.0 Study Guide 359

 Certificate Operations

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

By mastering the objectives covered in this lesson, you learned how FortiGate uses certificates, and how to
manage and work with certificates in your network.

FortiGate Security 7.0 Study Guide 360

 Web Filtering

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to configure web filtering on FortiGate to control web traffic in your network.

FortiGate Security 7.0 Study Guide 361

 Web Filtering

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the topics shown on this slide.

FortiGate Security 7.0 Study Guide 362

 Web Filtering

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding inspection modes, you will be able to implement the
appropriate inspection modes to support the desired security profiles.

FortiGate Security 7.0 Study Guide 363

 Web Filtering

DO NOT REPRINT
© FORTINET

Each inspection component plays a role in processing traffic on its way to its destination. Having control over
flow-based and proxy-based mode is helpful if you want to be sure that only flow-based inspection mode is
used. In most cases, proxy mode is preferred because more security profile features and more configuration
options are available. However, some implementations require all security profile scanning to use only flow-
based inspection mode for the highest possible throughput. You can configure the firewall policy to use flow-
based mode (which is the default option for a new policy), and vice versa. While both modes offer significant
security, proxy-based mode is more thorough while flow-based mode is designed to optimize performance.

You can select the inspection mode in a firewall policy. Switching from flow-based to proxy-based mode will
not require removing the selected security profiles on the policy. However, switching from proxy-based to
flow-based mode will remove any security profiles configured to use proxy-based inspection mode.

FortiGate Security 7.0 Study Guide 364

 Web Filtering

DO NOT REPRINT
© FORTINET

Flow-based inspection mode examines the file as it passes through FortiGate, without any buffering. As each
packet arrives, it is processed and forwarded without waiting for the complete file or web page. If you are
familiar with the TCP flow analysis of Wireshark, then that is essentially what the flow engine sees. Packets
are analyzed and forwarded as they are received. Original traffic is not altered. Therefore, advanced features
that modify content, such as safe search enforcement, are not supported.

The advantages of flow-based mode are:

• The user sees a faster response time for HTTP requests compared to proxy based
• There is less chance of a time-out error because of the server at the other end responding slowly

The disadvantages of flow-based mode are:

• A number of security features that are available in proxy-based mode are not available in flow-based mode
• Fewer actions are available based on the categorization of the website by FortiGuard services

FortiGate Security 7.0 Study Guide 365

 Web Filtering

DO NOT REPRINT
© FORTINET

Proxy-based scanning refers to transparent proxy. It’s called transparent because, at the IP layer, FortiGate is
not the destination address, but FortiGate does intercept the traffic. When proxy-based inspection is enabled,
FortiGate buffers traffic and examines it as a whole, before determining an action. Because FortiGate
examines the data as a whole, it can examine more points of data than it does when using flow-based
inspection.

In TCP connections, the FortiGate proxy generates the SYN-ACK to the client, and completes the three-way
handshake with the client, before creating a second, new connection to the server. If the payload is less than
the oversize limit, the proxy buffers transmitted files or emails for inspection, before continuing transmission.
The proxy analyzes the headers and may change the headers, such as HTTP host and URL, for web filtering.
If a security profile decides to block the connection, the proxy can send a replacement message to the client.
This adds latency to the overall transmission speed.

Proxy-based inspection is more thorough than flow-based inspection, yielding fewer false positives and
negative results.

FortiGate Security 7.0 Study Guide 366

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate web filters are also security profiles. The security profiles are customizable, according to the
selected inspection mode. So, the first step, before setting up a web filter, is to configure the inspection mode.

The protocol options profile determines the protocols your security profiles use, for example, to inspect web or
DNS traffic.

Note that HTTPS inspection port numbers, and other settings related to the handling of SSL, are defined
separately in the SSL/SSH inspection profile.

FortiGate Security 7.0 Study Guide 367

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate, or the individual VDOM, has two next-generation firewall (NGFW) modes available:
1. Profile-based mode: Requires administrators to create and use application control and web filter profiles
and apply them to a firewall policy. Profile-based mode is applicable to use flow-based or proxy-based
inspection mode as per the policy.
2. Policy-based mode: Administrators can apply application control and web filter configuration directly to a
security policy. Flow-based inspection mode is the only applicable process available in policy-based
NGFW mode.

Antivirus scanning is available as a security profile that you can apply in a profile-based NGFW mode firewall
policy or policy-based NGFW mode security policy.

You can change NGFW mode in the system settings of FortiGate or the individual VDOM. Note that the
change will require you to remove all existing policies in either mode.

FortiGate Security 7.0 Study Guide 368

 Web Filtering

DO NOT REPRINT
© FORTINET

If you configured FortiGate to use NGFW policy-based mode or created a VDOM specifically to provide
NGFW policy-based mode, you must configure a few policies to allow traffic.

SSL Inspection & Authentication (consolidated) policy: This allows traffic from a specific user or user group to
match the criteria specified within the consolidated policy and inspect SSL traffic using the SSL inspection
profile selected. FortiGate can either accept or deny the traffic.

Security policy: If the traffic is allowed as per the consolidated policy, FortiGate then processes it based on the
security policy to analyze additional criteria, such as URL categories for web filtering and application control.
Also, if enabled, the security policy further inspects traffic using security profiles such as AV, IPS, and file
filter.

FortiGate Security 7.0 Study Guide 369

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 370

 Web Filtering

DO NOT REPRINT
© FORTINET

Good job! You now understand inspection modes.

Now, you will learn about web filtering basics.

FortiGate Security 7.0 Study Guide 371

 Web Filtering

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in web filtering basics, you will be able to describe web filter profiles, use
FortiGuard web filter profiles, configure web filter overrides, define custom categories, and submit FortiGuard
rating requests.

FortiGate Security 7.0 Study Guide 372

 Web Filtering

DO NOT REPRINT
© FORTINET

Web filtering helps to control, or track, the websites that people visit. There are many reasons why network
administrators apply web filtering, including to:
• Preserve employee productivity
• Prevent network congestion, where valuable bandwidth is used for non-business purposes
• Prevent loss or exposure of confidential information
• Decrease exposure to web-based threats
• Limit legal liability when employees access or download inappropriate or offensive material
• Prevent copyright infringement caused by employees downloading or distributing copyrighted materials
• Prevent children from viewing inappropriate material

FortiGate Security 7.0 Study Guide 373

 Web Filtering

DO NOT REPRINT
© FORTINET

(slide contains animation)

The example on this slide shows the flow of an HTTP filter process.

FortiGate looks for the HTTP GET request to collect URL information and perform web filtering.

So, as shown, in HTTP the domain name and URL are separate pieces. The domain name might look like the
following in the header: Host: www.acme.com, and the URL might look like the following in the header:
/index.php?login=true.

If you filter by domain, sometimes it blocks too much. For example, the blogs on tumblr.com are considered
different content, because of all the different authors. In that case, you can be more specific, and block by the
URL part, tumblr.com/hacking, for example.

FortiGate Security 7.0 Study Guide 374

 Web Filtering

DO NOT REPRINT
© FORTINET

Now, you will look at the web filter profile.

You can configure this security profile to use a feature set for proxy-based or flow-based inspection modes.
However, depending on the mode you select, the available settings are different. Flow-based inspection has
fewer available options.

In the examples shown on this slide, the web filter profile has a FortiGuard category-based filter that
categorizes the websites based on categories and subcategories by FortiGuard. FortiGate offers two NGFW
options:
• Profile-Based (default)
• Web filters are defined as security profiles and applied to the firewall policy
• Policy-Based
• URL categories are defined directly under the firewall policy

FortiGate Security 7.0 Study Guide 375

 Web Filtering

DO NOT REPRINT
© FORTINET

In the example shown on this slide, the security profile is configured to use a proxy-based feature set. The
profile is available to a firewall policy configured to use proxy-based inspection mode. Other local options
include:
• Search Engines
• Static URL Filter
• Rating Options
• Proxy Options

After you configure your web filter profile, apply this profile to your firewall policy so the filtering is applied to
your web traffic.

FortiGate Security 7.0 Study Guide 376

 Web Filtering

DO NOT REPRINT
© FORTINET

Rather than block or allow websites individually, FortiGuard category filtering looks at the category that a
website has been rated with. Then, FortiGate takes action based on that category, not based on the URL.

FortiGuard category filtering is a live service that requires an active contract. The contract validates
connections to the FortiGuard network. If the contract expires, there is a two-day grace period during which
you can renew the contract before the service cuts off. If you do not renew, after the two-day grace period,
FortiGate reports a rating error for every rating request made. In addition, by default, FortiGate blocks web
pages that return a rating error. You can change this behavior by enabling the Allow websites when a rating
error occurs setting. You will learn more about this setting in this lesson.

You can configure FortiManager to act as a local FortiGuard server. To do this, you must download the
databases to FortiManager, and configure FortiGate to validate the categories against FortiManager, instead
of FortiGuard.

FortiGate Security 7.0 Study Guide 377

 Web Filtering

DO NOT REPRINT
© FORTINET

Website categories are determined by both automatic and human methods. The FortiGuard team has
automatic web crawlers that look at various aspects of the website in order to come up with a rating. There
are also people who examine websites and look into rating requests to determine categories.

To review the complete list of categories and subcategories, visit

www.fortiguard.com/webfilter/categories.

FortiGate Security 7.0 Study Guide 378

 Web Filtering

DO NOT REPRINT
© FORTINET

So, how does it work?

FortiGate queries the FDN—or FortiManager, if it has been configured to act as a local FortiGuard server—to
determine the category of a requested web page.

When users visit websites, FortiGate uses the FortiGuard live service to determine the category that the URL
belongs to and takes a configured action for that category, such as allow or block access. Using this feature,
you can perform bulk URL filtering, without individually defining each website.

You can enable the FortiGuard category filtering on the web filter, or DNS filter profiles. Categories and
subcategories are listed, and you can customize the actions to perform individually.

The actions available depend on the mode of inspection:

• Proxy: Allow, Block, Monitor, Warning, and Authenticate
• Flow-based, profile-based: Allow, Block, Monitor, Warning, and Authenticate
• Flow-based, policy-based: Action defined in a security policy (accept or deny)

FortiGate Security 7.0 Study Guide 379

 Web Filtering

DO NOT REPRINT
© FORTINET

The warning action informs users that the requested website is not allowed by the internet policies. However,
the action gives the user the option to proceed to the requested website, or return to the previous website.

You can customize the warning interval, so you can present this warning page at specific times, according to
the configured period.

FortiGate Security 7.0 Study Guide 380

 Web Filtering

DO NOT REPRINT
© FORTINET

The authenticate action blocks the requested websites, unless the user enters a successful username and
password.

You can customize the interval of time to allow access. Users are not prompted to authenticate again if they
access other websites in the same category until the timer expires.

Choosing this action prompts you to define user groups that are allowed to override the block.

FortiGate Security 7.0 Study Guide 381

 Web Filtering

DO NOT REPRINT
© FORTINET

The Threat Feeds feature enables FortiGate to dynamically import external block lists from an HTTP server.
You can use the block lists to enforce special security requirements specified by your organization. These
requirements can include long-term policies to always block access to specific websites, or short-term
requirements to block access to known compromised locations. These block lists are text files that are in plain
text format, where each line contains a single URL to be blocked.

Because the lists are dynamically imported, any changes made to the list are instantly imported by FortiOS
using the Security Fabric feature.

FortiGuard Category: This resource name appears as a remote category in web filter profiles and SSL
inspection exemptions.
IP Address: This resource name appears as an external IP block list in DNS filter profiles and as a
source/destination in IPv4 policy, IPv6, and Proxy policy.
Domain Name: This resource name will appear as a remote category in DNS filter profiles.
Refresh Rate: Using this setting, you can specify how often, in minutes, block lists can be refreshed from the
external source.

The size of the block list file can be 10 MB or 128,000 lines of text, whichever is most restrictive.

Note that the DNS profile supports only IPv4 addresses and ignores IPv6 addresses.

FortiGate Security 7.0 Study Guide 382

 Web Filtering

DO NOT REPRINT
© FORTINET

You can add dynamic block lists to:

• Web filter profiles and SSL inspection exemptions
• DNS filter profiles and source/destination addresses in firewall policies

FortiGate Security 7.0 Study Guide 383

 Web Filtering

DO NOT REPRINT
© FORTINET

When using FortiGuard category filtering to allow or block access to a website, one option is to make a web
rating override and define the website in a different category. Web ratings are only for host names—no URLs
or wildcard characters are allowed.

If the contract expires, and the two-day grace period passes, web rating overrides are not be effective. All
website category rating requests are returned with a rating error.

FortiGate Security 7.0 Study Guide 384

 Web Filtering

DO NOT REPRINT
© FORTINET

If you want to make an exception, for example, rather than unblock access to a potentially unwanted category,
change the website to an allowed category. You can also do the reverse. You can block a website that
belongs to an allowed category.

Remember that changing categories does not automatically result in a different action for the website. This
depends on the settings within the web filter profile.

FortiGate Security 7.0 Study Guide 385

 Web Filtering

DO NOT REPRINT
© FORTINET

If the predefined categories in FortiGuard are not suitable for the situation, you can add additional custom
categories.

You can add and delete custom categories as needed, as long as they are not in use.

FortiGate Security 7.0 Study Guide 386

 Web Filtering

DO NOT REPRINT
© FORTINET

Static URL filtering is another web filter feature. Configured URLs in the URL filter are checked against the
visited websites. If a match is found, the configured action is taken. URL filtering has the same patterns as
static domain filtering: simple, regular expressions, and wildcard.

Take a look at how it works.

When a user visits a website, FortiGate looks at the URL list for a matching entry. In the example shown on
this slide, the website matches the third entry in the table, which is set as type Simple. This type means that
the match must be exact—there is no option for a partial match with this pattern. Also, the action is set to
Block, so FortiGate displays a block page message.

FortiGate Security 7.0 Study Guide 387

 Web Filtering

DO NOT REPRINT
© FORTINET

There is always the possibility for errors in ratings, or a scenario where you simply do not agree with the rating
given. In that case, you can use the web portal to contact the FortiGuard team to submit a website for a new
rating, or get it rated if it is not already in the database.

FortiGate Security 7.0 Study Guide 388

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 389

 Web Filtering

DO NOT REPRINT
© FORTINET

Good job! You now understand the basics of web filtering.

Now, you will learn about additional proxy-based web filtering features.

FortiGate Security 7.0 Study Guide 390

 Web Filtering

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in additional proxy-based web filtering features, you will be able to configure
usage quotas, web profile overrides, search engine filters, and web content filtering.

FortiGate Security 7.0 Study Guide 391

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate also includes a feature to customize the quotas of time to access the categories that are set to
monitor, warning, or authenticate in the web filter profile in proxy-based inspection mode.

You can customize multiple quotas (timers). Each quota can be applied to either a single category or multiple
categories. If the quota applies to multiple categories, the timer is shared among all the categories instead of
having a single timer for each individual category.

FortiGate automatically assigns quotas for each source IP, or each user if the authentication action is used, as
the dashboard monitor shows. By default, the dashboard monitor is not added. You can click the + symbol to
add FortiGuard Quota monitor to the User & Authentication section.

Now, take a look at how quotas work.

FortiGate Security 7.0 Study Guide 392

 Web Filtering

DO NOT REPRINT
© FORTINET

As shown on this slide, the FortiGuard quota limits the time users spend on websites, based on category. You
can also set a quota, on the amount of traffic that can be allowed to a particular category.

A quota cannot redirect the user once the website is loaded in their browser. For example, if the user has 45
seconds left in their quota, and they access a website from the specified category, the selected website will
likely finish loading before the remaining 45 seconds are up. Then, the user can stay on that website, and that
website won’t be blocked until the browser is refreshed. This scenario occurs because the connection to the
website is not, usually, a live stream. After you receive the information, the connection is closed.

Note that the quota resets every 24 hours at midnight.

FortiGate Security 7.0 Study Guide 393

 Web Filtering

DO NOT REPRINT
© FORTINET

You can also override the filter profile. Web profile overrides change the rules that are used to inspect traffic.
Overrides authorize specified users, user groups, or predefined source IPs, to use a different web filter profile
to inspect their traffic.

In the example shown on this slide, the new profile applied to the user student, inspects all of that user’s web
traffic from the time that the new profile is applied, until the timer expires. To use this override, you must
enable an override authentication. When you enable the web profile override, the FortiGuard block page
shows a link you can select to activate the override.

FortiGate Security 7.0 Study Guide 394

 Web Filtering

DO NOT REPRINT
© FORTINET

Search engine filtering is available when you configure a web filter profile while setting the feature set to
proxy-based.

Safe search is an option that some browsers support. It applies internal filters to the search results. When you
enable safe search for the supported search sites, FortiGate appends code to the URL to enforce the use of
safe search. For example, on a Google search, FortiGate adds the string &safe=active to the URL in the
search. So, even if it is not locally enabled in the browser, FortiGate applies safe search to the requests when
they pass through. Safe search is supported for Google, Yahoo, Bing, and Yandex.

As a proxy-based web filter feature, search engine filtering is supported only when using full SSL inspection
because FortiGate requires access to the full header.

FortiGate Security 7.0 Study Guide 395

 Web Filtering

DO NOT REPRINT
© FORTINET

You can also control web content in the web filter profile by blocking access to websites containing specific
words or patterns. This helps to prevent access to sites with questionable material.

You can add words, phrases, patterns, wildcards, and Perl regular expressions to match content on websites.
You configure this feature on a per-web-filter-profile basis, not at the global level. So, it is possible to add
multiple web content filter lists and then select the best list for each web filter profile.

The system administrator can specify banned words and phrases and attach a numerical value, or score, to
the importance of those words and phrases. When the web content filter scan detects banned content, it adds
the scores of banned words and phrases on the page. If the sum is higher than the threshold set in the web
filter profile, FortiGate blocks the site.

The maximum number of web content patterns in a list is 5000.

Like search engine filtering, web content filtering requires that FortiGate uses deep SSL inspection because
FortiGate requires full access to the packet headers.

FortiGate Security 7.0 Study Guide 396

 Web Filtering

DO NOT REPRINT
© FORTINET

You can use advanced web filtering settings to improve the web filter.

The rating options are as follows:

1. Allow websites when a rating error occurs. If a rating error occurs from the FortiGuard web filter
service, users have full unfiltered access to all websites.
2. Rate URLs by domain and IP Address. This option sends both the URL and the IP address of the
requested site for checking, providing additional security against attempts to bypass the FortiGuard
system.

FortiGate Security 7.0 Study Guide 397

 Web Filtering

DO NOT REPRINT
© FORTINET

If you configure the web filter profile to use a proxy-based feature set, the advanced proxy option settings for
web filtering are as follows:
1. Block access to some Google accounts and services. You can include an exception list.
2. HTTP POST is the command used by your browser when you send information, so you can limit the
information and files to websites. The Allow option prevents a server timeout when scanning, or when
other filtering processes are performed for outgoing traffic.
3. Filter cookies, Java applets, and ActiveX scripts from web traffic.

FortiGate Security 7.0 Study Guide 398

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 399

 Web Filtering

DO NOT REPRINT
© FORTINET

Good job! You now understand additional proxy-based web filtering features.

Now, you will learn about video filtering.

FortiGate Security 7.0 Study Guide 400