Authentication protocols

When user authentication is enabled on a security policy, the authentication challenge is normally issued for any of the four protocols, HTTP, HTTPS, FTP, and Telnet, which are dependent on the connection protocol. By making selections in the Protocol Support list, the user controls which protocols support the authentication challenge. The user must connect with a supported protocol first, so that they can subsequently connect with other protocols.

For example, if you have selected HTTP, FTP, or Telnet, a username and password-based authentication occurs. The FortiGate unit then prompts network users to input their security username and password. If you have selected HTTPS, certificate-based authentication (HTTPS, or HTTP redirected to HTTPS only) occurs.

FTP and Telnet authentication replacement messages cannot be customized. For HTTP and HTTPS replacement messages see Authentication replacement messages on page 81.

For certificate-based authentication, you must install customized certificates on the FortiGate unit and on the browsers of network users. If you do not install certificates on the network user’s web browser, the network users may see an SSL certificate warning message and have to manually accept the default FortiGate certificate. The network user’s web browser may deem the default certificate as invalid.

When you use certificate authentication, if you do not specify any certificate when you create the security policy, the global settings are used. If you specify a certificate, the per-policy setting will overwrite the global setting. For more information about the use of certification authentication see Certificate-based authentication on page 110.

Authentication in captive portals

To set the authentication protocols

1. Go to User & Device > Authentication Settings.
2. In Protocol Support, select the required authentication protocols.
3. If using HTTPS protocol support, in Certificate, select a Local certificate from the drop-down list.
4. Select Apply.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Password policy

Password authentication is effective only if the password is sufficiently strong and is changed periodically. By default, the FortiGate unit requires only that passwords be at least eight characters in length, but up to 128 characters is permitted. You can set a password policy to enforce higher standards for both length and complexity of passwords. Password policies can apply to administrator passwords or IPsec VPN pre-shared keys.

To set a password policy in the web-based manager, go to System > Settings. In the CLI, use the config system password-policy command.

Users usually create passwords composed of alphabetic characters and perhaps some numbers. Password policy can require the inclusion of uppercase letters, lowercase letters, numerals or punctuation characters.

Configuring password minimum requirement policy

Best practices dictate that passwords include:

l one or more uppercase characters l one or more lower case characters l one or more of the numerals l one or more special characters.

The minimum number of each of these types of characters can be set in both the web-based manager and the CLI.

The following procedures show how to force administrator passwords to contain at least two uppercase, four lower care, two digits, and one special character. Leave the minimum length at the default of eight characters.

To change administrator password minimum requirements – web-based manager:

1. Go to System > Settings.
2. Select Enable Password Policy.
3. Select Must Contain at Least.
4. Enter the following information:

Upper Case Letters	2
Lower Case Letters	4
Numbers	2
Special Characters	1

5. Under Apply Password Policy to, select Administrator Password.
6. Select Apply.

To change administrator password minimum requirements – CLI:

config system password-policy

Password policy

set status enable set apply-to admin-password set min-upper-case-letter 2 set min-lower-case-letter 4 set min-number 2 set min-non-alphanumeric 1 set change-4-characters enable

end

The change-4-characters option forces new passwords to change a minimum of four characters in the old password. Changing fewer characters results in the new password being rejected. This option is only available in the CLI.

To configure a guest administrator password policy – CLI:

As of FortiOS 5.4, a password policy can also be created for guest administrators. The following command shows all possible commands, which are also available under config system password-policy.

config system password-policy set status {enable | disable} Enable/disable password policy. set apply-to {guest-admin-password} Guest admin to which this password policy applies. set minimum-length <8-128> Minimum password length. set min-lower-case-letter <0-128> Min. lowercase characters in password. set min-upper-case-letter <0-128> Min. uppercase characters in password. set min-non-alphanumeric <0-128> Min. non-alphanumeric characters in password. set min-number <0-128> Min. numeric characters in password.

set change-4-characters {enable | disable} Enable/disable changing at least 4 characters for new password.

set expire-status {enable | disable} Enable/disable password expiration.

set expire-day <1-999> Number of days before password expires.

set reuse-password {enable | disable} Enable/disable reuse of password. end

Password best practices

In addition to length and complexity, there are security factors that cannot be enforced in a policy. Guidelines issued to users will encourage proper password habits.

Best practices dictate that password expiration also be enabled. This forces passwords to be changed on a regular basis. You can set the interval in days. The more sensitive the information this account has access to, the shorter the password expiration interval should be. For example 180 days for guest accounts, 90 days for users, and 60 days for administrators.

Avoid:

l real words found in any language dictionary l numeric sequences, such as “12345” l sequences of adjacent keyboard characters, such as “qwerty” l adding numbers on the end of a word, such as “hello39” l adding characters to the end of the old password, such as “hello39” to “hello3900” l repeated characters l personal information, such as your name, birthday, or telephone number.

Maximum login attempts and blackout period

When you login and fail to enter the correct password you could be a valid user, or a hacker attempting to gain access. For this reason, best practices dictate to limit the number of failed attempts to login before a blackout period where you cannot login.

To set a maximum of five failed authentication attempts before the blackout, using the following CLI command:

config user setting set auth-invalid-max 5

end

To set the length of the blackout period to five minutes, or 300 seconds, once the maximum number of failed login attempts has been reached, use the following CLI command:

config user setting set auth-blackout-time 300

end

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Authentication timeout

An important feature of the security provided by authentication is that it is temporary—a user must reauthenticate after logging out. Also if a user is logged on and authenticated for an extended period of time, it is a good policy to have them re-authenticate at set periods. This ensures a user’s session is cannot be spoofed and used maliciously for extended periods of time — re-authentication will cut any spoof attempts short. Shorter timeout values are more secure.

Security authentication timeout

You set the security user authentication timeout to control how long an authenticated connection can be idle before the user must authenticate again. The maximum timeout is 4320 minutes (72 hours).

To set the security authentication timeout – web-based manager:

1. Go to User & Device > Authentication Settings.
2. Enter the Authentication Timeout value in minutes. The default authentication timeout is 5 minutes.
3. Select Apply.

SSL VPN authentication timeout

You set the SSL VPN user authentication timeout (Idle Timeout) to control how long an authenticated connection can be idle before the user must authenticate again. The maximum timeout is 259 200 seconds. The default timeout is 300 seconds.

To set the SSL VPN authentication timeout – web-based manager:

1. Go to VPN > SSL-VPN Settings.
2. Enable Idle Logout and enter the Inactive For value in seconds.

Password policy

3. Select Apply.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Managing guest access

Visitors to your premises might need user accounts on your network for the duration of their stay. If you are hosting a large event such as a conference, you might need to create many such temporary accounts. The FortiOS Guest Management feature is designed for this purpose.

A guest user account User ID can be the user’s email address, a randomly generated string, or an ID that the administrator assigns. Similarly, the password can be administrator-assigned or randomly generated.

You can create many guest accounts at once using randomly-generated User IDs and passwords. This reduces administrator workload for large events.

User’s view of guest access

1. The user receives an email, SMS message, or printout from a FortiOS administrator listing a User ID and password.
2. The user logs onto the network with the provided credentials.
3. After the expiry time, the credentials are no longer valid.

Administrator’s view of guest access

1. Create one or more guest user groups.

All members of the group have the same characteristics: type of User ID, type of password, information fields used, type and time of expiry.

2. Create guest accounts using Guest Management.
3. Use captive portal authentication and select the appropriate guest group.

Configuring guest user access

To set up guest user access, you need to create at least one guest user group and add guest user accounts. Optionally, you can create a guest management administrator whose only function is the creation of guest accounts in specific guest user groups. Otherwise, any administrator can do guest management.

Creating guest management administrators

To create a guest management administrator

1. Go to System > Administrators and create a regular administrator account. For detailed information see the System Administration
2. Select Restrict to Provision Guest Accounts.
3. In Guest Groups, add the guest groups that this administrator manages.

Creating guest user groups

The guest group configuration determines the fields that are provided when you create a guest user account.

Configuring guest user access

To create a guest user group:

1. Go to User & Device > User Groups and select Create New.
2. Enter the following information:

Name	Enter a name for the group.
Type	Guest
Enable Batch Account Creation	Create multiple accounts automatically. When this is enabled: l  User ID and Password are set to Auto-Generate. l  The user accounts have only User ID, Password, and Expiration fields. Only the Expiration field is editable. If the expiry time is a duration, such as “8 hours”, this is the time after first login. l  You can print the account information. Users do not receive email or SMS notification. See To create multiple guest user accounts automatically on page 72.
User ID	Select one of: l Email — User’s email address l Specify — Administrator assigns user ID l Auto-Generate — FortiGate unit creates a random user ID
Password	Select one of: l Specify — Administrator assigns user ID l Auto-Generate — FortiGate unit creates a random password l Disable — no password
Expire Type	Choose one of: l Immediately — expiry time is counted from creation of account l After first login — expiry time is counted from user’s first login
Default Expire Time	Set the expire time. The administrator can change this for individual users.
Enable Name	If enabled, user must provide a name.
Enable Sponsor	If enabled, user form has Sponsor field. Select Required if required.
Enable Company	If enabled, user form has Company field. Select Requiredif required.
Enable Email	If enabled, user is notified by email.
Enable SMS	If enabled, user is notified by SMS. Select whether FortiGuard Messaging Service or a another SMS provider is used.

Creating guest user accounts

Guest user accounts are not the same as local user accounts created in User & Device > User Definition. Guest accounts are not permanent; they expire after a defined time period. You create guest accounts in User & Device > Guest Management.

To create a guest user account

1. Go to User & Device > Guest Management.
2. In Guest Groups, select the guest group to manage.
3. Select Create New and fill in the fields in the New User

Fields marked Optional can be left blank. The guest group configuration determines the fields that are available.

4. Select OK.

To create multiple guest user accounts automatically

1. Go to User & Device > Guest Management.
2. In Guest Groups, select the guest group to manage.

The guest group must have the Enable Batch Guest Account Creation option enabled.

3. Select Create New > Multiple Users.

Use the down-pointing caret to the right of Create New.

4. Enter Number of Accounts.
5. Optionally, change the Expiration.
6. Select OK.

Guest management account List

Go to User & Device > Guest Management to create, view, edit or delete guest user accounts.

Create New	Creates a new guest user account.
Edit	Edit the selected guest user account.
Delete	Delete the selected guest user account.
Purge	Remove all expired accounts from the list.
Send	Send the user account information to a printer or to the guest. Depending on the group settings and user information, the information can be sent to the user by email or SMS.
Refresh	Update the list.
Guest Groups	Select the guest group to list. New accounts are added to this group.
User ID	The user ID. Depending on the guest group settings, this can be the user’s email address, an ID that the administrator specified, or a randomly-generated ID.
Expires	Indicates a duration such as “3 hours”. A duration on its own is relative to the present time. Or, the duration is listed as “after first login.”

Guest access in a retail environment

Guest access in a retail environment

Some retail businesses such as coffee shops provide free WiFi Internet access for their customers. For this type of application, the FortiOS guest management feature is not required; the WiFi access point is open and customers do not need logon credentials. However, the business might want to contact its customers later with promotional offers to encourage further patronage. Using an Email Collection portal, it is possible to collect customer email addresses for this purpose. The security policy grants network access only to users who provide a valid email address.

The first time a customer’s device attempts to use the WiFi connection, FortiOS requests an email address, which it validates. The customer’s subsequent connections go directly to the Internet without interruption.

Creating an email harvesting portal

The customer’s first contact with your network will be with a captive portal which presents a web page requesting an email address. When FortiOS has validated the email address, the customer’s device MAC address is added to the Collected Emails device group.

To create the email collection portal:

1. Go to WiFi & Switch Controller > SSID and edit your SSID.
2. Set Security Mode to Captive Portal.
3. Set Portal Type to Email Collection.
4. Optionally, in Customize Portal Messages select Email Collection.

You can change the portal content and appearance. See Customizing captive portal pages on page 105.

To create the email collection portal – CLI:

In this example the freewifi WiFi interface is modified to present an email collection captive portal.

config wireless-controller vap edit freewifi set security captive-portal set portal-type email-collect

end

Creating the security policy

You need configure a security policy that allows traffic to flow from the WiFi SSID to the Internet interface but only for members of the Collected Emails device group. This policy must be listed first. Unknown devices are not members of the Collected Emails device group, so they do not match the policy.

To create the security policy:

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information:

Incoming Interface	freewifi
Source Address	all
Source Device Type	Collected Emails
Outgoing Interface	wan1
Destination Address	all
Schedule	always
Service	ALL
Action	ACCEPT
NAT	On

3. Select OK.

To create the authentication rule – CLI:

config firewall policy edit 3 set srcintf “freewifi” set dstintf “wan1” set srcaddr “all” set action accept set devices collected-emails

set nat enable set schedule “always” set service “ALL”

end

Checking for harvested emails

In the web-based manager, go to User & Device > Device Inventory. In the CLI you can use the diagnose user device list command. For example,

FGT-100D # diagnose user device list hosts vd 0 d8:d1:cb:ab:61:0f gen 35 req 30 redir 1 last 43634s 7-11_2-int ip 10.0.2.101 ip6 fe80::dad1:cbff:feab:610f type 2 ‘iPhone’ src http c 1 gen 29 os ‘iPhone’ version ‘iOS 6.0.1’ src http id 358 c 1

email ‘yo@yourdomain.com’

vd 0 74:e1:b6:dd:69:f9 gen 36 req 20 redir 0 last 39369s 7-11_2-int ip 10.0.2.100 ip6 fe80::76e1:b6ff:fedd:69f9 type 1 ‘iPad’ src http c 1 gen 5 os ‘iPad’ version ‘iOS 6.0’ src http id 293 c 1

host ‘Joes’s-iPad’ src dhcp email ‘you@fortinet.com’

Fall-through authentication policies

User authentication policies have an implicit fall-through feature that intentionally causes policy matching to fall through to a policy lower on the list that can also match the traffic. In other words the first user policy that is matched in the policy list, based on standard policy criteria, isn’t the only policy that can be matched.

Fall-through is intended to match users in different user groups with different policies. For example, consider an organization with two user groups where one group requires a web filtering profile, while the other requires virus scanning. In this example, you would edit two basic Internet access policies: policy 1 assigning User Group A with a Web Filtering profile, and policy 2 assigning User Group B with an AntiVirus profile. Both policies are also assigned to the same internal subnet, named subnet1.

In this configuration, all users from subnet1 will see an authentication prompt. If the user is found in User Group A, the traffic is accepted by policy 1 and is filtered by the Web Filtering profile. If the user is found in User Group B, the traffic is accepted by policy 2 and is virus scanned.

The fall-through feature is required for users to be matched with policy 2. Without the fall-through feature, traffic would never be matched with policy 2.

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Users and user groups

FortiGate authentication controls system access by user group. By assigning individual users to the appropriate user groups you can control each user’s access to network resources. The members of user groups are user accounts, of which there are several types. Local users and peer users are defined on the FortiGate unit. User accounts can also be defined on remote authentication servers.

This section describes how to configure local users and peer users and then how to configure user groups.

This section contains the following topics:

l Users l User groups

Users

A user is a user account consisting of username, password, and in some cases other information, configured on the FortiGate unit or on an external authentication server. Users can access resources that require authentication only if they are members of an allowed user group. There are several different types of user accounts with slightly different methods of authentication:

User type	Authentication
Local user	The username and password must match a user account stored on the FortiGate unit. Authentication by FortiGate security policy.
Remote user	The username must match a user account stored on the FortiGate unit and the username and password must match a user account stored on the remote authentication server. FortiOS supports LDAP, RADIUS, and TACACS+ servers.
Authentication server user	A FortiGate user group can include user accounts or groups that exist on a remote authentication server.
FSSO user	With Fortinet Single Sign On (FSSO), users on a Microsoft Windows or Novell network can use their network authentication to access resources through the FortiGate unit. Access is controlled through FSSO user groups which contain Windows or Novell user groups as their members.
PKI or Peer user	A Public Key Infrastructure (PKI) or peer user is a digital certificate holder who authenticates using a client certificate. No password is required, unless two-factor authentication is enabled.
IM Users	IM users are not authenticated. The FortiGate unit can allow or block each IM user name from accessing the IM protocols. A global policy for each IM protocol governs access to these protocols by unknown users.
User type	Authentication
Guest Users	Guest user accounts are temporary. The account expires after a selected period of time.

This section includes:

l Local and remote users l PKI or peer users l Two-factor authentication l FortiToken l Monitoring users

Local and remote users

Local and remote users are defined on the FortiGate unit in User & Device > User Definition.

Create New	Creates a new user account. When you select Create New, you are automatically redirected to the User Creation Wizard.
Edit User	Modifies a user’s account settings. When you select Edit, you are automatically redirected to the Edit User page.
Delete	Removes a user from the list. Removing the user name removes the authentication configured for the user. The Delete icon is not available if the user belongs to a user group. To remove multiple local user accounts from within the list, on the User page, in each of the rows of user accounts you want removed, select the check box and then select Delete. To remove all local user accounts from the list, on the User page, select the check box in the check box column and then select Delete.
User Name	The user name. For a remote user, this username must be identical to the username on the authentication server.
Type	Local indicates a local user authenticated on the FortiGate unit. For remote users, the type of authentication server is shown: LDAP, RADIUS, or TACACS+.
Two-factor Authentication	Indicates whether two-factor authentication is configured for the user.
Ref.	Displays the number of times this object is referenced by other objects. Select the number to open the Object Usage window and view the list of referring objects. The list is grouped into expandable categories, such as Firewall Policy. Numbers of objects are shown in parentheses. To view more information about the referring object, use the icons: l  View the list page for these objects – available for object categories. Goes to the page where the object is listed. For example, if the category is User Groups, opens User Groups list. l  Edit this object – opens the object for editing. l View the details for this object – displays current settings for the object.

To create a local or remote user account – web-based manager:

1. Go to User & Device > User Definition and select Create New.
2. On the Choose User Type page select:

Local User	Select to authenticate this user using a password stored on the FortiGate unit.
Remote RADIUS User Remote TACACS+ User Remote LDAP User	To authenticate this user using a password stored on an authentication server, select the type of server and then select the server from the list. You can select only a server that has already been added to the FortiGate unit configuration.

3. Select Next and provide user authentication information. For a local user, enter the User Name and Password.

For a remote user, enter the User Name and the server name.

4. Select Next and enter Contact Information.

If email or SMS is used for two-factor authentication, provide the email address or SMS cell number at which the user will receive token password codes. If a custom SMS service is used, it must already be configured. See FortiToken on page 56.

5. Select Next, then on the Provide Extra Info page enter

Two-factor Authentication	Select to enable two-factor authentication. Then select the Token (FortiToken or FortiToken Mobile) for this user account. See Associating FortiTokens with accounts on page 60.
User Group	Select the user groups to which this user belongs.

6. Select Create.

To create a local user – CLI example:

Locally authenticated user

config user local edit user1 set type password set passwd ljt_pj2gpepfdw end

To create a remote user – CLI example:

config user local edit user2 set type ldap set ldap_server ourLDAPsrv

end

For a RADIUS or TACACS+ user, set type to radius or tacacs+, respectively.

To create a user with FortiToken Mobile two-factor authentication – CLI example:

config user local edit user5 set type password set passwd ljt_pj2gpepfdw set two_factor fortitoken set fortitoken 182937197

end

Remote users are configured for FortiToken two-factor authentication similarly.

To create a user with SMS two-factor authentication using FortiGuard messaging service – CLI example:

config user local edit user6 set type password set passwd 3ww_pjt68dw set two_factor sms set sms-server fortiguard set sms-phone 1365984521

end

Removing users

Best practices dictate that when a user account is no longer in use, it should be deleted. Removing local and remote users from FortiOS involve the same steps.

If the user account is referenced by any configuration objects, those references must be removed before the user can be deleted. See Removing references to users on page 53.

To remove a user from the FortiOS configuration – web-based manager:

1. Go to User & Device > User Definition.
2. Select the check box of the user that you want to remove.
3. Select Delete.
4. Select OK.

To remove a user from the FortiOS configuration – CLI example:

config user local delete user4444 end

Removing references to users

You cannot remove a user that belongs to a user group. Remove the user from the user group first, and then delete the user.

To remove references to a user – web-based manager

1. Go to User & Device > User Definition.
2. If the number in the far right column for the selected user contains any number other than zero, select it.
3. A more detailed list of object references to this user is displayed. Use its information to find and remove these references to allow you to delete this user.

PKI or peer users

A PKI, or peer user, is a digital certificate holder. A PKI user account on the FortiGate unit contains the information required to determine which CA certificate to use to validate the user’s certificate. Peer users can be included in firewall user groups or peer certificate groups used in IPsec VPNs. For more on certificates, see Certificates overview on page 111.

To define a peer user you need:

• a peer username
• the text from the subject field of the user’s certificate, or the name of the CA certificate used to validate the user’s certificate

Creating a peer user

The peer user can be configured only in the CLI.

To create a peer user for PKI authentication – CLI example:

config user peer edit peer1 set subject peer1@mail.example.com

set ca CA_Cert_1

end

There are other configuration settings that can be added or modified for PKI authentication. For example, you can configure the use of an LDAP server to check access rights for client certificates. For information about the detailed PKI configuration settings, see the FortiGate CLI Reference.

Two-factor authentication

The standard logon requires a username and password. This is one factor authentication—your password is one piece of information you need to know to gain access to the system.

Two factor authentication adds the requirement for another piece of information for your logon. Generally the two factors are something you know (password) and something you have (certificate, token, etc.). This makes it harder for a hacker to steal your logon information. For example if you have a FortiToken device, the hacker would need to both use it and know your password to gain entry to your account.

Two-factor authentication is available on both user and admin accounts. But before you enable two-factor authentication on an administrator account, you need to ensure you have a second administrator account configured to guarantee administrator access to the FortiGate unit if you are unable to authenticate on the main admin account for some reason.

FortiToken extension to comply with PCI 3.2

With multi-factor-authentication enabled as mandatory (see syntax below), all authentication will collect both username/password and OTP as a second factor before presenting an authentication result. The system will log for each factor.

If a user is not configured with two-factor authentication, any OTP or an empty OTP would make the second factor authentication pass.

FortiOS processes the user and password first and then always collects the second factor (if configured) without any indication of the first factor failing or succeeding. FortiOS accepts the second factor even if the first failed (unknown to the user) and returns a login attempt pass or fail, with no indication of which factor failed.

Syntax

config system global set multi-factor-authentication {optional | mandatory}

end

The methods of two-factor authentication include:

• Certificate l Email
• SMS
• FortiToken

Certificate

You can increase security by requiring both certificate and password authentication for PKI users. Certificates are installed on the user’s computer. Requiring a password also protects against unauthorized use of that computer.

Optionally peer users can enter the code from their FortiToken instead of the certificate.

To create a peer user with two-factor authentication – CLI example

config user peer edit peer1 set subject E=peer1@mail.example.com

set ca CA_Cert_1 set two-factor enable set passwd fdktguefheygfe

end

For more information on certificates, see Certificates overview on page 111.

Email

Two-factor email authentication sends a randomly generated six digit numeric code to the specified email address. Enter that code when prompted at logon. This token code is valid for 60 seconds. If you enter this code after that time, it will not be accepted.

A benefit is that you do not require mobile service to authenticate. However, a potential issue is if your email server does not deliver the email before the 60 second life of the token expires.

The code will be generated and emailed at the time of logon, so you must have email access at that time to be able to receive the code.

To configure an email provider – web-based manager:

1. Go to System > Advanced and enable Use Custom Email Server under Email Service.
2. Enter SMTP Server and Default Reply To
3. If applicable, enable Authentication and enter the SMTP User and Password to use.
4. Select a Security Mode, options are: None, SMTPS or STARTTLS.
5. Enter the Port number, the default is 25.
6. Select Apply.

To configure an email provider – CLI:

config system email-server set server <server_domain-name> set reply-to <Recipient_email_address>

end

To enable email two-factor authentication – web-based manager:

1. To modify an administrator account, go to System > Administrators. To modify a user account go to User & Device > User Definition.
2. Edit the user account.
3. Enable and enter the user’s Email Address.
4. Select Enable Two-factor Authentication.
5. Select Email based two-factor authentication.
6. Select OK.

If Email based two-factor authentication option doesn’t appear after selecting Enable Two-factor Authentication, you need to enable it via the CLI as follows.

To enable email two-factor authentication – CLI:

config user local edit <user_name> set email-to <user_email> set two-factor email end

SMS

SMS two-factor authentication sends the token code in an SMS text message to the mobile device indicated when this user attempts to logon. This token code is valid for 60 seconds. If you enter this code after that time, it will not be accepted. Enter this code when prompted at logon to be authenticated.

SMS two-factor authentication has the benefit that you do not require email service before logging on. A potential issue is if the mobile service provider does not send the SMS text message before the 60 second life of the token expires.

FortiGuard Messaging Service include four SMS Messages at no cost. If you need more, you should acquire a license through support.fortinet.com or via customer service.

If you do not use the FortiGuard Messaging Service, you need to configure an SMS service.

To configure an SMS service – CLI:

config system sms-server edit <provider_name> set mail-server <server_domain-name>

next

end

To configure SMS two-factor authentication – web-based manager:

1. To modify an:

l administrator account, go to System > Administrators, or l user account go to User & Device > User Definition.

2. Edit the user account.
3. Select SMS and enter the Country Dial Code and Phone Number.
4. Select Enable Two-factor Authentication. and select the correct Token.
5. Select OK.

If you have problems receiving the token codes via SMS messaging, contact your mobile provider to ensure you are using the correct phone number format to receive text messages and that your current mobile plan allows text messages.

FortiToken

FortiToken is a disconnected one-time password (OTP) generator. It is a small physical device with a button that when pressed displays a six digit authentication code. This code is entered with a user’s username and password as two-factor authentication. The code displayed changes every 60 seconds, and when not in use the LCD screen is blanked to extend the battery life.

There is also a mobile phone application, FortiToken Mobile, that performs much the same function.

FortiTokens have a small hole in one end. This is intended for a lanyard to be inserted so the device can be worn around the neck, or easily stored with other electronic devices. Do not put the FortiToken on a key ring as the metal ring and other metal objects can damage it. The FortiToken is an electronic device like a cell phone and must be treated with similar care.

Any time information about the FortiToken is transmitted, it is encrypted. When the FortiGate unit receives the code that matches the serial number for a particular FortiToken, it is delivered and stored encrypted. This is in keeping with the Fortinet’s commitment to keeping your network highly secured.

FortiTokens can be added to user accounts that are local, IPsec VPN, SSL VPN, and even Administrators. See Associating FortiTokens with accounts on page 60.

A FortiToken can be associated with only one account on one FortiGate unit.

If a user loses their FortiToken, it can be locked out using the FortiGate so it will not be used to falsely access the network. Later if found, that FortiToken can be unlocked on the FortiGate to allow access once again. See FortiToken maintenance on page 62.

There are three tasks to complete before FortiTokens can be used to authenticate accounts:

1. Adding FortiTokens to the FortiGate
2. Activating a FortiToken on the FortiGate
3. Associating FortiTokens with accounts

In addition, this section includes the following:

l FortiToken maintenance l FortiToken Mobile Push

The FortiToken authentication process

The steps during FortiToken two-factor authentication are as follows.

1. User attempts to access a network resource.
2. FortiGate unit matches the traffic to an authentication security policy, and FortiGate unit prompts the user for username and password.
3. User enters their username and password.
4. FortiGate unit verifies their information, and if valid prompts the user for the FortiToken code.
5. User gets the current code from their FortiToken device.
6. User enters current code at the prompt.
7. FortiGate unit verifies the FortiToken code, and if valid allows access to the network resources such as the Internet.

The following steps are needed only if the time on the FortiToken has drifted and needs to be re-synchronized with the time on the FortiGate unit.

8. If time on FortiToken has drifted, FortiGate unit will prompt user to enter a second code to confirm.
9. User gets the next code from their FortiToken device
10. User enters the second code at the prompt.
11. FortiGate unit uses both codes to update its clock to match the FortiToken and then proceeds as in step “Users and user groups” on page 49.

The FortiToken authentication process is illustrated below:

When configured the FortiGate unit accepts the username and password, authenticates them either locally or remotely, and prompts the user for the FortiToken code. The FortiGate then authenticates the FortiToken code. When FortiToken authentication is enabled, the prompt field for entering the FortiToken code is automatically added to the authentication screens.

Even when an Administrator is logging in through a serial or Telnet connection and their account is linked to a FortiToken, that Administrator will be prompted for the token’s code at each login.

Adding FortiTokens to the FortiGate

Before one or more FortiTokens can be used to authenticate logons, they must be added to the FortiGate. The import feature is used to enter many FortiToken serial numbers at one time. The serial number file must be a text file with one FortiToken serial number per line.

Both FortiToken Mobile and physical FortiTokens store their encryption seeds on the cloud, therefore you will only be able to register them to a single FortiGate or FortiAuthenticator.

Because FortiToken-200CD seed files are stored on the CD, these tokens can be registered on multiple FortiGates and/or FortiAuthenticators, but not simultaneously.

To manually add a FortiToken to the FortiGate – web-based manager:

1. Go to User & Device > FortiTokens.
2. Select Create New.
3. In Type, select Hard Token or Mobile Token.
4. Enter one or more FortiToken serial numbers (hard token) or activation codes (mobile token).
5. Select OK.

To import multiple FortiTokens to the FortiGate – web-based manager:

1. Go to User & Device > FortiTokens.
2. Select Create New.
3. In Type, select Hard Token.
4. Select Import.
5. Select Serial Number File or Seed File, depending on which file you have.
6. Browse to the local file location on your local computer.
7. Select OK.

The file is imported.

8. Select OK.

To import FortiTokens to the FortiGate from external sources – CLI:

FortiToken seed files (both physical and mobile versions) can be imported from either FTP or TFTP servers, or a USB drive, allowing seed files to be imported from an external source more easily:

execute fortitoken import ftp <file name> <ip>[:ftp port] <Enter> <user> <password> execute fortitoken import tftp <file name> <ip> execute fortitoken import usb <file name>

To add two FortiTokens to the FortiGate – CLI:

config user fortitoken edit <serial_number> next

edit <serial_number2> next

end

Activating a FortiToken on the FortiGate

Once one or more FortiTokens have been added to the FortiGate unit, they must be activated before being available to be associated with accounts. The process of activation involves the FortiGate querying FortiGuard servers about the validity of each FortiToken. The serial number and information is encrypted before it is sent for added security.

To activate a FortiToken on the FortiGate unit – web-based manager:

1. Go to User & Device > FortiTokens.
2. Select one or more FortiTokens with a status of Available.
3. Right-click the FortiToken entry and select Activate.
4. Select Refresh.

The status of selected FortiTokens will change to Activated.

The selected FortiTokens are now available for use with user and admin accounts.

To activate a FortiToken on the FortiGate unit – CLI:

config user fortitoken edit <token_serial_num> set status activate

next

end

Associating FortiTokens with accounts

The final step before using the FortiTokens to authenticate logons is associating a FortiToken with an account. The accounts can be local user or administrator accounts.

To add a FortiToken to a local user account – web-based manager:

1. Ensure that your FortiToken serial number has been added to the FortiGate successfully, and its status is Available.
2. Go to User & Device > User Definition, and edit the user account.
3. Enter the user’s Email Address.
4. Enable Two-factor Authentication.
5. Select the user’s FortiToken serial number from the Token
6. Select OK.

For mobile token, click on Send Activation Code to be sent to the email address configured previously. The user will use this code to activate his mobile token. An Email Service has to be set under System > Advanced in order to send the activation code.

To add a FortiToken to a local user account – CLI:

config user local edit <username> set type password set passwd “myPassword” set two-factor fortitoken set fortitoken <serial_number> set email-to “username@example.com”

set status enable

next

end

To add a FortiToken to an administrator account – web-based manager:

1. Ensure that your FortiToken serial number has been added to the FortiGate successfully, and its status is Available.
2. Go to System > Administrators, and edit the admin account.

This account is assumed to be configured except for two-factor authentication.

3. Enter admin’s Email Address.
4. Enable Two-factor Authentication.
5. Select the user’s FortiToken serial number from the Token
6. Select OK.

For mobile token, click on Send Activation Code to be sent to the email address configured previously. The admin will use this code to activate his mobile token. An Email Service has to be set under System > Advanced in order to send the activation code.

To add a FortiToken to an administrator account – CLI:

config system admin edit <username> set password “myPassword” set two-factor fortitoken set fortitoken <serial_number> set email-to “username@example.com”

next

end

The fortitoken keyword will not be visible until fortitoken is selected for the two-factor option.

FortiToken maintenance

Once FortiTokens are entered into the FortiGate unit, there are only two tasks to maintain them — changing the status,

To change the status of a FortiToken between activated and locked – CLI:

config user fortitoken edit <token_serial_num> set status lock

next

end

Any user attempting to login using this FortiToken will not be able to authenticate.

To list the drift on all FortiTokens configured on this FortiGate unit – CLI:

# diag fortitoken info

FORTITOKEN DRIFT STATUS

FTK2000BHV1KRZCC 0 token already activated, and seed won’t be returned

FTK2001C5YCRRVEE 0 token already activated, and seed won’t be returned

FTKMOB4B94972FBA 0 provisioned

FTKMOB4BA4BE9B84 0 new

Total activated token: 0

Total global activated token: 0

Token server status: reachable

This command lists the serial number and drift for each FortiToken configured on this FortiGate unit. This command is useful to check if it is necessary to synchronize the FortiGate and any particular FortiTokens.

FortiToken Mobile Push

A command under config system ftm-push allows you to configure the FortiToken Mobile Push services server IP address and port number. The Push service is provided by Apple (APNS) and Google (GCM) for iPhone and Android smartphones respectively. This will help to avoid tokens becoming locked after an already enabled two-factor authentication user has been disabled.

CLI syntax

config system ftm-push set server-ip <ip-address> set server-port [1-65535] Default is 4433. end

Note that the server-ip is the public IP address of the FortiGate interface that the FTM will call back to; it is the IP address used by the FortiGate for incoming FTM calls.

If an SSL VPN user authenticates with their token, then logs out and attempts to reauthenticate again within a minute, a new message will display showing “Please wait x seconds to login again.” This replaces a previous error/permission denied message.

The “x” value will depend on the calculation of how much time is left in the current time step.

CLI syntax

config system interface edit <name> set allowaccess ftm

next end

FortiGate supports when the FortiAuthenticator initiates FTM Push notifications, for when users are attempting to authenticate through a VPN and/or RADIUS (with FortiAuthenticator as the RADIUS server).

Monitoring users

To monitor user activity in the web-based manager, go to Monitor > Firewall User Monitor. The list of users who are logged on is displayed with some information about them such as their user group, security policy ID, how long they have been logged on, their IP address, traffic volume, and their authentication method as one of FSSO, NTLM, or firewall (FW-auth).

From this screen you can de-authenticate all users who are logged on. The de-authenticate button is at the top left of this screen.

To see information about banned users go to Monitor > Quarantine Monitor. Displayed information about users who have been banned includes what application the triggered the ban (Application Protocol), the reason for the ban (Cause or rule), Created, and when the ban expires.

Filtering the list of users

When there are many users logged on, it can be difficult to locate a specific user or multiple users to analyze. Applying filters to the list allows you to organize the user list to meet your needs, or only display some the users that meet your current requirements.

Select settings bottom at the top right of the screen to adjust columns that are displayed for users, including what order they are displayed in. This can be very helpful in locating information you are looking for.

Each column heading has a grey filter icon. Click on the filter icon to configure a filter for the data displayed in that column. Each column has similar options including a field to enter the filtering information, a check box to select the negative of the text in the field, and the options to add more fields, apply the filter, clear all filters, or cancel without saving. To enter multiple terms in the field, separate each of them with a comma. To filter entries that contain a specific prefix, use an * (asterisk).

For example, to create a filter to display only users with an IP address of 10.11.101.x who authenticated using one of security policies five through eight, and who belong to the user group Accounting.

1. Go to Monitor > Quarantine Monitor.
2. Enter 11.101.* and select Apply.
3. Select the filter icon beside Policy ID.
4. Enter 5-8 and select Apply.
5. Select the filter icon beside User Group.
6. Enter Accounting and select Apply.

 

Login credentials for guest users shown in clear text on GUI and voucher

In FortiOS 5.6.4, login credentials for guest users is displayed/printed in clear text on the GUI and in the voucher. It is also sent in clear text by SMS and email.

User groups

A user group is a list of user identities. An identity can be:

l a local user account (username/password stored on the FortiGate unit l a remote user account (password stored on a RADIUS, LDAP, or TACACS+ server) l a PKI user account with digital client authentication certificate stored on the FortiGate unit l a RADIUS, LDAP, or TACACS+ server, optionally specifying particular user groups on that server l a user group defined on an FSSO server.

Security policies and some types of VPN configurations allow access to specified user groups only. This restricted access enforces Role Based Access Control (RBAC) to your organization’s network and its resources. Users must be in a group and that group must be part of the security policy.

In most cases, the FortiGate unit authenticates users by requesting their username and password. The FortiGate unit checks local user accounts first. If a match is not found, the FortiGate unit checks the RADIUS, LDAP, or TACACS+ servers that belong to the user group. Authentication succeeds when a matching username and password are found. If the user belongs to multiple groups on a server, those groups will be matched as well.

There are four types of FortiGate user groups: Firewall, FSSO, Guest, and RADIUS single sign-on (RSSO) user groups.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Introduction to authentication

What is authentication?

Businesses need to authenticate people who have access to company resources. In the physical world this may be a swipe card to enter the building, or a code to enter a locked door. If a person has this swipe card or code, they have been authenticated as someone allowed in that building or room.

Authentication is the act of confirming the identity of a person or other entity. In the context of a private computer network, the identities of users or host computers must be established to ensure that only authorized parties can access the network. The FortiGate unit enables controlled network access and applies authentication to users of security policies and VPN clients.

Methods of authentication

FortiGate unit authentication is divided into three basic types: password authentication for people, certificate authentication for hosts or endpoints, and two-factor authentication for additional security beyond just passwords. An exception to this is that FortiGate units in an HA cluster and FortiManager units use password authentication.

Password authentication verifies individual user identities, but access to network resources is based on membership in user groups. For example, a security policy can be configured to permit access only to the members of one or more user groups. Any user who attempts to access the network through that policy is then authenticated through a request for their username and password.

Methods of authentication include:

l Local password authentication l Server-based password authentication l Certificate-based authentication l Two-factor authentication

Methods of authentication

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Introduction

Directed by security policies, a FortiGate screens network traffic from the IP layer up through the application layer of the TCP/IP stack. The steps involved in this inspection depend on the FortiGate hardware configuration (the presence or absence of network processors such as the NP6 and content processors such as the CP8 and CP9) and on the Unified Threat Management (UTM)/Next Generation Firewall (NGFW) inspection mode (flow-based or proxy-based) of the FortiGate or VDOM.

This chapter describes what happens to a packet as it travels through a FortiGate running FortiOS 6.0.

The FortiGate performs three types of security inspection:

• Kernel-based stateful inspection, that provides individual packet-based security within a basic session state l Flow-based inspection, that takes a snapshot of content packets and uses pattern matching to identify security threats in the content
• Proxy-based inspection, that reconstructs content passing through the FortiGate and inspects the content for security threats.

Each inspection component plays a role in the processing of a packet as it traverses the FortiGate en route to its destination.

Parallel Path Processing

Parallel Path Processing (PPP) uses the firewall policy configuration to choose from a group of parallel options to determine the optimal path for processing a packet. Most FortiOS features are applied through Firewall policies and the features applied determine the path a packet takes. Using firewall policies you can impose UTM/NGFW processing on content traffic that may contain security threats (such as HTTP, email and so on). Many UTM/NGFW processes are offloaded and accelerated by CP8 or CP9 processors. Using the policy configuration you can apply a range of protection from basic IPS attack protection that looks for network-based attacks to full scale advanced threat management (ATM), application control, antivirus, DLP and so on.

You can also create policies for traffic that does not pose security threats and bypass UTM/NGFW checking. This control allows you to improve network performance without compromising security. On FortiGates with network processors (for example the NP6) much of the traffic that does not require UTM/NGFW processing can be offloaded to the NP6 processors freeing up FortiGate processing resources for other higher risk traffic.

In addition, many FortiGate models support NTurbo to offload flow-based UTM/NGFW sessions to network processors. Flow-based sessions can also be accelerated using IPSA technology to enhance offloading of pattern matching to CP8 and CP9 content processors.

This chapter begins with an overview of packet flow ingress and egress and includes a section that shows how NP6 offloading optimizes packet flow for packets that don’t require UTM/NGFW processing and for packets that use NTurbo to offload flow-based UTM/NGFW processing.

Next this chapter breaks down how packets pass through UTM/NGFW processing both for a single-pass flowbased UTM/NGFW processing and a proxy-based UTM/NGFW processing.

 

High-level list of processes that affect packets                                                                     Parallel Path Processing

High-level list of processes that affect packets

In general packets passing through a FortiGate can be affected by the following processes. This is a complete high-level list of all of the processes. Not all packets see all of these processes. The processes a packet encounters depends on the type of packet and on the FortiGate software and hardware configuration.

 

• Ingress packet flow l Network Interface l TCP/IP stack
• DoS ACL
• DoS Policy l IP integrity header checking l IPsec VPN decryption
• Admission Control l Quarantine l FortiTelemetry l User Authentication
• Kernel l Destination NAT l Routing
• Stateful inspection/Policy

Lookup/Session management l Session Helpers l User Authentication l Device Identification

• SSL VPN
• Local Management Traffic
• UTM/NGFW
• Flow-based inspection l NTurbo l IPSA
• Proxy-based inspection l Explicit Web Proxy
• Kernel
• Forwarding l Source NAT (SNAT)
• Egress packet flow l IPsec VPN Encryption l Botnet check l Traffic shaping l WAN Optimization l TCP/IP stack l Network Interface

 

Packet flow ingress and egress: FortiGates without network processor offloading

This section describes the steps a packet goes through as it enters, passes through and exits from a FortiGate. This scenario shows all of the steps a packet goes through if a FortiGate does not contain network processors (such as the NP6).

Ingress

Ingress

All packets accepted by a FortiGate pass through a network interface and are processed by the TCP/IP stack. Then if DoS policies or Access Control List (ACL) policies have been configured the packet must pass through these as well as automatic IP integrity header checking.

DoS scans are handled very early in the life of the packet to determine whether the traffic is valid or is part of a DoS attack. The DoS module inspects all traffic flows but only tracks packets that can be used for DoS attacks (for example, TCP SYN packets), to ensure they are within the permitted parameters. Suspected DoS attacks are blocked, other packets are allowed.

IP integrity header checking reads the packet headers to verify if the packet is a valid TCP, UDP, ICMP, SCTP or GRE packet. The only verification that is done at this step to ensure that the protocol header is the correct length. If it is, the packet is allowed to carry on to the next step. If not, the packet is dropped.

Incoming IPsec packets that match configured IPsec tunnels on the FortiGate are decrypted after header checking is done.

If the packet is an IPsec packet, the IPsec engine attempts to decrypt it. If the IPsec engine can apply the correct encryption keys and decrypt the packet, the unencrypted packet is sent to the next step. Non-IPsec traffic and IPsec traffic that cannot be decrypted passes on to the next step without being affected. IPsec VPN decryption is offloaded to and accelerated by CP8 or CP9 processors.

Admission control

Admission control checks to make sure the packet is not from a source or headed to a destination on the quarantine list. If configured admission control then imposes FortiTelemetry protection that requires a device to have FortiClient installed before allowing packets from it. Admission control can also impose captive portal authentication on ingress traffic.

Kernel

Once a packet makes it through all of the ingress steps, the FortiOS kernel performs the following checks to determine what happens to the packet next.

Destination NAT

Destination NAT checks the NAT table and determines if the destination IP address for incoming traffic must be changed using DNAT. DNAT is typically applied to traffic from the internet that is going to be directed to a server on a network behind the FortiGate. DNAT means the actual address of the internal network is hidden from the internet. This step determines whether a route to the destination address actually exists. DNAT must take place before routing so that the FortiGate can route packets to the correct destination.

Packet flow ingress and egress: FortiGates without network processor offloading                                                Kernel

Routing

Routing uses the routing table to determine the interface to be used by the packet as it leaves the FortiGate. Routing also distinguishes between local traffic and forwarded traffic. Firewall policies are matched with packets depending on the source and destination interface used by the packet. The source interface is known when the packet is received and the destination interface is determined by routing.

Stateful inspection/policy lookup/session management

Stateful inspection looks at the first packet of a session and looks in the policy table to make a security decision about the entire session. Stateful inspection looks at packet TCP SYN and FIN flags to identity the start and end of a session, the source/destination IP, source/destination port and protocol. Other checks are also performed on the packet payload and sequence numbers to verify it as a valid session and that the data is not corrupted or poorly formed.

When the first packet of a session is matched in the policy table, stateful inspection adds information about the session to its session table. So when subsequent packets are received for the same session, stateful inspection can determine how to handle them by looking them up in the session table (which is more efficient than looking them up in the policy table).

Stateful inspection makes the decision to drop or allow a session and apply security features to it based on what is found in the first packet of the session. Then all subsequent packets in the same session are processed in the same way.

When the final packet in the session is processed, the session is removed from the session table. Stateful inspection also has a session idle timeout that removes sessions from the session table that have been idle for the length of the timeout.

See the Stateful Firewall Wikipedia article (https://en.wikipedia.org/wiki/Stateful_firewall) for an excellent description of stateful inspection.

Session helpers

Some protocols include information in the packet body (or payload) that must be analyzed to successfully process sessions for this protocol. For example, the SIP VoIP protocol uses TCP control packets with a standard destination port to set up SIP calls. To successfully process SIP VoIP calls, FortiOS must be able to extract information from the body of the SIP packet and use this information to allow the voice-carrying packets through the firewall.

FortiOS uses session helpers to analyze the data in the packet bodies of some protocols and adjust the firewall to allow those protocols to send packets through the firewall. FortiOS includes the following session helpers:

l PPTP l H323 l RAS l TNS l TFTP l RTSP l FTP

l MMS l PMAP l SIP l DNS-UDP l RSH l DCERPC l MGCP

UTM/NGFW

User authentication

User authentication added to security policies is handled by the stateful inspection, which is why Firewall authentication is based on IP address. Authentication takes place after policy lookup selects a policy that includes authentication.

Device identification

Device identification is applied if required by the matching policy.

SSL VPN

Local SSL VPN traffic is treated like special management traffic as determined by the SSL VPN destination port. Packets are decrypted and are routed to an SSL VPN interface. Policy lookup is then used to control how packets are forwarded to their destination outside the FortiGate. SSL encryption and decryption is offloaded to and accelerated by CP8 or CP9 processors.

Local management traffic

Local management traffic terminates at a FortiGate interface. This can be any FortiGate interface including dedicated management interfaces. In multiple VDOM mode local management traffic terminates at the management interface. In transparent mode, local management traffic terminates at the management IP address.

Local management traffic includes administrative access, some routing protocol communication, central management from FortiManager, communication with the FortiGuard network and so on. Management traffic is allowed or blocked according to the Local In Policy list which lists all management protocols and their access control settings. You configure local management access indirectly by configuring administrative access and so on.

Management traffic is processed by applications such as the web server which displays the FortiOS GUI, the SSH server for the CLI or the FortiGuard server to handle local FortiGuard database updates or FortiGuard Web Filtering URL lookups.

Local management traffic is not involved in subsequent stateful inspection steps.

SSL VPN traffic terminates at a FortiGate interface similar to local management traffic. However, SSL VPN traffic uses a different destination port number than administrative HTTPS traffic and can thus be detected and handled differently.

UTM/NGFW

If the policy matching the packet includes security profiles, then the packet is subject to Unified Threat Management (UTM)/Next Generation Firewall (NGFW) processing. UTM/NGFW processing depends on the inspection mode of the FortiGate: Flow-based (single pass architecture) or proxy-based. Proxy-based processing can include Explicit web proxy traffic. Many UTM/NGFW processes are offloaded and accelerated by CP8 or CP9 processors.

Packet flow ingress and egress: FortiGates without network processor offloading      Content processors (CP8 and CP9)

Single pass flow-based UTM/NGFW inspection identifies and blocks security threats in real time as they are identified using single-pass Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats.

Proxy-based UTM/NGFW inspection can apply both flow-based and proxy-based inspection. Packets initially encounter the IPS engine, which can apply single-pass flow-based IPS and Application Control (as configured). The packets are then sent to the proxy for proxy-based inspection. Proxy-based inspection can apply VoIP inspection, DLP, AntiSpam, Web Filtering, Antivirus, and ICAP.

Explicit web proxy inspection is similar to proxy based inspection.

Content processors (CP8 and CP9)

Most FortiGate models contain Security Processing Unit (SPU) Content Processors (CPs) that accelerate many common resource intensive security related processes. CPs work at the system level with tasks being offloaded to them as determined by the main CPU. Capabilities of the CPs vary by model. Newer FortiGate units include CP8 and CP9 processors. Older CP versions still in use in currently operating FortiGate models include the CP4, CP5, and CP6.

CP9 capabilities

The CP9 content processor provides the following services:

• Flow-based inspection (IPS, application control etc.) pattern matching acceleration with over 10Gbps throughput l IPS pre-scan l IPS signature correlation l Full match processors
• High performance VPN bulk data engine l IPsec and SSL/TLS protocol processor l DES/3DES/AES128/192/256 in accordance with FIPS46-3/FIPS81/FIPS197 l MD5/SHA-1/SHA256/384/512-96/128/192/256 with RFC1321 and FIPS180 l HMAC in accordance with RFC2104/2403/2404 and FIPS198 l ESN mode
• GCM support for NSA “Suite B” (RFC6379/RFC6460) including GCM-128/256; GMAC-128/256
• Key Exchange Processor that supports high performance IKE and RSA computation l Public key exponentiation engine with hardware CRT support l Primary checking for RSA key generation l Handshake accelerator with automatic key material generation l True Random Number generator l Elliptic Curve support for NSA “Suite B” l Sub public key engine (PKCE) to support up to 4096 bit operation directly (4k for DH and 8k for RSA with CRT)
• DLP fingerprint support l TTTD (Two-Thresholds-Two-Divisors) content chunking l Two thresholds and two divisors are configurable

Kernel

CP8 capabilities

The CP8 content processor provides the following services:

• Flow-based inspection (IPS, application control etc.) pattern matching acceleration l High performance VPN bulk data engine l IPsec and SSL/TLS protocol processor l DES/3DES/AES in accordance with FIPS46-3/FIPS81/FIPS197 l ARC4 in compliance with RC4 l MD5/SHA-1/SHA256 with RFC1321 and FIPS180 l HMAC in accordance with RFC2104/2403/2404 and FIPS198
• Key Exchange Processor support high performance IKE and RSA computation l Public key exponentiation engine with hardware CRT support l Primarily checking for RSA key generation l Handshake accelerator with automatic key material generation l Random Number generator compliance with ANSI X9.31 l Sub public key engine (PKCE) to support up to 4096 bit operation directly
• Message authentication module offers high performance cryptographic engine for calculating SHA256/SHA1/MD5 of data up to 4G bytes (used by many applications)
• PCI express Gen 2 four lanes interface l Cascade Interface for chip expansion

Kernel

Traffic is now in the process of exiting the FortiGate. The kernel uses the routing table to forward the packet out the correct exit interface.

The kernel also checks the NAT table and determines if the source IP address for outgoing traffic must be changed using SNAT. SNAT is typically applied to traffic from an internal network heading out to the internet. SNAT means the actual address of the internal network is hidden from the internet.

Egress

Before exiting the FortiGate, outgoing packets that are entering an IPsec VPN tunnel are encrypted and encapsulated. IPsec VPN encryption is offloaded to and accelerated by CP8 or CP9 processors. Packets are then subject to botnet checking to make sure they are not destined for known botnet addresses.

Traffic shaping is then imposed, if configured, followed by WAN Optimization. The packet is then processed by the TCP/IP stack and exits out the egress interface.

Packet flow: FortiGates with NP6 processors first packet of a new session

On a FortiGate with NP6 processors the first packet in a new session is handled the same way as on a FortiGate with no NP6 processors. Except that some processes, such as DoS, ACL, IP integrity checking, and IPsec VPN decryption are accelerated by the NP6 processor.

 

Network processors (NP6)                            Packet flow: FortiGates with NP6 processors first packet of a new session

Network processors (NP6)

NP6 and NP6lite network processors provide fastpath acceleration by offloading communication sessions from the FortiGate CPU. When the first packet of a new session is received by an interface connected to an NP6 processor, just like any session connecting with any FortiGate interface, the session is forwarded to the FortiGate CPU where it is matched with a security policy. If the session is accepted by a security policy and if the session can be offloaded its session key is copied to the NP6 processor that received the packet. All of the rest of the packets in the session are intercepted by the NP6 processor and fast-pathed out of the FortiGate unit to their destination without ever passing through the FortiGate CPU. The result is enhanced network performance provided by the NP6 processor plus the network processing load is removed from the CPU. In addition the NP6 processor can handle some CPU intensive tasks, like IPsec VPN encryption/decryption.

NP6lite processors have the same architecture and function in the same way as NP6 processors. All of the descriptions of NP6 processors in this document can be applied to NP6lite possessors except where noted.

Session keys (and IPsec SA keys) are stored in the memory of the NP6 processor that is connected to the interface that received the packet that started the session. All sessions are fast-pathed and accelerated, even if they exit the FortiGate unit through an interface connected to another NP6. There is no dependence on getting the right pair of interfaces since the offloading is done by the receiving NP6.

The key to making this possible is an Integrated Switch Fabric (ISF) that connects the NP6s and the FortiGate unit interfaces together. Many FortiGate units with NP6 processors also have an ISF. The ISF allows any port connectivity. All ports and NP6s can communicate with each other over the ISF. There are no special ingress and egress fast path requirements as long as traffic enters and exits on interfaces connected to the same ISF.

Some FortiGate units, such as the FortiGate-1000D include multiple NP6 processors that are not connected by an ISF. Because the ISF is not present fast path acceleration is supported only between interfaces connected to the same NP6 processor. Since the ISF introduces some latency, models with no ISF provide low-latency network acceleration between network interfaces connected to the same NP6 processor.

Each NP6 has a maximum throughput of 40 Gbps using 4 x 10 Gbps XAUI or Quad Serial Gigabit Media Independent Interface (QSGMII) interfaces or 3 x 10 Gbps and 16 x 1 Gbps XAUI or QSGMII interfaces.

There are at least two limitations to keep in mind:

• The capacity of each NP6 processor. An individual NP6 processor can support between 10 and 16 million sessions. This number is limited by the amount of memory the processor has. Once an NP6 processor hits its session limit, sessions that are over the limit are sent to the CPU. You can avoid this problem by as much as possible distributing incoming sessions evenly among the NP6 processors. To be able to do this you need to be aware of which interfaces connect to which NP6 processors and distribute incoming traffic accordingly.
• The NP6 processors in some FortiGate units employ NP direct technology that removes the ISF. The result is very low latency but no inter-processor connectivity requiring you to make sure that traffic to be offloaded enters and exits the FortiGate through interfaces connected to the same NP processor.

16

Packet flow: FortiGates with NP6 processors – packets in an offloaded session

The first packet of a session determines if the session can be offloaded. As long as there is no proxy-based UTM/NGFW, if your FortiGate includes NP6 processors, most sessions can be offloaded to them. After the first packet, subsequent packets in an offloaded session skip routing, UTM/NGFW, and kernel processors and are just forwarded out the egress interface by the NP6 processor. As well, security measures such as DoS policies, ACL, and so on are accelerated by the NP6 processor.

Packet flow: FortiGates with NP6 processors – packets in an NTurbo session

If your FortiGate supports NTurbo, many flow-based UTM/NGFW sessions can be offloaded to NP6 processors.

 

Packet flow: FortiGates with NP6 processors – packets in an NTurbo session

After the first packet, subsequent packets in an offloaded flow-based UTM/NGFW session skip routing, and kernel processors. Flow-based UTM/NGFW operations are still handled by the CPU with IPSA offloading pattern matching to CP8 or CP9 processors.

If a security threat is found the session is dropped. Otherwise, packets that are not blocked by UTM/NGFW are forwarded out of the egress interfaces by the NP6 processor.

NTurbo is not compatible with DoS policies, session helpers, or and most types of tunneling. If any of these features are present, flow-based UTM/NGFW sessions are not offloaded by NTurbo.

flow-based inspection

Flow-based UTM/NGFW inspection identifies and blocks security threats in real time as they are identified using single-pass architecture that involves Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats.

If a FortiGate or a VDOM is configured for flow-based inspection, depending on the options selected in the firewall policy that accepted the session, flow-based inspection can apply IPS, Application Control, Web Filtering, DLP, and AntiVirus. Flow-based inspection is all done by the IPS engine and as you would expect, no proxying is involved.

Before flow-based inspection can be applied the IPS engine uses a series of decoders to determine the appropriate security modules to be applied depending on the protocol of the packet and on policy settings. In addition, if SSL inspection is configured, the IPS engine also decrypts SSL packets. SSL decryption is offloaded and accelerated by CP8 or CP9 processors.

If your configuration includes SSL mirroring, the IPS engine copies decrypted application content, wraps it inside a TCP packet (with IP and ethernet headers), and sends it to the configured mirror interface. The TCP connection tuple is carried over from the original SSL connection. For the Ethernet frame, destination address is broadcast (FF:FF:FF:FF:FF:FF) and source address is all zeros.

All of the applicable flow-based security modules are applied simultaneously in one single pass, and pattern matching is offloaded and accelerated by CP8 or CP9 processors. IPS, Application Control, flow-based Web Filtering and flow-based DLP filtering happen together. Flow-based antivirus caches files during protocol decoding and submits cached files for virus scanning while the other matching is carried out.

Flow-based inspection typically requires less processing resources than proxy-based inspection and since its not a proxy, flow-based inspection does not change packets (unless a threat is found and packets are blocked). Flowbased inspection cannot apply as many features as proxy inspection (for example, flow-based inspection does not support client comforting and some aspects of replacement messages).

IPS and Application Control are only applied using flow-based inspection. Web Filtering, DLP and Antivirus can also be applied using proxy-based inspection.

UTM/NGFW packet flow: flow-based inspection

proxy-based inspection

If a FortiGate or VDOM is configured for proxy-based inspection then a mixture of flow-based and proxy-based inspection occurs. Packets initially encounter the IPS engine, which uses the same steps described in UTM/NGFW packet flow: flow-based inspection on page 20 to apply single-pass IPS and Application Control if configured in the firewall policy accepting the traffic.

The packets are then sent to the FortiOS UTM/NGFW proxy for proxy-based inspection. The proxy first determines if the traffic is SSL traffic that should be decrypted for SSL inspection. SSL traffic to be inspected is decrypted by the proxy. SSL decryption is offloaded to and accelerated by CP8 or CP9 processors.

If your configuration includes SSL mirroring, the IPS engine copies decrypted application content, wraps it inside a TCP packet (with IP and ethernet headers), and sends it to the configured mirror interface. The TCP connection tuple is carried over from the original SSL connection. For the Ethernet frame, destination address is broadcast (FF:FF:FF:FF:FF:FF) and source address is all zeros.

Proxy-based inspection extracts and caches content, such as files and web pages, from content sessions and inspects the cached content for threats. Content inspection happens in the following order: VoIP inspection, DLP, Ant-Spam, Web Filtering, AntiVirus, and ICAP.

If no threat is found the proxy relays the content to its destination. If a threat is found the proxy can block the threat and replace it with a replacement message.

Decrypted SSL traffic is sent to the IPS engine (where IPS and Application Control can be applied) before reentering the proxy where actual proxy-based inspection is applied to the decrypted SSL traffic. Once decrypted SSL traffic has been inspected it is re-encrypted and forwarded to its destination. SSL encryption is offloaded to and accelerated by CP8 or CP9 processors. If a threat is found the proxy can block the threat and replace it with a replacement message.

The proxy can also block VoIP traffic that contains threats. VoIP inspection can also look inside VoIP packets and extract port and address information and open pinholes in the firewall to allow VoIP traffic through.

ICAP intercepts HTTP and HTTPS traffic and forwards it to an ICAP server. The FortiGate is the surrogate, or “middle-man”, and carries the ICAP responses from the ICAP server to the ICAP client; the ICAP client then responds back, and the FortiGate determines the action that should be taken with these ICAP responses and requests.

UTM/NGFW packet flow: proxy-based inspection

explicit web proxy

If the explicit web proxy is enabled on a FortiGate or VDOM, a mixture of flow-based and proxy-based inspection occurs. One or more interfaces configured to listen for web browser sessions on the configured explicit web proxy port (by default 8080) accept all HTTP and HTTPS sessions on the explicit proxy port that match an explicit web proxy policy.

Plain text explicit web proxy HTTP traffic passes in parallel to both the IPS engine and the explicit web proxy for content scanning. The IPS engine applies IPS and application control content scanning. The explicit web proxy applies DLP, web filtering, and AntiVirus content scanning.

If the IPS engine and the explicit proxy do not detect any security threats, FortiOS relays the content to a destination interface. If the IPS engine or the explicit proxy detect a threat, FortiOS can block the threat and replace it with a replacement message.

Encrypted explicit web proxy HTTPS traffic passes to the explicit web proxy for decryption. Decrypted traffic once again passes in parallel to the IPS engine and the explicit web proxy for content scanning.

If the IPS engine and the explicit proxy do not detect any security threats, the explicit proxy re-encrypts the traffic and FortiOS relays the content to its destination. If the IPS engine or the explicit proxy detect a threat, FortiOS can block the threat and replace it with a replacement message. The explicit proxy offloads HTTPS decryption and encryption to CP8 or CP9 processors.

FortiOS uses routing to route explicit web proxy sessions through the FortiGate to a destination interface. Before a session leaves the exiting interface, the explicit web proxy changes the source addresses of the session packets to the IP address of the exiting interface. A FortiGate operating in transparent mode changes the source address to the transparent mode management IP address. You can also configure the explicit web proxy to keep the original client IP address.

UTM/NGFW packet flow: explicit web proxy

 

Comparison of inspection types

Security Function	Kernel (Stateful inspection)	Flow-based inspection	Proxy-based inspection
Firewall	yes
IPsec VPN	yes
Traffic Shaping	yes
User Authentication	yes
Management Traffic	yes
SSL VPN	yes
IPS		yes
Antivirus		yes	yes
Application Control		yes
Web filtering		yes	yes
DLP		yes	yes
Email Filtering			yes
VoIP inspection			yes
ICAP			yes

The tables in this section show how different security functions map to different inspection types.

Mapping security functions to inspection types

The table below lists FortiOS security functions and shows whether they are applied by the kernel, flow-based inspection or proxy-based inspection.

FortiOS security functions and inspection types

More information about inspection methods                                                               Comparison of inspection types

More information about inspection methods

The three inspection methods each have their own strengths and weaknesses. The following table looks at all three methods side-by-side.

Inspection methods comparison

Feature	Stateful	Flow	Proxy
Inspection unit per session	first packet	selected packets, single pass architecture, simultaneous application of configured inspection methods	complete content, configured inspection methods applied in order
Memory, CPU required	low	medium	high
Level of threat protection	good	better	best
Authentication	yes
IPsec and SSL VPN	yes
Antivirus protection		yes	yes
Web Filtering		yes	yes
Data Leak Protection (DLP)		yes	yes
Application control		yes
IPS		yes
Delay in traffic	minor	no	small
Reconstruct entire content		no	yes

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!