Network Address Translation (NAT)

DO NOT REPRINT
© FORTINET

Use the following best practices when implementing NAT:

• Avoid misconfiguring an IP pool range:

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

• Don’t configure a NAT rule for inbound traffic unless it is required by an application. For example, if there is
a matching NAT rule for inbound SMTP traffic, the SMTP server might act as an open relay.

• You must schedule a maintenance window to switch from central NAT mode to firewall policy NAT mode,
or from firewall policy NAT mode to central NAT mode. Switching between NAT modes can create a
network outage.

FortiGate Security 7.0 Study Guide 201

 Network Address Translation (NAT)

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 202

 Network Address Translation (NAT)

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 203

 Network Address Translation (NAT)

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 to understand and configure NAT so that
you can use it in your network.

FortiGate Security 7.0 Study Guide 204

 Firewall Authentication

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about using authentication on the firewall policies of FortiGate.

FortiGate Security 7.0 Study Guide 205

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

FortiGate Security 7.0 Study Guide 206

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in methods of firewall authentication, you will be able to describe and identify
the supported methods of firewall authentication available on FortiGate.

FortiGate Security 7.0 Study Guide 207

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Traditional firewalling grants network access by verifying the source IP address and device. This is
inadequate and can pose a security risk, because the firewall cannot determine who is using the device to
which it is granting access.

FortiGate includes authentication of users and user groups. As a result, you can follow individuals across
multiple devices.

Where access is controlled by a user or user group, users must authenticate by entering valid credentials
(such as username and password). After FortiGate validates the user, FortiGate applies firewall policies and
profiles to allow or deny access to specific network resources.

FortiGate Security 7.0 Study Guide 208

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate supports multiple methods of firewall authentication:

• Local password authentication

• Server-based password authentication (also called remote password authentication)
• Two-factor authentication
This is a system of authentication that is enabled on top of an existing method—it cannot be enabled
without first configuring one of the other methods. It requires something you know, such as a password,
and something you have, such as a token or certificate.

During this lesson, you will learn about each method of firewall authentication in detail.

FortiGate Security 7.0 Study Guide 209

 Firewall Authentication

DO NOT REPRINT
© FORTINET

The simplest method of authentication is local password authentication. User account information (username
and password) is stored locally on the FortiGate device. This method works well for a single FortiGate
installation.

Local accounts are created on the User Definition page where a wizard takes you through the process. For
local password authentication, select Local User as the user type and create a username and password. If
desired, you can also add email and SMS information to the account, enable two-factor authentication, and
add the user to a preconfigured user group.

After you create the user, you can add the user—or any preconfigured user group in which the user is a
member—to a firewall policy, in order to authenticate. You will learn about user groups and firewall policies in
this lesson.

FortiGate Security 7.0 Study Guide 210

 Firewall Authentication

DO NOT REPRINT
© FORTINET

When server-based password authentication is used, a remote authentication server authenticates users. This
method is desirable when multiple FortiGate devices need to authenticate the same users or user groups, or
when adding FortiGate to a network that already contains an authentication server.

When you use a remote authentication server to authenticate users, FortiGate sends the user’s entered
credentials to the remote authentication server. The remote authentication server responds by indicating
whether the credentials are valid or not. If valid, FortiGate consults its configuration to deal with the traffic.
Note that it is the remote authentication server—not FortiGate—that evaluates the user credentials.

When the server-based password authentication method is used, FortiGate does not store all (or, in the case
of some configurations, any) of the user information locally.

FortiGate Security 7.0 Study Guide 211

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate provides support for many remote authentication servers, including POP3, RADIUS, LDAP, and
TACACS+.

POP3 is the only server that requires an email address as the login credential. All other remote authentication
servers use the user name. Some POP3 servers require the full email with domain ([email protected]),
others require the suffix only, while still others accept both formats. This requirement is determined by the
configuration of the server and is not a setting on FortiGate. You can configure POP3 authentication only
though the CLI. Note that you can configure LDAP to validate with email, rather than the user name.

FortiGate Security 7.0 Study Guide 212

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can configure FortiGate to use external authentication servers in the following two ways:

• Create user accounts on FortiGate. With this method, you must select the remote authentication server
type (RADIUS, TACACS+, or LDAP), point FortiGate to your preconfigured remote authentication server,
and add the user to an appropriate group. This is usually done when you want to add two-factor
authentication to your remote users. Remember, POP3 is only configurable through the CLI.
• Add the remote authentication server to user groups. With this method, you must create a user group and
add the preconfigured remote server to the group. Accordingly, any user who has an account on the
remote authentication server can authenticate. If you are using other types of remote server, such as an
LDAP server, as the remote authentication server, you can control access to specific LDAP groups, as
defined on the LDAP server.

Similar to local password authentication, you must then add the preconfigured user group (in which the user is
a member) to a firewall policy in order to authenticate. You will learn about user groups and firewall policies
later in this lesson.

FortiGate Security 7.0 Study Guide 213

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Traditional user authentication requires your user name plus something you know, such as a password. The
weakness with this traditional method of authentication is that if someone obtains your user name, they need
only your password to compromise your account. Furthermore, since people tend to use the same password
across multiple accounts (some sites with more security vulnerabilities than others), accounts are vulnerable
to attack, regardless of password strength.

Two-factor authentication, on the other hand, requires something you know, such as a password, and
something you have, such as a token or certificate. Because this method places less importance on, often
vulnerable passwords, it makes compromising the account more complex for an attacker. You can use two-
factor authentication on FortiGate with both user and administrator accounts. The user (or user group to which
the user belongs) is added to a firewall policy in order to authenticate. Note that you cannot use two-factor
authentication with explicit proxies.

You can use one-time passwords (OTPs) as your second factor. OTPs are more secure than static
passwords because the passcode changes at regular intervals and is valid for only a short amount of time.
Once you use the OTP, you can’t use it again. So, even if it is intercepted, it is useless. FortiGate can deliver
OTPs through tokens, such as FortiToken 200 (hardware token) and FortiToken Mobile (software token), as
well as through email or SMS. To deliver an OTP over email or SMS, the user account must contain user
contact information.

FortiTokens and OTPs delivered through email and SMS are time based. FortiTokens, for example, generate
a new, six-digit password every 60 seconds (by default). An NTP server is highly recommended to ensure the
OTPs remain in sync. FortiToken Mobile Push allows users to accept the authorization request from their
FortiToken mobile app, without the need to enter an additional code.

FortiGate Security 7.0 Study Guide 214

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Tokens use a specific algorithm to generate an OTP. The algorithm consists of:

• A seed: a unique, randomly-generated number that does not change over time
• The time: obtained from an accurate internal clock

Both seed and time go through an algorithm that generates an OTP (or passcode) on the token. The
passcode has a short life span, usually measured in seconds (60 seconds for FortiToken 200, possibly more
or less for other RSA key generators). Once the life span ends, a new passcode generates.

When using two-factor authentication using a token, the user must first log in with a static password followed
by the passcode generated by the token. A validation server (FortiGate) receives the user’s credentials and
validates the static password first. The validation server then proceeds to validate the passcode. It does so by
regenerating the same passcode using the seed and system time (which is synchronized with the one on the
token) and comparing it with the one received from the user. If the static password is valid, and the OTP
matches, the user is successfully authenticated. Again, both the token and the validation server must use the
same seed and have synchronized system clocks. As such, it is crucial that you configure the date and time
correctly on FortiGate, or link it to an NTP server (which is recommended).

FortiGate Security 7.0 Study Guide 215

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can add a FortiToken 200 or FortiToken Mobile to FortiGate on the FortiTokens page.

A hard token has a serial number that provides FortiGate with details on the initial seed value. If you have
several hard tokens to add, you can import a text file, where one serial number is listed per line.

A soft token requires an activation code. Note that each FortiGate (and FortiGate VM) provides two free
FortiToken Mobile activations. You must purchase any additional tokens from Fortinet.

You cannot register the same FortiToken on more than one FortiGate. If you want to use the same FortiToken
for authentication on multiple FortiGate devices, you must use a central validation server, such as
FortiAuthenticator. In that case, FortiTokens are registered and assigned to users on FortiAuthenticator, and
FortiGate uses FortiAuthenticator as its validation server.

After you have registered the FortiToken devices with FortiGate, you can assign them to users to use as their
second-factor authentication method. To assign a token, edit (or create) the user account and select Enable
Two-factor Authentication. On the Token drop-down list, select the registered token you want to assign.

FortiGate Security 7.0 Study Guide 216

 Firewall Authentication

DO NOT REPRINT
© FORTINET

All the authentication methods you’ve learned about—local password authentication, server-based
authentication, and two-factor authentication—use active authentication. Active authentication means that
users are prompted to manually enter their login credentials before being granted access.

But not all users authenticate the same way. Some users can be granted access transparently, because user
information is determined without asking the user to enter their login credentials. This is known as passive
authentication. Passive authentication occurs with the single sign-on method for server-based password
authentication: FSSO, RSSO, and NTLM.

FortiGate Security 7.0 Study Guide 217

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 218

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand the basics of firewall authentication.

Now, you will learn about remote authentication servers.

FortiGate Security 7.0 Study Guide 219

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in remote authentication servers, you will be able to configure firewall
authentication using remote user accounts defined on a remote authentication server.

FortiGate Security 7.0 Study Guide 220

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Lightweight Directory Access Protocol (LDAP) is an application protocol used for accessing and maintaining
distributed directory information services.

The LDAP protocol is used to maintain authentication data that may include departments, people, groups of
people, passwords, email addresses, and printers. LDAP consists of a data-representation scheme, a set of
defined operations, and a request-and-response network.

The LDAP protocol includes a number of operations that a client can request, such as search, compare, and
add or delete an entry. Binding is the operation in which the LDAP server authenticates the user. If the user is
successfully authenticated, binding allows the user access to the LDAP server, based on that user’s
permissions.

FortiGate Security 7.0 Study Guide 221

 Firewall Authentication

DO NOT REPRINT
© FORTINET

The root of the LDAP directory tree represents the organization itself, and is defined as a domain component
(DC). The DC is usually a DNS domain, such as example.com. (Because the name contains a dot, it is written
as two parts separated by a comma: dc=example,dc=com.) You can add additional entries, known as objects,
to the hierarchy as needed. Generally, two types of objects make up most entries: containers and leafs.

Containers are objects that can include other objects, similar to a folder in a file system. Example containers
include:
• Country (represented as c)
• Organizational unit (represented as ou)
• Organization (represented as o)

Leafs are objects at the end of a branch and have no subordinate objects. Example leafs include:
• User ID (represented as uid)
• Common name (represented as cn)

FortiGate Security 7.0 Study Guide 222

 Firewall Authentication

DO NOT REPRINT
© FORTINET

This slide shows an example of a simple LDAP hierarchy.

You must configured the FortiGate device (acting as an LDAP client) requesting authentication to address its
request to the part of the hierarchy where user records exist: either the domain component, or a specific
container where the record exists. Similar to users, containers have DNs, and in this example, the DN is
ou=people,dc=example,dc=com.

The authentication request must also specify the user account entry. This can be one of many options
including the common name (cn) or, on a computer network, the user ID (uid), which is the information users
use to log in. Note that if the object name includes a space, such as John Smith, you must enclose the text
with double quotes when testing in the CLI. For example: cn=“John Smith”.

FortiGate Security 7.0 Study Guide 223

 Firewall Authentication

DO NOT REPRINT
© FORTINET

On the LDAP Servers page, you can configure FortiGate to point to an LDAP server for server-based
password authentication. The configuration depends heavily on the server’s schema and security settings.
Windows Active Directory (AD) is very common.

The Common Name Identifier setting is the attribute name you use to find the user name. Some schemas
allow you to use the attribute uid. AD most commonly uses sAMAccountName or cn, but can use others as
well.

The Distinguished Name setting identifies the top of the tree where the users are located, which is generally
the dc value; however, it can be a specific container or ou. You must use the correct X.500 or LDAP format.

The Bind Type setting depends on the security settings of the LDAP server. You must use the setting
Regular (to specify a regular bind) if you are searching across multiple domains and require the credentials of
a user that is authorized to perform LDAP queries (for example, an LDAP administrator).

If you want to have a secure connection between FortiGate and the remote LDAP server, enable Secure
Connection and include the LDAP server protocol (LDAPS or STARTTLS) as well as the CA certificate that
verifies the server certificate.

Note that the Test Connectivity button only tests whether the connection to the LDAP server is successful or
not. To test whether a user’s credentials can successfully authenticate, you can use the Test User
Credentials button, or you can use the CLI.

FortiGate Security 7.0 Study Guide 224

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Use the diagnose test authserver command on the CLI to test whether a user’s credentials can
successfully authenticate. You want to ensure that authentication is successful, before implementing it on any
of your firewall policies.

The response from the server reports success, failure, and group membership details.

FortiGate Security 7.0 Study Guide 225

 Firewall Authentication

DO NOT REPRINT
© FORTINET

RADIUS is much different from LDAP, because there is no directory tree structure to consider. RADIUS is a
standard protocol that provides authentication, authorization, and accounting (AAA) services.

When a user is authenticating, the client (FortiGate) sends an ACCESS-REQUEST packet to the RADIUS
server. The reply from the server is one of the following:

• ACCESS-ACCEPT, which means that the user credentials are ok

• ACCESS-REJECT, which means that the credentials are wrong
• ACCESS-CHALLENGE, which means that the server is requesting a secondary password ID, token, or
certificate. This is typically the reply from the server when using two-factor authentication.

Not all RADIUS clients support the RADIUS challenge method.

FortiGate Security 7.0 Study Guide 226

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can configure FortiGate to point to a RADIUS server for server-based password authentication through
the RADIUS Servers page.

The Primary Server IP/Name setting is the IP address or FQDN of the RADIUS server.

The Primary Server Secret setting is the secret that was set up on the RADIUS server in order to allow
remote queries from this client. Backup servers (with separate secrets) can be defined in case the primary
server fails. Note that FortiGate must be listed on the RADIUS server as a client of that RADIUS server or
else the server will not reply to queries done by FortiGate.

The Authentication Method setting refers to the authentication protocol that the RADIUS server supports.
Options include chap, pap, mschap, and mschap2. If you select Default, FortiGate will use pap, mschap2,
and chap (in that order).

Unlike LDAP configurations, the Test Connectivity button used in the example shown on this slide can test
actual user credentials, but, like LDAP, you can also test this using the CLI.

The Include in every User Group option adds the RADIUS server and all users that can authenticate against
it, to every user group created on FortiGate. So, you should enable this option only in very specific scenarios
(for example, when only administrators can authenticate against the RADIUS server and policies are ordered
from least restrictive to most restrictive).

FortiGate Security 7.0 Study Guide 227

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Testing RADIUS is much the same as testing LDAP. Use the diagnose test authserver command on
the CLI to test whether a user’s credentials can successfully authenticate. Again, you should do this to ensure
authentication is successful before implementing it on any of your firewall policies.

Like LDAP, it reports success, failure, and group membership details, depending on the server’s response.
Deeper troubleshooting usually requires RADIUS server access.

Note that Fortinet has a vendor-specific attributes (VSA) dictionary to identify the Fortinet-proprietary RADIUS
attributes. This capability allows you to extend the basic functionality of RADIUS. You can obtain the Fortinet
VSA dictionary from the Fortinet Knowledge Base (kb.fortinet.com).

FortiGate Security 7.0 Study Guide 228

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 229

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand the basics of remote authentication servers.

Now, you will learn about user groups.

FortiGate Security 7.0 Study Guide 230

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in user groups, you will be able to configure user groups to efficiently manage
firewall policies.

FortiGate Security 7.0 Study Guide 231

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate allows administrators to assign users to groups. Usually, groups are used to more effectively
manage individuals that have some kind of shared relationship. You might want to group employees by
business area, such as finance or HR, or by employee type, such as contractors or guests.

After you create user groups, you can add them to firewall policies. This allows you to control access to
network resources, because policy decisions are made on the group as a whole. You can define both local
and remote user groups on a FortiGate device. There are four user group types:

• Firewall
• Guest
• Fortinet single sign-on (FSSO)
• RADIUS single sign-on (RSSO)

The firewall user groups on FortiGate do not need to match any type of group that may already exist on an
external server, such as an LDAP server. The firewall user groups exist solely to make configuration of
firewall policies easier.

Most authentication types have the option to make decisions based on the individual user, rather than just
user groups.

FortiGate Security 7.0 Study Guide 232

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Guest user groups are different from firewall user groups because they contain exclusively temporary guest
user accounts (the whole account, not just the password). Guest user groups are most commonly used in
wireless networks. Guest accounts expire after a predetermined amount of time.

Administrators can manually create guest accounts or create many guest accounts at once using randomly
generated user IDs and passwords. This reduces administrator workload for large events. Once created, you
can add accounts to the guest user group and associate the group with a firewall policy.

You can create guest management administrators that have access only to create and manage guest user
accounts.

FortiGate Security 7.0 Study Guide 233

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can configure user groups on the User Groups page. You must specify the user group type and add
users to the group. Depending on the group you create, you require different configurations. For the firewall
user group, for example, members can consist of local users, PKI peer users, and users from one or more
remote authentication servers. If your remote authentication server is an LDAP server, you can select specific
LDAP groups to add to your user group, as defined on the LDAP server. Note that you can also select
RADIUS groups, but this requires additional configuration on your RADIUS server and FortiGate (see the
Fortinet Knowledge Base at kb.fortinet.com).

User groups simplify your configuration if you want to treat specific users in the same way, for example, if you
want to provide the entire training department with access to the same network resources. If you want to treat
all users differently, you need to add all users to firewall policies separately.

FortiGate Security 7.0 Study Guide 234

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 235

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand the basics of user groups.

Now, you will learn about using firewall policies for authentication.

FortiGate Security 7.0 Study Guide 236

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

By demonstrating competence with firewall policies, you will be able to configure firewall policies to enforce
authentication on specific users and user groups.

FortiGate Security 7.0 Study Guide 237

 Firewall Authentication

DO NOT REPRINT
© FORTINET

A firewall policy consists of access and inspection rules (compartmentalized sets of instructions) that tell
FortiGate how to handle traffic on the interface whose traffic they filter. After the user makes an initial
connection attempt, FortiGate checks the firewall policies to determine whether to accept or deny the
communication session. However, a firewall policy also includes a number of other instructions, such as those
dealing with authentication. You can use the source of a firewall policy for this purpose. The source of a
firewall policy must include the source address (IP address), but you can also include the user and user
group. In this way, any user, or user group that is included in the source definition for the firewall policy can
successfully authenticate.

User and user group objects can consist of local firewall accounts, external server accounts, PKI users, and
FSSO users.

FortiGate Security 7.0 Study Guide 238

 Firewall Authentication

DO NOT REPRINT
© FORTINET

A firewall policy also checks the service in order to transport the named protocols or group of protocols. No
service (with the exception of DNS) is allowed through the firewall policy before successful user
authentication. DNS is usually used by HTTP so that people can use domain names for websites, instead of
their IP address. DNS is allowed because it is a base protocol and will most likely be required to initially see
proper authentication protocol traffic. Hostname resolution is almost always a requirement for any protocol.
However, the DNS service must still be defined in the policy as allowed, in order for it to pass.

In the example shown on this slide, policy sequence 1 (Full_Access) allows users to use external DNS
servers in order to resolve host names, before successful authentication. DNS is also allowed if authentication
is unsuccessful, because users need to be able to try to authenticate again. Any service that includes DNS
would function the same way, like the default ALL service.

HTTP service is TCP port 80 and does not include DNS (UDP port 53).

FortiGate Security 7.0 Study Guide 239

 Firewall Authentication

DO NOT REPRINT
© FORTINET

As well as the DNS service, the firewall policy must specify the allowed protocols, such as HTTP, HTTPS,
FTP, and Telnet. If the firewall policy that has authentication enabled does not allow at least one of the
supported protocols used for obtaining user credentials, the user will not be able to authenticate.

Protocols are required for all authentication methods that use active authentication (local password
authentication, server-based password authentication, and two-factor authentication). Active authentication
prompts the user for user credentials based on the following:

• The protocol of the traffic

• The firewall policy

Passive authentication, on the other hand, determines the user identity behind the scenes, and does not
require any specific services to be allowed within the policy.

FortiGate Security 7.0 Study Guide 240

 Firewall Authentication

DO NOT REPRINT
© FORTINET

In the example shown on this slide, assuming active authentication is used, any initial traffic from
LOCAL_SUBNET will not match policy sequence 17 (Guest). Policy sequence 17 looks for both IP and user,
and user group information (LOCAL_SUBNET and Guest-group respectively), and since the user has not yet
authenticated, the user group aspect of the traffic does not match. Since the policy match is not complete,
FortiGate continues its search down the sequence list, to see if there is a complete match.

Next, FortiGate evaluates policy sequence 18 to see if the traffic matches. It will not for the same reason it did
not match 17.

Finally, FortiGate evaluates policy sequence 19 to see if the traffic matches. It matches all criteria, so traffic is
allowed with no need to authenticate.

When you use only active authentication, if all possible policies that could match the source IP have
authentication enabled, then the user will receive a login prompt (assuming they use an acceptable login
protocol). In other words, if policy sequence 19 also had authentication enabled, the users would receive login
prompts.

If you use passive authentication and it can successfully obtain user details, then traffic from
LOCAL_SUBNET with users that belong to Guest-group will apply to policy sequence 17, even though policy
sequence 19 does not have authentication enabled.

If you use both active and passive authentication, and FortiGate can identify a user’s credentials through
passive authentication, the user never receives a login prompt, regardless of the order of any firewall policies.
This is because there is no need for FortiGate to prompt the user for login credentials when it can identify who
the user is passively. When you combine active and passive authentication methods, active authentication is

FortiGate Security 7.0 Study Guide 241

 Firewall Authentication

DO NOT REPRINT
© FORTINET
intended to be used as a backup, to be used only when passive authentication fails.

FortiGate Security 7.0 Study Guide 242

 Firewall Authentication

DO NOT REPRINT
© FORTINET

As mentioned earlier, there are three different ways you can alter active authentication behavior. If you have
an active authentication firewall policy followed by a fall-through policy that does not have authentication
enabled on it, then all traffic will use the fall-through policy. This means that users are not asked to
authenticate. By default, all traffic passes through the catch-all policy without being authenticated. You can
alter this behavior by enabling authentication on all firewall policies. When you enable authentication, all the
systems must authenticate before traffic is placed on egress interface.

Alternatively, only on the CLI, you can change the auth-on-demand option to always. This instructs
FortiGate to trigger an authentication request, if there is a firewall policy with active authentication enabled. In
this case, the traffic is allowed until authentication is successful.

If you want to have all users connect to a specific interface, then it is better to enable captive portal
authentication at the interface level. This way, all devices must authenticate before they are allowed to access
any resources.

FortiGate Security 7.0 Study Guide 243

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 244

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand how to use firewall policies for authentication.

Now, you will learn about authenticating though captive portal.

FortiGate Security 7.0 Study Guide 245

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in captive portal, you will be able to configure authentication through a captive
portal.

FortiGate Security 7.0 Study Guide 246

 Firewall Authentication

DO NOT REPRINT
© FORTINET

If you want all users connecting to the network to be prompted for their login credentials (active
authentication), you can enable captive portal. Captive portal is a convenient way to authenticate web users
on wired or Wi-Fi networks through an HTML form that requests a username and password.

You can host a captive portal on FortiGate or an external authentication server, such as FortiAuthenticator.

FortiGate Security 7.0 Study Guide 247

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You enable captive portal, for both wired and Wi-Fi networks, at the interface level—regardless of the firewall
policy that allows it or the port that it ultimately leaves by (authentication being enabled or disabled on the
policy is not a factor). This is true for any network interface, including Wi-Fi and VLAN interfaces. On the local
network, you must enable the captive portal setting on the incoming port.

You can configure a captive portal on the Interfaces page. Select the required interface. In the Network
section, enable Security mode, and on the drop-down list, select Captive Portal. Note that if you are
configuring captive portal for a Wi-Fi network, the Wi-Fi SSID must first exist.

Captive portals are not compatible with interfaces in DHCP mode.

FortiGate Security 7.0 Study Guide 248

 Firewall Authentication

DO NOT REPRINT
© FORTINET

In the Network section, you also restrict captive portal user access.

Select Restricted to Groups to control the access from the captive portal configuration.

Use the security-mode and security-groups settings in port configurations to make the same
changes on the CLI.

FortiGate Security 7.0 Study Guide 249

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can select Allow all to allow access to members of any groups configured on the firewall policies after
authentication.

Use the security-mode captive-portal setting in port configurations to enforce captive portal access
using the CLI. By omitting the security-groups setting the User access configuration is set to Allow all.

FortiGate Security 7.0 Study Guide 250

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can configure a firewall policy to suppress captive portal for specific addresses, or services. This is useful
for devices that are unable to actively authenticate, such as printers and fax machines, but still need to be
allowed by the firewall policy. When suppressed, traffic that matches the source or destination is not
presented with the captive portal login page.

There are two ways you can bypass captive portal:

• Through a security exemption list in the GUI or the CLI under config user security-exempt-list
• Through the firewall policy. In the CLI, edit the policy and enter the command set captive-portal-
exempt enable. All traffic matching this policy is now exempt from having to authenticate through the
captive portal.

FortiGate Security 7.0 Study Guide 251

 Firewall Authentication

DO NOT REPRINT
© FORTINET

If you want to enable a terms of service disclaimer to be used in combination with captive portal
authentication, you can do so by using the config firewall policy and set disclaimer enable
commands on the CLI. The terms of service disclaimer states the legal responsibilities of the user and the
host organization. When you enable the disclaimer, the user must agree to the terms outlined in the statement
in order to proceed to the requested URL. When enabled, the terms of service disclaimer opens immediately
following a successful authentication.

Neither a security exemption list, nor a captive portal exemption on a firewall, can bypass a disclaimer.

FortiGate Security 7.0 Study Guide 252

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate allows you to customize portal messages, which include the login page and disclaimer page. You
can customize the messages on the Replacement Messages page.

The disclaimer page is in HTML, so you must have knowledge of HTML in order to customize the message.
The default layout is Simple View, which hides most of the replacement messages. Use Extended View to
show all editable replacement messages.

FortiGate Security 7.0 Study Guide 253

 Firewall Authentication

DO NOT REPRINT
© FORTINET

An authentication timeout is useful for security purposes. It minimizes the risk of someone using the IP of the
legitimate authenticated user. It also ensures users do not authenticate and then stay in memory indefinitely. If
users stayed in memory forever, it would eventually lead to memory exhaustion.

There are three options for timeout behavior:

• Idle: looks at the packets from the host IP. If there are no packets generated by the host device in the
configured timeframe, then the user is logged out.
• Hard: time is an absolute value. Regardless of the user’s behavior, the timer starts as soon as the user
authenticates and expires after the configured value.
• New session: even if traffic is being generated on existing communications channels, the authentication
expires if no new sessions are created through the firewall from the host device within the configured
timeout value.

Choose the type of timeout that best suits the authentication needs of your environment.

FortiGate Security 7.0 Study Guide 254

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 255

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Good job! You now understand authenticating though captive portals.

Now, you will learn about monitoring and troubleshooting.

FortiGate Security 7.0 Study Guide 256

 Firewall Authentication

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in monitoring and troubleshooting, you will be able to monitor authenticated
users and troubleshoot any issues that may occur.

FortiGate Security 7.0 Study Guide 257

 Firewall Authentication

DO NOT REPRINT
© FORTINET

You can monitor users who authenticate through your firewall policies using the Dashboard > User &
Devices > Firewall Users page. It displays the user, user group, duration, IP address, traffic volume, and
authentication method.

It does not include administrators, because they are not authenticating through firewall policies that allow
traffic. They are logging in directly on FortiGate.

This page also allows you to disconnect a user, or multiple users, at the same time.

FortiGate Security 7.0 Study Guide 258

 Firewall Authentication

DO NOT REPRINT
© FORTINET

In the web-based manager, a good tool for troubleshooting is the Bytes column on the security policy page,
which you open by clicking Policy & Objects > Firewall Policy. This column displays the number of bytes
that have passed through this policy. This is valuable information to have when you are troubleshooting.
When you are testing your configuration (end-to-end connectivity, user authentication, and policy use)
watching the byte count for an increase can help with troubleshooting. An increase indicates if the policy in
question is seeing any traffic, which is useful information if you expect a user to require authentication, but
they are never prompted.

Use the following CLI commands to gather more information about users and user authentication attempts to
help troubleshoot failed authentication attempts:
• diagnose firewall auth list: shows authenticated users and their IP address.
• diagnose firewall auth clear: clears all authorized users from the current list. This is useful
when you need to force users to reauthenticate after system or group changes. However, this command
can easily result in many users having to reauthenticate, so use it carefully.
• diagnose debug application fnbamd -1: use this command to troubleshoot active authentication,
(You must use it in conjunction with diagnose debug enable.)
• diagnose test authserver radius-direct <ip> <port> <secret>: tests preshared key
between FortiGate and the RADIUS server.
• diagnose test authserver ldap <server_name> <username> <password>: tests LDAP
authentication for the specified user account.

FortiGate Security 7.0 Study Guide 259

 Firewall Authentication

DO NOT REPRINT
© FORTINET

Use the best practices listed on this slide to avoid unnecessary issues when configuring firewall
authentication.

FortiGate Security 7.0 Study Guide 260

 Firewall Authentication

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 261

 Firewall Authentication

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 262

 Firewall Authentication

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 to use authentication on the firewall
policies of FortiGate.

FortiGate Security 7.0 Study Guide 263

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to configure local and remote logging on FortiGate; view, search, and
monitor logs; and protect your log data.

FortiGate Security 7.0 Study Guide 264

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

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

FortiGate Security 7.0 Study Guide 265

 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 log basics, you will be able to more effectively analyze log data from your
database.

FortiGate Security 7.0 Study Guide 266

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

When traffic passes through FortiGate to your network, FortiGate scans the traffic, and then takes action
based on the firewall policies in place. This activity is recorded, and the information is contained in a log
message. The log message is stored in a log file. The log file is then stored on a device capable of storing
logs. FortiGate can store logs locally on its own disk space, or can send logs to an external storage device,
such as FortiAnalyzer.

The purpose of logs is to help you monitor your network traffic, locate problems, establish baselines, and
more. Logs provide you with a greater perspective of your network, allowing you to make adjustments to your
network security, if necessary.

Some organizations have legal requirements when it comes to logging, so it is important to be aware of your
organization’s policies during configuration.

For effective logging, your FortiGate system date and time should be accurate. You can either manually set
the system date and time, or configure FortiGate to keep its time correct automatically by synchronizing with a
Network Time Protocol (NTP) server. An NTP server is highly recommended.

FortiGate Security 7.0 Study Guide 267

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

To FortiGate, there are three different types of logs: traffic logs, event logs, and security logs. Each type is
further divided into subtypes.

Traffic logs record traffic flow information, such as an HTTP/HTTPS request and its response, if any. It
contains subtypes named forward, local, and sniffer.
• Forward traffic logs contain information about traffic that FortiGate either accepted or rejected according to
a firewall policy.
• Local traffic logs contain information about traffic directly to and from the FortiGate management IP
addresses. They also include connections to the GUI and FortiGuard queries.
• Sniffer logs contain information related to traffic seen by the one-arm sniffer.

Event logs record system and administrative events, such as adding or modifying a setting, or daemon
activities. It contains subtypes named endpoint control, high availability, system, user, router, VPN, WAD, and
wireless.
• System event logs contain information related to operations, such as automatic FortiGuard updates and
GUI logins.
• User logs contain logon and logoff events for firewall policies with user authentication.
• Router, VPN, WAD, and wireless subtypes include logs for those features. For example, VPN contains
IPsec and SSL VPN log entries.

Finally, security logs record security events, such as virus attacks and intrusion attempts. They contain log
entries based on the security profile type (log type = utm), including application control, antivirus, DLP, anti-
spam (email filter), web filter, intrusion protection, anomaly (DoS-policy), and WAF. Security logs and
subtypes are only visible in the GUI if logs are created within it—if no security logs exists, the menu item does
not appear.

FortiGate Security 7.0 Study Guide 268

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Each log entry includes a log level (or priority level) that ranges in order of importance from emergency to
information.

There is also a debug level. It puts diagnostic information into the event log. The debug level is rarely used,
unless you are actively investigating an issue with Fortinet Support. Generally, the lowest level you want to
use is information, but even this level generates many logs and can cause premature hard disk failure.
Depending on the type of log and the needs of your organization, you may want to log only notification levels
or higher.

You and your organization’s policies dictate what must be logged.

FortiGate Security 7.0 Study Guide 269

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Every log message has a standard layout comprising two sections: a header and a body.

The header contains fields that are common to all log types, such as originating date and time, log identifier,
log category, severity level, and virtual domain (VDOM). The value of each field, however, is specific to the
log message. In the raw log entry example shown on this slide, the log type is UTM, the subtype is
webfilter, and the level is warning. The type and subtype of logs determine what fields appear in the log
body.

The body, therefore, describes the reason why the log was created and actions taken by FortiGate. These
fields vary by log type. In the example shown on this slide, the fields are as follows:

• The policyid field indicates which firewall rule matched the traffic
• The srcip field indicates the source IP address
• The dstip field indicates the destination IP address
• The hostname field indicates the URL or IP of the host
• The action field indicates what FortiGate did when it found a policy that matched the traffic
• The msg field indicates the reason for the action taken. In this example, the action is blocked, which
means that FortiGate prevented this IP packet from passing, and the reason is because it belonged to a
denied category in the firewall policy.

If you log to a third-party device, such as a syslog server, knowing the log structure is crucial to integration.
For information on log structures and associated meanings, visit http://docs.fortinet.com.

FortiGate Security 7.0 Study Guide 270

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Collecting logs from the devices in your Security Fabric is important. This is why two or more FortiGate
devices and a FortiAnalyzer—a remote logging device—are requisite products at the core of the Security
Fabric solution. With FortiGate, you can enable different security features, like antivirus, web filtering, intrusion
prevention (IPS), and application control, in different firewalls in the fabric. For example, in the Internal
Segmentation firewall (ISFW), you can enable only antivirus, while in the Next Generation firewall (NGFW)
facing the internet, you can enable web filtering, IPS, and application control. This means you do not have to
duplicate scans and logs of the same traffic flow when it passes through multiple firewalls.

The Security Fabric can provide a network topology view (physical and logical), and FortiGate devices can
share network-related information. For example, devices connected to downstream FortiGate devices will be
visible on the upstream device as well (you must enable device detection on the Interfaces page of the
FortiGate GUI). In short, administrators can view logs and devices connected to the network by logging on to
the root FortiGate in the Security Fabric. This information is securely shared using the FortiTelemetry
protocol.

FortiGate Security 7.0 Study Guide 271

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

It is important to remember that the more logs that get generated, the heavier the toll on your CPU, memory,
and disk resources. Storing logs for a period of time also requires disk space, as does accessing them. So,
before configuring logging, make sure it is worth the extra resources and that your system can handle the
influx.

Also important to note is logging behavior with security profiles. Security profiles can, depending on the
logging settings, create log events when a traffic matching the profile is detected. Depending on the amount of
traffic you have, and logging settings that are enabled, your traffic logs can swell and, ultimately, impact the
performance of your firewall.

From the FortiGate CLI, you can enable performance statistic logging for remote logging devices, such as
FortiAnalyzer and syslog, to occur every 1-15 minutes (0 to disable). This is not available for local disk logging
or FortiCloud.

FortiGate Security 7.0 Study Guide 272

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 273

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Good job! You now understand log basics.

Now, you will learn about local logging.

FortiGate Security 7.0 Study Guide 274

 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 local logging, you will be able to successfully store logs to local disk and
retain those logs, based on your requirements.

FortiGate Security 7.0 Study Guide 275

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Storing logs on FortiGate is known as local logging. You can store logs to the device’s hard drive.

Typically, mid to high-end FortiGates have a hard drive. Logging to a hard drive is known as disk logging.
Depending on the model series, disk logging may be enabled by default.

FortiGate can store all log types, including log archives and traffic logs, locally. Traffic logs and log archives
are larger files, and need a lot of room when being logged by FortiGate.

Under heavy log usage, any logging to FortiGate—disk—will result in a performance impact.

If you are using the local hard disk on a device for WAN optimization, you cannot also log to disk (unless your
device has two separate disks: you can use one with WAN optimization and the other for logging). If you are
using the local hard disk for WAN optimization, you can log to remote FortiAnalyzer devices or syslog servers.

FortiGate Security 7.0 Study Guide 276

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

If you want to store logs locally on FortiGate, you must enable disk logging from the Log Settings page. Only
certain FortiGate models support disk logging. If your FortiGate does not support disk logging, you can log to
an external device instead. You will learn about remote logging later in this lesson.

Disk logging must be enabled in order for information to appear on the FortiView dashboards. If disabled, logs
display in real time only. You can also enable this setting using the CLI config log disk setting
command.

By default, logs older than seven (7) days are deleted from the disk (log age is configurable).

FortiGate Security 7.0 Study Guide 277

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

If you decide to log locally on FortiGate, be aware that the entire disk space is not available to store logs. The
FortiGate system reserves approximately 25% of its disk space for system usage and unexpected quota
overflow.

To determine the amount of reserved space on your FortiGate, use the CLI command diagnose sys
logdisk usage. Subtract the total logging space from the total disk space to calculate the reserved space.

FortiGate Security 7.0 Study Guide 278

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

If storing logs locally does not fit your requirements, you can store logs externally. You can configure
FortiGate to store logs on syslog servers, FortiCloud, FortiSIEM, FortiAnalyzer, or FortiManager. These
logging devices can also be used as a backup solution.

Syslog is a logging server that is used as a central repository for networked devices.

FortiCloud is a Fortinet subscription-based, hosted security management and log retention service that offers
long-term storage of logs with reporting. If you have a smaller network, FortiCloud is usually more feasible
than buying a dedicated logging device. Note that every FortiGate offers a free tier and will keep logs for
seven days. You must upgrade to the paid service to retain logs for one year.

FortiSIEM provides unified event correlation and risk management that can collect, parse, normalize, index,
and store security logs.

FortiAnalyzer and FortiManager are external logging devices with which FortiGate can communicate. You can
place FortiAnalyzer or FortiManager in the same network as FortiGate, or outside of it. While FortiAnalyzer
and FortiManager share a common hardware and software platform and can both take log entries,
FortiAnalyzer and FortiManager actually have different capabilities that are worth noting. The primary purpose
of FortiManager is to centrally manage multiple FortiGate devices. As such, log volumes are limited to a fixed
amount per day, which are less than the equivalent size FortiAnalyzer. On the other hand, the primary
purpose of FortiAnalyzer is to store and analyze logs, so the log limit is much higher (though the limit is model
dependent). Note that local disk or logging is not required for you to configure logging to FortiAnalyzer or
FortiManager.

FortiGate Security 7.0 Study Guide 279

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

The process to configure FortiGate to send logs to FortiAnalyzer or FortiManager is identical. In order for
FortiGate to send logs to either device, you must register FortiGate with FortiAnalyzer or FortiManager. After it
is registered, FortiAnalyzer or FortiManager can begin to accept incoming logs from FortiGate.

You can configure remote logging to FortiAnalyzer or FortiManager using both the GUI and CLI.

• GUI: On the Log Settings page, enable logging to FortiAnalyzer/FortiManager, and type the IP address of
the remote logging device.
• CLI: For both FortiAnalyzer and FortiManager, use the config log fortianalyzer setting
command. Even though FortiManager isn’t explicitly mentioned in the command, it is used for
FortiManager as well. Using the CLI, up to three separate devices or one cloud FortiAnalyzer instance can
be added to increase redundancy for the protection of log data. The commands for the three devices are
not cumulative. Generating logs uses system resources, so if FortiGate frequently creates and sends logs
to multiple places, CPU and RAM usage increase.

Note that the Test Connectivity function on the GUI will report as failing until FortiGate is registered on
FortiAnalyzer or FortiManager, because it is not yet authorized to send logs.

FortiGate Security 7.0 Study Guide 280

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate allows near real-time uploading and consistent high-speed compression and analysis to
FortiAnalyzer and FortiManager.

On the GUI, upload options include Real Time, Every Minute, and Every 5 Minutes (default).

If your FortiGate model includes an internal hard drive, you also have the store-and-upload option. This
allows you to store logs to disk and then upload to FortiAnalyzer or FortiManager at a scheduled time (usually
a low bandwidth time). You can configure the store-and-upload option, as well as a schedule, on the CLI
only.

FortiGate Security 7.0 Study Guide 281

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

If FortiAnalyzer becomes unavailable to FortiGate for any reason, FortiGate uses its miglogd process to cache
the logs. There is a maximum value to the cache size, and the miglogd process will begin dropping cached
logs (oldest first) once this value is reached. When the connection between the two devices is restored, the
miglogd process begins to send the cached logs to FortiAnalyzer. Therefore, the FortiGate buffer keeps logs
long enough to sustain a reboot of your FortiAnalyzer (if you are upgrading the firmware, for example), but it is
not intended for a lengthy FortiAnalyzer outage.

On FortiGate, the CLI command diagnose test application miglogd 6 displays statistics for the
miglogd process, including the total cache size and current cache size.

The CLI command diagnose log kernel-stats will show an increase in failed-log if the cache is
full and needs to drop logs.

FortiGate devices with an SSD disk have a configurable log buffer. When the connection to FortiAnalyzer is
unreachable, FortiGate is able to buffer logs on disk if the memory log buffer is full. The logs queued on the
disk buffer can be sent successfully after the connection to FortiAnalyzer is restored.

FortiGate Security 7.0 Study Guide 282

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Similar to FortiAnalyzer and FortiManager, you can configure remote logging to FortiCloud on the Log
Settings page or the CLI. However, you must first activate your FortiCloud account, so FortiGate can
communicate with your FortiCloud account. Once complete, you can enable FortiCloud logging and set the
upload option. If you want to store your logs to disk first and then upload to FortiCloud, you must specify a
schedule. When disk usage is set to WAN optimization (wanopt), the store and upload option for logging to
FortiCloud is removed.

You can also configure remote logging to syslog and FortiSIEM on the Log Settings page or the CLI. You
can configure FortiGate to send logs to up to four syslog servers or FortiSIEM devices using the config log
syslogd CLI command.

FortiGate supports sending logs to syslog in CSV and CEF format, an open log management standard that
provides interoperability of security-related information between different network devices and applications.
CEF data can be collected and aggregated for analysis by enterprise management or Security Information
and Event Management (SIEM) systems, such as FortiSIEM. You can configure each syslog server
separately to send log messages in CEF or CSV format.

You can configure an individual syslog to use CSV and CEF format using the CLI. The example shown on this
slide is for syslogd3. All other syslog settings can be configured as required independently of the log message
format, including the server address and transport (UDP or TCP) protocol.

FortiGate Security 7.0 Study Guide 283

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

If you have a FortiGate with virtual domains (VDOMs) configured, you can globally add multiple
FortiAnalyzers and syslog servers. You can configure up to three FortiAnalyzer devices and up to four syslog
servers under global settings.

FortiGate Security 7.0 Study Guide 284

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate uses UDP port 514 (or TCP port 514, if reliable logging is enabled) for log transmission.

Log messages are stored on disk and transmitted to FortiAnalyzer as plain text in LZ4 compressed format.
This reduces disk log size and reduces log transmission time and bandwidth usage.

FortiGate Security 7.0 Study Guide 285

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

When you enable reliable logging on FortiGate, the log transport delivery method changes from UDP (User
Datagram Protocol) to TCP (Transmission Control Protocol). TCP provides reliable data transfer,
guaranteeing that the data transferred remains intact and arrives in the same order in which it was sent.

If you enable logging to FortiAnalyzer or FortiManager using the GUI, reliable logging is automatically
enabled. If you enable logging using the CLI, you must enable reliable logging using the CLI command shown
on this slide.

Logging to FortiCloud uses TCP, and you can set the encryption algorithm using the CLI (the default setting is
high).

Optionally, if using reliable logging, you can encrypt communications using SSL-encrypted OFTP traffic, so
when a log message is generated, it is safely transmitted across an unsecure network. You can encrypt
communications using SSL-secured OFTP by configuring the enc-algorithm setting on the CLI.

FortiGate Security 7.0 Study Guide 286

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 287

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Good job! You now understand remote logging.

Now, you will learn about log settings.

FortiGate Security 7.0 Study Guide 288

 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 log settings, you will be able to successfully enable logging on your
FortiGate, and ensure logs are generated on traffic caused by traffic passing through your firewall policies.

FortiGate Security 7.0 Study Guide 289

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

The Log Settings page allows you to decide if, where, and how a log is stored.

As previously discussed, you must configure whether to store logs locally on your FortiGate disk, or remotely
to an external device, such as FortiAnalyzer.

You must also configure what event logs and local traffic logs to capture. Local traffic logs provide information
about traffic directly to and from FortiGate. By default, this option is disabled because of the large number of
logs they can generate. Event logs provide all of the system information generated by FortiGate, such as
administrator logins, configuration changes made by administrators, user activity, and daily operations of the
device—they are not directly caused by traffic passing through firewall policies. For example, IPsec VPNs
closing, or routing protocol activity, are not caused by traffic passing through a firewall policy. One exception
might be the user log, because it does record user login and logout events on traffic that passes through
policies. The event logs you choose to enable depend on what features you are implementing and what
information you need to get from the logs.

The Resolve Hostnames feature resolves IP addresses to host names. This requires FortiGate to perform
reverse DNS lookups for all IP addresses. If your DNS server is not available or is slow to reply, it can impact
your ability to look through the logs, because the requests will time out.

FortiGate Security 7.0 Study Guide 290

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

While the log settings on the GUI allow you to configure what event logs and local traffic logs to capture, you
can also set more robust and granular options using the CLI.

Previously, we mentioned that you can configure up to four logging services for syslog and FortiSIEM using
the command config log syslogd setting, and up to four FortiAnalyzer or FortiManager devices using
the config log fortianalyzer setting. You can control what logs are sent to each of these devices
separately, using the command config log syslogd filter for remote syslog or FortiSIEM, and the
command config log fortianalyzer filter for FortiAnalyzer or FortiManager devices.

In this way, you can set devices to different logging levels and/or send only certain types of logs to one device
and other types (or all logs) to others. For example, you can send all logs at information level and above to
fortianalyzer, alert level and above to fortianalyzer2, and only traffic logs to fortianalyzer3.

FortiGate Security 7.0 Study Guide 291

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

After you configure all logging settings, you can enable logging on your firewall policies. Only when enabled
on a firewall policy can a log message—caused by traffic passing through that firewall policy—generate.

Generally, if you configure FortiGate to inspect traffic, you should also enable logging for that security feature
to help you track and debug your traffic flow. Except for violations that you consider to be low in severity, you’ll
want to know if FortiGate is blocking attacks. Most attacks don’t result in a security breach on the first try. A
proactive approach, when you notice a persistent attacker whose methods seem to be evolving, can avoid a
security breach. To get early warnings like this, enable logging for your security profiles.

To enable logging on traffic passing through a firewall policy, you must do the following:

1. Enable the desired security profile(s) on your firewall policy.

2. Enable Log Allowed Traffic on that firewall policy. This setting is vital. If disabled, you will not receive
logs of any kind—even if you have enabled a security profile on your firewall policy. You can choose to log
only security events, or log all sessions:
• Security Events: If enabled (along with one or more security profiles), security log events appear
in the forward traffic log and security log. A forward traffic log generates for packets causing a
security event.
• All Sessions: If enabled, a forward traffic log generates for every single session. If one or more
security profiles is also enabled, security log events appear in the forward traffic log and security
log.

FortiGate Security 7.0 Study Guide 292

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

On FortiGate, you can hide usernames in traffic logs and UTM logs, so that the username appears as
anonymous. This is useful, because some countries do not permit non-anonymized logging.

To anonymize usernames, use the set user-anonymize enable CLI command.

It is assumed that logging is enabled in firewall policies and security profiles, and that identity-based policies
are configured on FortiGate.

FortiGate Security 7.0 Study Guide 293

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

You can access your logs on the GUI in the Log & Report menu. The options that appear in this menu
depend on your configuration. Security logs appear only if security events exist.

Select the type of log you want to view, such as Forward Traffic. Logs on the GUI appear in a formatted table
view. The formatted view is easier to read than the raw view, and enables you to filter information when
viewing log messages. To view the log details, select the log in the table. The log details then appear in the
Log Details pane on the right side of the window.

If archiving is enabled on security profiles that support it (such as DLP), archived information appears within
the Log Details pane in the Archived Data section. Archived logs are also recorded when using
FortiAnalyzer or FortiCloud.

If you configure FortiGate to log to multiple locations, you can change the log display location in this section.
In the example shown on this slide, the log location is set to Disk. If logging to a syslog, you must view logs
on the syslog instead.

FortiGate Security 7.0 Study Guide 294

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Depending on your configuration, your FortiGate might record a high volume of logs. This can make it more
difficult to locate a specific log, especially during an investigation.

To navigate the logs more efficiently, you can set up log filters. The more information you specify in the filter,
the easier it is to find the precise log entry. Filters are configurable for each column of log data on the display.
Click Add Filter to select the filter from the drop-down list that appears. If you see data that you want to filter
on in a log in the table already, you can right-click that data to select the quick filter option. For example, if you
see an antivirus log in the table with a specific botnet name, right-click the botnet name in the table and a
quick filter option appears that lets you filter on all logs with that botnet name.

By default, the most common columns are shown and less common columns are hidden. Accordingly, if
filtering data based on a column that is hidden, be sure to add the column as a selected column. To add
columns, right-click any column field, and, in the pop-up menu that appears, select the column in the
Available Columns section.

If your search filters don’t return any results when the log data does exist, the filter may be poorly formed.
FortiGate looks for an exact match in the log, so you must form the search string correctly.

FortiGate Security 7.0 Study Guide 295

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

You can also access log messages generated by individual policies. Right-click the policy for which you want
to view all associated logs and, in the pop-up menu, select Show Matching Logs. FortiGate takes you to the
Forward Traffic page where a filter is automatically set based on the policy UUID.

FortiGate Security 7.0 Study Guide 296

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

You are not restricted from viewing log messages on the GUI. You can also view log messages on the CLI,
using the execute log display command. This command allows you to see specific log messages that
you already configured within the execute log filter command. The execute log filter
command configures what log messages you will see, how many log messages you can view at one time (a
maximum of 1000 lines of log messages), and the type of log messages you can view.

Logs appear in the raw format view. The raw format displays logs as they appear within the log file.

Similar to the GUI, if you have configured either a syslog or SIEM server, you will not be able to view log
messages on the CLI.

FortiGate Security 7.0 Study Guide 297

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

Because you can’t always be physically watching the logs on the device, you can monitor events by setting up
alert email. Alert emails provide an efficient and direct method of notifying an administrator of events.

Before you configure alert email, you should configure your own SMTP server on your FortiGate first. The
FortiGate has an SMTP server preconfigured, but it is recommended that you use your internal email server if
you have one.

You can configure alert emails using the CLI. You can trigger alert emails based on event (such as any time
an intrusion is detected or the web filter blocked traffic), or on minimum log severity level (such as all logs at
the Alert level or above). You can configure up to three recipients.

FortiGate Security 7.0 Study Guide 298

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

In order to prioritize solving the most relevant issues easily, you can configure severity levels for IPS
signatures, web categories, and applications that are associated with a threat weight (or score).

On the Threat Weight page, you can apply a risk value of either low, medium, high, or critical to each
category-based item. Each of these levels includes a threat weight. By default, low = 5, medium = 10, high =
30, and critical = 50. You can adjust these threat weights based on your organizational requirements.

After threat weight is configured, you can view all detected threats on the Security page. You can also search
for logs by filtering on threat score.

Note that threat weight is for informational purposes only. FortiGate will not take any action based on threat
weight.

FortiGate Security 7.0 Study Guide 299

 Logging and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate Security 7.0 Study Guide 300