Fortigate Lab
Fortigate Lab
© FORTINET
Fortinet Training
http://www.fortinet.com/training
Fortinet Forums
https://forum.fortinet.com
Fortinet Support
https://support.fortinet.com
FortiGuard Labs
http://www.fortiguard.com
Feedback
Email: [email protected]
2/7/2018
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
In this course, you will use a virtual lab for hands-on exercises. This section explains how to connect to the lab
and its virtual machines. It also shows the topology of the virtual machines in the lab.
If your trainer asks you to use a different lab, such as devices physically located in your
classroom, then ignore this section. This section applies only to the virtual lab
accessed through the Internet. If you do not know which lab to use, please ask your
trainer.
Network Topology
Lab Environment
Fortinet's virtual lab for hands-on exercises is hosted on remote datacenters that allow each student to have their
own training lab environment or point of deliveries (PoD).
System Checker
Before starting any course, check if your computer can connect to the remote datacenters successfully. The
System Checker fully verifies if your network connection and your web browser can support a reliable connection
to the virtual lab.
You do not have to be logged in to the lab portal in order to run the System Checker.
If your computer connects successfully to the virtual lab, the Browser Check and Network Connection
Check each display a check mark icon. You can then proceed to log in.
If either of the tests fail:
l Browser Check: This affects your ability to access the virtual lab environment.
l Network Connection Check: This affects the usability of the virtual lab environment.
For solutions, click the Support Knowledge Base link, or ask your trainer.
Logging In
After you use the system checker to confirm that your system can run the labs successfully, you can proceed to
log in.
l https://virtual.mclabs.com/
2. If prompted, select the time zone for your location, and then click Update.
This ensures that your class schedule is accurate.
Your system dashboard appears, listing the virtual machines (VM) in your lab topology.
l In the System drop-down list for the VM you want to open, select Open.
A new web browser tab opens, granting you access to the virtual device. When you open a VM, your browser
uses HTML5 to connect to it.
Depending on the VM you select, the web browser provides access to either a text-based CLI or the GUI.
Connections to the Local-Windows VM use a GUI similar to a remote desktop. When you use a web-based
connection, you are logged in automatically and the Windows desktop opens.
For most lab exercises, you will connect to the Local-Windows VM.
If your computer’s connection to the VM times out or closes, to regain access, return to the window or tab that
contains the list of VMs for your session and reopen the VM.
If you store files in a cloud service such as Dropbox or SugarSync, you can use the web browser to download the
files to your Local-Windows VM.
On the VM, you can use a web browser to upload the files to the Fortinet VM GUI.
After you connect your computerto a VM, a web browser opens in a new applet window.
Screen Resolution
To configure screen resolution in the HTML5 client, open the System menu.
International Keyboards
If characters in your language don’t display correctly, keyboard mappings may not be correct.
To solve this, at the top of GUI, in the Keyboard drop-down list, select Show On-Screen Keyboard.
Your instructor can broadcast the lab systems to allow students to see ongoing tasks in real time. When an
instructor begins a broadcast, you will receive an alert at the top of all open lab pages.
To accept and view the broadcast, click the notification message or, on the left side of the window, click View
Broadcast.
If you have a question or comment, on the left side of the window, click Raise Hand. Your instructor will be
notified and will assist you.
Troubleshooting Tips
l Do not connect to the virtual lab environment through Wi-Fi, 3G, VPN tunnels, or other low-bandwidth or high-
latency connections.
l For best performance, use a stable broadband connection, such as a LAN.
l Prepare your computer's settings by disabling screen savers and changing the power saving scheme so that your
computer is always on, and does not go to sleep or hibernate.
l If the connection to any VM or the virtual lab portal closes unexpectedly, try to reconnect. If you can't reconnect,
notify the instructor.
l If you can't connect to a VM, on the dashboard, right-click the VM,, and then select System > Power Cycle, to
force the VM to start up. This fixes most problems. If itdoes not solve the problem, select System > Revert to
Initial State, to return the VM to its initial state.
Reverting to the VM's initial snapshot will undo all of your work. Try other solutions
first.
In this lab, you will learn about the FortiGate administration through the CLI and GUI. You will also back up and
restore a configuration file, as well as create a new administrator account and modify administrator access
permissions.
Objectives
l Access the FortiGate CLI.
l Back up and restore configuration files.
l Locate the FortiGate model and FortiOS firmware build in a configuration file.
l Create a new administrator user.
l Restrict administrator access.
Time to Complete
Estimated: 25 minutes
In this exercise, you will access a FortiGate device using the command line interface (CLI).
The next steps will help you get familiar with the FortiGate CLI.
This command displays basic status information about FortiGate. The output includes FortiGate's serial
number, operation mode, and so on. When the More prompt appears on the CLI, do one of the following:
To exit Q
get ?
This command shows all of the options that the CLI will accept after the # get command. Depending on the
command, you may need to enter additional words to completely specify a configuration option.
7. Try some of the control key sequences shown in the following table:
Action Command
execute ?
This command lists all options that the CLI will accept after the execute command.
10. Press the space bar and then press the Tab key three times.
Each time you press the Tab key, the CLI replaces the second word with the next possible option for the
execute command, in alphabetical order.
Use this technique to reduce the number of keystrokes that are required to enter a
command. Often, experts can configure FortiGate faster using the CLI than the GUI.
If there are other commands that start with the same characters, your abbreviation
must be long enough to be specific, so that FortiGate can distinguish them.
Otherwise, the CLI displays an error message about ambiguous commands.
11. On a fresh line, enter the following command to view the port3 interface configuration (hint: try using the shortcuts
you just learned about):
The show full-configuration command displays all the configuration settings for the interface.
The show command displays only those values that are different from the default values.
In this exercise, you will learn how to generate and restore clear-text and encrypted configuration backups. The
configuration files produced by backups, allow you to restore to an earlier FortiGate configuration.
2. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and
leave the password field empty.
You can also access the Local-FortiGate GUI from the Firefox browser bookmarks
bar.
All the lab exercises were tested running Mozilla Firefox on the Local-Windows and
Remote-Windows VMs. To get consistent results, you should use Firefox to access
both the Internet and the FortiGate GUIs in this virtual environment.
4. Click Upload to select the backup configuration file from your local PC.
5. Click Desktop > Resources > FortiGate-Security > Introduction > local-initial.conf, and then click
Open.
6. Click OK.
7. Click OK to reboot.
After your browser uploads the configuration, FortiGate reboots automatically. This takes approximately 30
to 45 seconds.
8. When the Local-FortiGate GUI login page reappears after reboot, log in as admin and leave the password field
empty.
9. Click Network > Interfaces and verify that the network interface settings were restored.
10. Click Network > Static Routes and verify that the default route was restored.
Always back up the configuration file before making changes to FortiGate (even if the change seems minor or
unimportant). There is no undo. You should carefully consider the pros and cons of an encrypted backup before
you begin encrypting backups. While your configuration, including things like private keys, remains private, an
encrypted file hampers troubleshooting because Fortinet support cannot read the file. Consider saving backups in
plain-text and storing them in a secure place instead.
Now, you will create an encrypted file with the backup of the FortiGate's current configuration.
4. Click OK.
5. Select Save File and click OK.
The Firefox browser saves the encrypted configuration file in the Downloads folder, by default.
You can access downloaded files by clicking the blue down arrow in the top right of
the browser.
Restoring from backup allows you to return to a previous configuration. As a word of caution, if you cannot recall
the password required to decrypt the backup, you will not be able to restore to this backup! Ensure that you record
the password and store it in a secure place.
Now, you will restore the configuration backup that you created in the previous procedure.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Compare the Headers of Two Configuration Files on page 26.
When troubleshooting issues, or when having to restore FortiGate to an earlier OS version or build, it is useful to
know where to find this information in a configuration file. This exercise will show you where to find the version
and build number in a configuration file.
Now, you will open and compare two configuration files using Notepad++.
2. Click File > Open and browse to the Downloads folder to open the encrypted configuration file.
3. Click File > Open and browse to the initial configuration file:
Desktop\Resources\FortiGate-Security\Introduction\local-initial.conf
In both the clear-text and encrypted configuration files, the top line acts as a header,
listing the firmware and model that this configuration belongs to.
FortiGate offers many options for configuring administrator privileges. For example, you can specify the IP
addresses that administrators are allowed to connect from.
In this exercise, you will work with administrator profiles and administrator user accounts. An administrator profile
is a role that is assigned to an administrator user that defines what the user is permitted to do on the FortiGate
GUI and CLI.
Now, you will create a new user administrator profile that has read-only access for most of the configuration
settings.
Now, you will create a new administrator account. You will assign the account to the administrator profile you
created previously. The administrator will have read-only access to most of the configuration settings.
Field Value
Password fortinet
Administrator names and passwords are case sensitive. You can't include characters
such as < > ( ) # " in an administrator account name or password. Spaces are allowed,
but not as the first or last character.
In this procedure, you will confirm that the new administrator account has read-write access to only the security
profiles configuration.
2. Log back in to the Local-FortiGate GUI with the user name Security and the password fortinet.
3. Explore the permissions that you have in the GUI.
You should see that this account can configure only security profiles.
Now, you will restrict access for FortiGate administrators. Only administrators connecting from a trusted subnet
will be allowed access. This is useful if you need to restrict the access points from which administrators connect to
FortiGate.
Now, you will verify that administrators outside the subnet 10.0.2.0/24 can't access FortiGate.
Because you are trying to connect from the 10.0.1.10 address, you shouldn't be able to connect. This is
because you restricted logins to only the source IP addresses in the list of trusted hosts.
3. On the virtual lab portal, open the Local-FortiGate VM using one of the following methods:
l Click the Local-FortiGate VM.
l In the drop-down list below the Local-FortiGate VM, click System > Open.
In this lab, you will configure firewall policies on Local-FortiGate and perform various tests on the Local-Windows
VM, to confirm that traffic is matching the desired firewall policies based on the configuration.
Objectives
l Configure firewall objects and firewall policies.
l Configure source and destination matching in firewall policies.
l Apply service and schedule objects to a firewall policy.
l Configure firewall policy logging options.
l Reorder firewall policies.
l Read and understand logs.
l Use policy lookup to find a matching policy.
Time to Complete
Estimated: 55 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to the Local-FortiGate.
In this exercise, you will configure firewall address objects. You will also configure an IPv4 firewall policy to which
you will apply firewall address objects along with schedule, services, and log options. Then, you will test the
firewall policy by passing traffic through it and checking the logs for your traffic.
At its core, FortiGate is a firewall, so almost everything that it does to your traffic is related to your firewall
policies.
By default, FortiGate has many preconfigured, well-known address objects in the factory default configuration.
However, if those objects don’t meet the needs of your organization, you can configure more.
Field Value
Name LOCAL_SUBNET
Type IP/Netmask
Interface any
5. Click OK.
First, you will disable the existing firewall policy. Then, you will create a more specific firewall policy using the
firewall address object that you created in the previous procedure. You will also select specific services and
configure log settings.
Field Value
Name Internet_Access
Source LOCAL_SUBNET
Destination all
Schedule always
Tip: On right side of the screen, type the name in the search box, and
then click Services to add.
Action ACCEPT
NAT <enable>
3. Leave all other settings at their default values and click OK to save the changes.
Now that you have configured the firewall policy, you will test it by passing traffic through it and viewing the
generated logs.
Enabling Generate Logs when Session Starts will generate twice the amount of
log messages. You should use this option only when this level of detail is absolutely
necessary.
When you click Show Matching Logs in the firewall policy, it adds the Policy UUID
filter in forward traffic logs.
6. In the Forward Traffic logs, click X to remove the Policy UUID filter.
When you remove the Policy UUID filter, the logs show unfiltered. You will use the logs in upcoming labs.
In the applicable interface pair’s section, FortiGate will look for a matching policy, beginning at the top. Usually,
you should put more specific policies at the top; otherwise, more general policies will match the traffic first, and
your more granular policies will never be applied.
In this exercise, you will create a new firewall policy with more specific settings such as source, destination,
service, and action set to DENY. Then, you will move this firewall policy above the existing firewall policies and
observe the behavior of firewall policy reordering.
You will create a new firewall policy to match a specific source, destination, service, and action set to DENY.
After you have performed these steps, see Add the Policy ID Column on page 38.
Name Block_Ping
Source LOCAL_SUBNET
Destination LINUX_ETH1
Schedule always
Service PING
Tip: Type the name in the search box on right hand side and click on
services to add.
Action DENY
The policy sequence number defines the order in which firewall policies match the traffic from top to bottom. CLI
commands use the policy ID instead of the policy sequence number. When policies are moved, the policy
sequence number changes accordingly, but the policy ID stays with the firewall policy.
2. Scroll to the bottom of the list and click Apply to save the changes.
3. Drag the ID column to where you want it positioned in the column list.
Now that your configuration is ready, you will test it by moving the Block_Ping firewall policy above the
Internet_Access firewall policy. The objective is to confirm that after reordering the firewall policy,
l traffic is matched to a more specific firewall policy
l the policy ID remains same, and
l the sequence number changes.
To confirm traffic matches a more granular firewall policy after reordering the firewall policy
1. Continuing on the Local-Windows VM, open a command prompt.
2. Ping the destination address (LINUX_ETH1) that you configured in the Block_Ping firewall policy.
ping –t 10.200.1.254
The ping should still work because it matches the ACCEPT policy and not the DENY policy that you created.
The Block_Ping policy was never checked, because the traffic matched the policy at the top (Internet_
Access). This demonstrates the behavior that FortiGate will look for a matching policy, beginning at the
top.
7. Return to the command prompt window that is running the continuous ping.
You should see that the traffic is now blocked and the replies appear as Request timed out.
This demonstrates the outcome of the policy reordering. After moving the more granular policy above the
general access policy, the traffic is matched to the more granular policy and, based on the action DENY, the
traffic stops processing.
FortiGate can match traffic by device type by selecting a device definition in the source field. There are two types
of device identification:
l Agentless device identification, which uses traffic from the device and the device is indexed by its MAC address.
l Agent-based device identification, which uses FortiClient and sends its unique FortiClient ID to FortiGate.
In this lab, you will use the agentless device identification technique. You will add the device to the source field of
the existing firewall policy and observe the firewall policy source-matching behavior.
First, you will disable the Block_Ping firewall policy so that your traffic matches the Internet_Access firewall
policy.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you have performed these steps, see Configure and Test Device Identification on page 41.
Now, you will run a continuous ping to an IP address. To test the firewall policy source matching behavior, you will
add a non-matching device, such as a Linux PC, to the source field.
ping –t 10.200.1.254
3. Return to your browser where you are logged in to the Local-FortiGate GUI, and click Policy & Objects > IPv4
Policy.
4. Right-click the Seq.# column for the Internet_Access firewall policy and click Edit.
5. Click Source and in the right pane, click Device.
6. Click Linux PC.
You are choosing a device type that doesn’t match your device (Windows).
7. Click OK.
FortiGate notifies you that this action enables device identification on the source interface.
8. Click OK.
If you enable a source device type in the firewall policy, FortiGate enables device
detection on the source interface(s) of the policy.
9. Return to the command prompt on the Local-Windows VM where you are running the continuous ping.
You should see that traffic is blocked.
10. On the Local-Windows VM, open a few browser tabs and try connecting to various external websites such as:
l kb.fortinet.com
l docs.fortinet.com
The firewall blocks this traffic.
The traffic is blocked because the source device type in the firewall policy is set to Linux-PC, which does not
match the Windows device from which the traffic is generated.
Do not close the command prompt. Keep the continuous ping running until you are
notified to stop it.
FortiGate checks from top to bottom to find a firewall policy that matches the traffic. If none of the firewall
policies match the traffic, the default implicit deny firewall policy drops the traffic.
To confirm that the traffic is dropped by the implicit deny policy, you will enable logging on the implicit firewall
policy and then check the logs.
After you have performed these steps, see Reconfigure Device Identification on page 44.
3. Right-click the Seq.# column for the Implicit Deny firewall policy and click Edit.
4. Enable Log Violation Traffic.
5. Click OK.
Now you will edit the Internet_Access firewall policy and add a Windows PC to match your Local-Windows VM.
You will see that the traffic will be allowed by this policy after you add a matching source device.
After a device is identified, FortiGate updates its list of devices and caches the list on the flash disk to speed up
detection. You can view the details of an identified device, which include device type, detection method, IP
address, and so on.
4. On the Local-Windows VM, open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
5. At the login prompt, enter the user name admin (all lower case).
6. Run the following command to view the detection method and other device details:
The identified device is cached on FortiGate and is not added to the configuration file. You will add the identified
device to the configuration file by adding an alias to the device.
Field Value
Alias MyDevice
5. Click OK.
6. Return to the Local-FortiGate PuTTY session, and run the following command to confirm that the device now
appears in the configuration file as a permanent device:
8. Return to your browser where you are logged in to the Local-FortiGate GUI, and click User & Device > Custom
Devices & Groups.
Your device is now listed under Custom Devices.
Now that you've added your device as a custom device, you will add it to the firewall policy.
FortiGate can match the traffic using address objects or ISDB objects as destinations. ISDB objects are
predefined entries that are regularly updated by FortiGuard and contains a database of IP addresses, protocols,
and port numbers used by the most common Internet services.
ISDB objects can be used to allow or deny traffic to well-known Internet destinations, without worrying about
configuring IP addresses, protocols, or ports used by those destinations in the firewall policy.
In this lab, you will apply an ISDB object as a destination criteria on a firewall policy to block traffic to a well-known
Internet service.
You will now review the entries in the Internet Service Database.
4. Click Cancel.
Now, you will now modify an existing firewall policy and use an ISDB object as a destination.
8. Click OK.
Now that you have configured the firewall policy, you will test it by passing traffic through it.
FortiGate checks for the matching policy from top to bottom. Facebook is blocked by Seq.# 3 firewall policy
because the destination is set to Facebook-Web. Twitter is allowed by Seq.# 4 firewall policy, which allows
Internet access.
2. Return to the browser where you are logged into the Local-FortiGate GUI, and right-click the Seq.# column for the
Block_Facebook firewall policy.
3. Select Policy Status, and then click Disable.
FortiGate can find a matching firewall policy based on the policy lookup input criteria. Policy lookup feature is
basically creating a packet flow over FortiGate without real traffic. From this packet flow, FortiGate can extract a
policy ID and highlight it on the GUI policy configuration page.
In this lab, you will use the policy lookup feature to find a matching firewall policy based on input criteria.
As required in the previous exercises, most of the configured firewall policies are currently disabled. Now, you will
enable some of the existing firewall policies.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you have performed these steps, see Set Up and Test the Policy Lookup Criteria on page 51.
Now, you will set up the policy lookup criteria. FortiGate will search and highlight the matching firewall policy
based on your input criteria.
Protocol TCP
Source 10.0.1.100
Destination fortinet.com
3. Click Search.
The search will match the Full_Access policy, but not the more specific firewall policy, Fortinet.
In the search criteria, the source address is set to 10.0.1.100. This source address is not a part of the
Fortinet firewall policy; therefore, the search does not match the Fortinet firewall policy.
5. Click Search.
This time, the search matches the Fortinet firewall policy, in which the destination is set to FQDN.
Now you will reorder the firewall policies. You will move the Block_Facebook firewall policy above the Full_
Access policy.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you have performed these steps, see Retest Policy Lookup After Reordering the Firewall Policies on
page 53.
Now, you will test the policy lookup feature after reordering the firewall policies.
Field Value
Protocol TCP
Source 10.0.1.10
Destination facebook.com
3. Click Search.
The search will match the Full_Access policy, but not the more specific policy, Block_Facebook,
because it is disabled.
4. Right-click the Seq.# column of the Block_Facebook policy and set the Policy Status to Enable.
5. Click Policy Lookup.
6. Click Search.
This time the search matches the more specific policy, Block_Facebook.
NAT is used to perform source NAT (SNAT) and destination NAT (DNAT) for the traffic passing through
FortiGate. There are two ways to configure source NAT and destination NAT:
You will configure and test SNAT using the central SNAT policy and DNAT using the DNAT policy and VIPs.
Objectives
l Configure destination NAT settings using a VIP.
l Configure the source NAT settings using overload IP pools.
l Configure a central NAT policy for the source NAT.
l Configure DNAT and VIPs for the destination NAT.
Time to Complete
Estimated: 50 minutes
Prerequisites
Before starting the procedures in this lab, you must restore a configuration file on each FortiGate.
Make sure to restore the correct configuration in each FortiGate using the following
steps. Failure to restore the correct configuration on each FortiGate will prevent you
from doing the lab exercise.
VIP addresses are typically used to translate external or public IP addresses to internal or private IP addresses.
In this exercise, you will configure a VIP address for the Local-Windows VM. Then, you will create an egress-to-
ingress firewall policy and apply a VIP address. This will allow Internet connections to the Local-Windows VM.
You will also verify the destination NAT (DNAT) and source NAT (SNAT) behavior using CLI commands.
Create a VIP
On FortiGate, a VIP is a destination NAT (DNAT), which you can select only in a firewall policy’s destination
address field.
In this procedure, you will configure the VIP to map the Local-Windows VM (10.0.1.10) to 10.200.1.200,
which is a part of the port1 subnet. You can refer to the lab Network Topology on page 9 diagram.
To create a VIP
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGateGUI at 10.0.1.254 as admin and
leave the password field empty.
2. Click Policy & Objects > Virtual IPs.
3. Click Create New, and then select Virtual IP.
4. Configure the following settings:
Field Value
Name VIP-INTERNAL-HOST
Interface port1
5. Click OK.
You will configure a new firewall policy using the VIP that you just created as the destination address.
Field Value
Name Web-Server-Access
Source all
Destination VIP-INTERNAL-HOST
Schedule always
Tip: In right pane, type the name in the search box, and then click
Services to add.
Action ACCEPT
4. In the Firewall / Network Options section, turn off the NAT switch.
5. In the Logging Options section, turn on the Log Allowed Traffic switch, and then select All Sessions.
Now that you've configured a firewall policy with the VIP address as the destination, you can test your VIP by
accessing it from the Remote-Windows VM, which is behind the Remote-FortiGate internal network. Traffic is
routed from the Remote-FortiGate to the Local-FortiGate by a Linux machine, which acts as a router between
these two FortiGate devices. For more information, see Network Topology on page 9.
You will also test how the source address is translated by the VIP when traffic is leaving from the Local-Windows
VM.
2. On the Local-Windows VM, open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
3. At the login prompt, enter the user name admin (all lower case).
4. Enter the following command to check the destination NAT entries in the session table:
get system session list
Sample output:
Local-FortiGate# get system session list
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
tcp 3594 10.200.3.1:49478 - 10.200.1.200:80 10.0.1.10:80
You will notice that the destination address 10.200.1.200 is translated to 10.0.1.10, which is the
mapping you configured in the VIP.
As a result of the VIP (which is a static NAT), all translated outgoing connections from the Local-Windows VM (IP
address 10.0.1.10) will use the VIP address to source NAT for the ingress-to-egress firewall policy and not the
egress interface IP address.
To test SNAT
1. Continuing on Local-Windows, return to the Local-FortiGate PuTTY session and run the following command to
clear any existing sessions:
The CLI command diagnose sys session clear will clear all sessions
including SSH session you created using PuTTY. This is expected behavior.
The firewall is stateful, so any existing sessions will not use this new firewall policy
until they time out or are cleared for ingress-to-egress traffic.
This clears the session to the Local-FortiGate from the Local-Windows VM.
Sample output:
The outgoing connections from the Local-Windows VM are now being translated with
the VIP address 10.200.1.200, instead of the firewall egress interface IP address
(10.200.1.1).
This is a behavior of the SNAT VIP. That is, when you enable SNAT on a policy, a VIP static NAT takes
priority over the destination interface IP address.
IP pools are used to translate the source address to an address from that pool, rather than the egress interface
address.
Currently, the Local-FortiGate translates the source IP address of all traffic generated from the Local-Windows
VM to 10.200.1.200 because of the SNAT translation in the VIP.
In this exercise, you will create an IP pool, apply it to the ingress-to-egress firewall policy, and verify the SNAT
address using CLI commands.
Create an IP Pool
In this procedure, you will create an IP pool from the range of public IP addresses available on the egress port
(port1).
To create an IP pool
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and
leave the password field empty.
2. Click Policy & Objects > IP Pools.
3. Click Create New and configure the following settings:
Field Value
Name INTERNAL-HOST-EXT-IP
Type Overload
4. Click OK.
Now, you will apply the IP pool to change the behavior from static NAT to dynamic NAT on the ingress-to-egress
firewall policy.
Field Value
NAT <enable>
4. Click the + that appeared when you clicked Use Dynamic IP Pool, and from the right pane, click INTERNAL-
HOST-EXT-IP.
Your configuration will look similar to the following example:
5. Click OK.
Now that your configuration is ready, you can test dynamic NAT with IP pools by browsing to a few external sites
on the Internet. If successful, you will see that the Local-Windows VM IP address (10.0.1.10) is translated to
the IP pool address of 10.200.1.100.
The CLI command diagnose sys session clear will clear all sessions
including the SSH session you created using PuTTY. This is expected behavior.
The firewall is stateful, so any existing sessions will not use this updated firewall policy
until they time out or are cleared for ingress-to-egress traffic.
Sample output:
Notice that the source NAT address is now 10.200.1.100, as configured in the IP pool, and the IP pool
has overridden the static NAT VIP.
8. Close PuTTY.
9. Close all browser tabs except the Local-FortiGate GUI.
A central SNAT policy is applied to multiple firewall policies, based on a configured central rule. The NAT on the
firewall policy controls whether the central SNAT is used or not.
In this exercise, you will configure a central SNAT policy and test it.
Prerequisites
Before beginning this lab, you must restore a configuration for central NATfile to Local-FortiGate.
Make sure to restore the correct configuration for Local-FortiGate using the following
steps. Failure to restore the correct configuration on Local-FortiGate will prevent you
from doing the lab exercise.
For example, you will see the following error if you try to enable central NAT without
removing VIP and IP pool references from the existing firewall policies.
To prevent this error from occurring during this exercise, the VIP and IP pool
references have been removed from the firewall policies.
1. The IP pool has been removed from the Full_Access firewall policy (policy ID 1),
and the VIP address has been removed from the Web-Server-Access firewall
policy (policy ID 2), because central NAT can be enabled only if none of the firewall
policies have IP pool and VIP addresses associated with them.
2. When central NAT is enabled, existing VIPs take precedence over source NAT. As
such, the VIP object you added in a previous exercise to test the firewall policy
source NAThas been removed.
In this procedure, you will test the behavior of FortiGate when a SNAT policy is not configured.
The CLI command diagnose sys session clear will clear all sessions
including the SSH session you created using PuTTY. This is expected behavior.
Sample output:
Notice that the SNAT address is now 10.200.1.1, which is the egress interface IP (port1).
If no central SNAT or matching central SNAT rule exists, FortiGate automatically uses
the outgoing interface IP address for the source NAT.
In this procedure, you will configure a central SNAT policy using the IP pool you created in the previous exercise.
Field Value
Protocol ANY
3. Keep the default values for the remaining settings and click OK to save the changes.
If NAT is enabled on the firewall policy, central SNAT is used. In this procedure, you will verify that NAT is
enabled on the firewall policy.
There is no option for IP pools. In central SNAT, NAT on the firewall policy controls
whether the central SNAT is used or not. If NAT is enabled on the firewall policy,
central SNAT is used.
Now that your configuration is ready, you can test the behavior of the central SNAT policy.
Sample output:
Notice that the source NAT address is now 10.200.1.100, which matches the central SNAT policy.
7. Close PuTTY.
8. Close all browser tabs except the Local-FortiGate GUI.
Now you will create a second IP Pool, which you will use later when creating a second central SNAT policy.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Create a Second SNAT Policy on page 72
Name SNAT-Pool
Type Overload
3. Click OK.
Now you will create a more granular SNAT policy by selecting a specific destination address and protocol to
match specific traffic.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Reorder Central SNAT Policies on page 73
Field Value
Protocol TCP
3. Click OK.
Now you will reorder the central NAT policies to put the more granular rule at the top.
Similar to firewall policies, a central SNAT policy is processed from top to bottom and, if a match is found, the
source address and source port translate based on that central SNAT policy.
Now that your configuration is ready, you will test the central SNAT configuration.
ping -t 10.200.3.1
7. Open several browser tabs and connect to a few websites. For example:
l www.fortinet.com
l www.yahoo.com
l www.bbc.com
8. Open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
9. At the login prompt, enter the user name admin (all lower case).
10. Run the following command:
Notice that the TCP sessions to destination 10.200.3.1 are translated to 10.200.1.50, because that
address matches the central SNAT policy.
Sample output:
ICMP sessions to destination 10.200.3.1 are translated to 10.200.1.100, which matches the central
SNAT policy at the bottom.
Sample output:
Also, other TCP sessions to different destinations are translated to 10.200.1.100, based on the
matching central SNAT policy at the bottom.
A Central SNAT policy is processed from top to bottom, similar to firewall policies.
In firewall policy NAT, Virtual IPs is selected in the firewall policy as the destination address. In central NAT, as
soon as DNAT & Virtual IPs is configured, FortiGate automatically creates a rule in the kernel to allow DNAT to
occur, and no additional configuration is required.
In this exercise, you will configure and test the behavior of central DNAT.
Field Value
Name Central-DNAT
Interface port1
5. Click OK.
Now, you will verify the firewall policy settings for the egress-to-ingress firewall policy.
You can't select VIPs previously created in a firewall policy as a destination address.
As soon as a VIP object is created, FortiGate automatically creates a rule in the kernel
for DNAT to occur.
5. Scroll to the bottom of the page and ensure the Enable this policy switch is turned on.
6. Click OK.
In this procedure, you will test DNAT and VIPs by accessing the Local-Windows VM.
http://10.200.1.150
Sample output:
Local-FortiGate # get system session list
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
6. Open additional web browser tabs and try to access few websites. For example:
l www.fortinet.com
l www.yahoo.com
l www.bbc.com
7. Return to the Local-FortiGate PuTTY session and verify the SNAT IP address those sessions are using:
Sample output:
Notice that the session originating from source IP, 10.0.1.10, is translated to 10.200.1.150 (VIP) as
opposed to the central SNAT policy pool IP of 10.200.1.100. This is expected behavior in central NAT.
If both the SNAT and DNAT are defined, the egress traffic will source NAT to the
DNAT/VIP address, as opposed to the configured source SNAT policy.
8. Close PuTTY.
9. Close all browser tabs except the Local-FortiGate GUI.
In this lab, you will configure FortiGate to communicate with a remote LDAP server for server-based password
authentication.
You will also configure captive portal, so that any user connecting to the network is prompted for their login
credentials (active authentication).
Objectives
l Configure server-based password authentication with an LDAP server.
l Configure captive portal so users connecting to the network are forced to authenticate.
Time to Complete
Estimated: 20 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
In this exercise, you will configure an LDAP server on FortiGate for remote authentication, create a remote
authentication group for remote users, and add that group as a source in a firewall policy.
Finally, you will authenticate over SSL-VPN as one of the remote users, and then monitor the login as the
administrator.
You can configure FortiGate to point to an LDAP server for server-based password authentication using the
preconfigured Active Directory service located on the Local-Windows VM. Active Directory already has users
available to use in this lab.
Field Value
Name ADserver
This is the attribute name used to find the user name. Active Directory
calls this cn.
This is the domain name for Active Directory on the Windows Server.
Active Directory has already been preconfigured, with all users located in
the Training organizational unit (ou).
Username ADadmin
Password Training!
This is the password pre-configured for the ADadmin user. You must use it
to be able to bind.
5. Click OK.
Now, you will assign an LDAP user group (AD-users) that includes two users (aduser1 and aduser2) to a firewall
user group called Remote-users on FortiGate. By doing this , you will be able to configure firewall policies to act
on the firewall user group.
Usually, groups are used to more effectively manage individuals who have a shared relationship.
The Remote-users firewall group is preconfigured for you. However, you must modify
it to add the users from the remote LDAP server you configured in the previous
procedure.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you have completed this exercise, see Add the Remote User Group to Your Firewall Policy on page
83.
2. To add users from the remote LDAP server, in the Remote Groups table, click Add.
The AD-users group is disabled and has a green checkmark beside it, indicating it has been added.
5. Click OK.
The users in this Active Directory group are now included in your FortiGate Remote-users firewall user
group. Only users from the remote LDAP server that match this user group entry can authenticate.
6. Click OK.
Now that the LDAP server is added to the Remote-users firewall user group, you can add the group to a firewall
policy. This allows you to control access to network resources, because policy decisions are made for the group as
a whole.
Because a remote user on your LDAP server will authenticate over SSL-VPN, you will add the group to an SSL-
VPN firewall policy.
Configuring SSL-VPN is out of scope for this lab, so the SSL-VPN settings are
preconfigured. However, you still need to configure an SSL-VPN firewall policy and
add the Remote-user group to it.
Field Value
Name SSL-VPN
Source LOCAL_SUBNET
Schedule always
Service ALL
Action ACCEPT
3. In the Security Profiles section, enable Web Filter, and then select Category_Monitor.
This web filter was preconfigured and is set to block the following categories: Potentially Liable, Adult/Mature
Content, and partially blocking Security Risk.
4. In the Logging Options section, enable Log Allowed Traffic, and then select All Sessions.
5. Click OK.
diagnose test authserver ldap <LDAP server name> <LDAP user name> <password>
Where:
4. Close PuTTY.
Now, you will authenticate through the preconfigured SSL VPN as aduser1. This user is a member of the
Remote_users group on FortiGate. Then, you will monitor the authentication.
If you receive an error that indicates your connection is not secure, click Advanced, and then select Add
Exception.
2. Clear the Permanently store this exception check box and click Confirm Security Exception.
6. Return to your browser tab with the SSL-VPN portal and click Quick Connection again. This time, in the URL
field, type elite-hackers.com and then click Launch.
This URL is set to be blocked by the Web Filter security profile you enabled in the SSL VPN firewall policy.
7. Remain logged in to the SSL VPN portal and continue to the next procedure.
If you do not see a Web Filter menu item, refresh your browser tab.
4. Return to the browser tab where you are logged in to the SSL VPN portal and log out.
5. Return to the browser tab with the Local-FortiGate GUI, and go to Monitor > SSL-VPN Monitor.
The user no longer appears in the SSL-VPN monitor because the connection is no longer active. However,
FortiView > VPN retains the login information.
In this exercise, you will configure captive portal and restrict access to a specific user group. Captive portal is a
convenient way to authenticate web users on wired or Wi-Fi networks using an HTML form that requests a user
name and password (active authentication).
This exercise involves creating a user group (and adding a user to it), enabling captive portal and restricting
access based on that group, and enabling the disclaimer message.
Finally, you will authenticate through captive portal and monitor the authentication.
Because the goal is to enable captive portal based on a specific group, you must first create a user group and
then add a user to the group. For the purposes of this exercise, you will add the user student to the group.
Student is a local user on FortiGate that was preconfigured.
Field Value
Name CP-group
Type Firewall
Members student
4. Click OK.
2. In the Admission Control section, enable captive portal using the following settings:
3. Click OK.
To provide a disclaimer message to users who are logging in through captive portal, you must enable disclaimers.
Because you are enabling captive portal through a wired interface, you can enable disclaimers only using the CLI.
If you enable captive portal using Wi-Fi, you can enable disclaimers using the GUI
(WiFi & Switch Controller > SSID ). You are using a wired interface in this lab.
4. Close PuTTY.
Now that captive portal is configured and the disclaimer is enabled, you can test the configuration by
authenticating through captive portal as the student user. Then, you will monitor the authentication as the
admin user.
4. Open additional browser tabs and access a few more websites through captive portal, for example:
While the CLI config user setting dictates how long a user authenticating
through captive portal can remain authenticated, you can choose to manually revoke a
captive portal user's authentication by selecting the user in the Firewall User
Monitor list and clicking De-authenticate. Once deauthenticated, the user
disappears from the list, because it is reserved for active users only.
3. Select student and click De-authenticate to manually end the user's session.
4. Click OK.
5. Close the browser.
In this lab, you will configure log settings on Local-FortiGate, configure alert email, and view logs.
Objectives
l Configure logging on FortiGate so FortiGate understands how to log traffic.
l Configure threat weight.
l Monitor logs through alert emails.
l View logs on the Local-FortiGate GUI.
Time to Complete
Estimated: 35 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate. After the reboot, you must also
check your web filter license status, because you will be using web filtering in this lab and it must show as
licensed.
3. If there is a grey ? icon next to Web Filtering, indicating the license status is unavailable, complete the following:
a. Click System > FortiGuard.
b. Scroll to the bottom of the page, and then, next to Filtering Services Availability, click Check Again to
force an update.
c. Click OK to confirm.
You should see a confirmation message indicating that the web filtering service is available.
To record network activity, you must configure logging on FortiGate. In this exercise, you will configure the log
settings.
Configuring log settings does not generate logs directly on FortiGate. Rather, log settings define if, where, and
how a log is stored.
The objective of this exercise is to prepare the log settings on Local-FortiGate. For the purposes of this lab, this
includes:
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Configure Threat Weight on page 96.
Field Value
Disk <enable>
4. In the Log Settings section, make sure the following settings are configured:
Field Value
Event logs provide all of the system information generated by the FortiGate
device (they are not caused by traffic passing through firewall policies).
However, it is good practice to track and monitor events that occur on
FortiGate.
These logs record traffic directly to and from FortiGate and can fill up your disk
quickly if not properly managed and monitored. For the purposes of this lab,
leave all local traffic log options disabled.
Field Value
6. Click Apply.
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). Threat weight allows you to set
the risk values for low, medium, high, and critical levels, and then apply a threat weight to specific categories.
The objective of this task is to set the following categories to critical status:
l Malicious Websites
l Hacking
l Explicit Violence
l Pornography
You will use threat weight later when searching for logs at a specific threat weight.
3. In the Risk Level Values section, record the value associated with the Critical risk level.
You will use this information later to search for logs using the risk level value as a filter.
Critical
4. Click Apply.
Now that you've defined if, where, and how a log is stored using the FortiGate log settings, you must define
whether logs are generated. To accomplish this, you must enable logging on your firewall policy. A log message
can generate only when logging is enabled on a firewall policy.
For the purposes of this lab, two firewall policies have been created for you. However, you will now need to
configure these firewall polices for logging.
l IPS: You will use this firewall policy to capture IPS traffic.
l Full Access: You will use this firewall policy to capture antivirus, web filter, DNS, and application control traffic.
IPS
l IPS | high_security
Full Access
l AntiVirus | default
l Web Filter | Category-block-and-warning
l DNS Filter | default
l Application Control | block-high-risk
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Monitoring Logs Through Alert Email on page 101.
IPS high_security
3. In the Logging Options section, enable Log Allowed Traffic, and then select All Sessions.
Remember, you will not get logs of any kind if Log Allowed Traffic is not enabled.
4. Click OK.
You've successfully enabled logging on your firewall policy. Later in this lab, you will test these log settings.
AntiVirus default
3. In the Logging Options section, enable Log Allowed Traffic, and then select All Sessions.
Remember, you will not get logs of any kind if Log Allowed Traffic is not enabled.
4. Click OK.
You've successfully enabled logging on your firewall policy. Later in this lab, you will test these log settings.
In this exercise, you will configure alert emails, run some traffic through the Local-FortiGate, and view alert
emails.
Because you can’t always be physically at the FortiGate device, you can monitor events by setting up alert
emails. Alert emails provide an efficient and direct method of notifying an administrator of events.
An SMTP mail server is required for alert email to operate. Because configuring a mail
server is out of scope for this lab, it has been preconfigured for you. You can view the
email service configuration on the Local-FortiGate GUI by clicking System >
Advanced.
Field Value
From [email protected]
Interval 1
Generate Traffic
For the purposes of this lab, you must generate traffic so you can see the logs collected by FortiGate.
The traffic you generate will go through Local-FortiGate. You have already enabled
the security policy on the IPS firewall policy and enabled logging for all sessions.
You will use two different tools to create different types of traffic.
In this lab, you will direct FIT-generated traffic through the Local-FortiGate. The FIT is behind port3 on the Local-
FortiGate. The traffic from FIT will go through the Full Access firewall policy. For more information, see
Network Topology on page 9.
You configured the Full Access firewall policy to include the following security policies and logging options:
Because FIT-generated traffic will originate from the IP of the FIT VM (10.0.1.20),
all these logs will show the same source IP in the logs. This is a limitation of the lab
environment. In a real-world scenario, you will likely see many different source IPs for
your traffic.
cd FIT
Traffic begins to generate and repeats the script each time it completes.
4. Leave the PuTTY session open (you can minimize it) so traffic continues to generate.
This will run throughout the remainder of this lab.
Do not close the FIT PuTTY session or traffic will stop generating.
You will direct the Nikto-generated traffic through Local-FortiGate. Nitko is running on the Linux VM, and the
traffic will go through the egress to ingress firewall policy named IPS. For more information, see Network
Topology on page 9.
You configured the IPS firewall policy to include the following security policy and logging options:
The scan will continue for approximately 25 minutes. The dialog displays an End Time and indication that 1
host is tested when complete.
You can run the command again after the scan completes (press the up arrow and then press Enter) to
generate more logs, but it's not required. One cycle will provide enough logs for the purposes of this lab.
4. Leave the PuTTY session open (you can minimize it) so traffic continues to generate.
This will run for the remainder of the lab.
Do not close the LINUX PuTTY session or traffic will stop generating.
Now that traffic is being sent through your FortiGate, you can check the [email protected] email to see if any
alerts have been generated based on that traffic. You configured the alert email to generate an alert every one
minute any time an intrusion is detected by the IPS security profile on the IPS firewall policy, and any time the
web filter security profile blocks traffic on the Full Access firewall policy.
The log message that accompanies an alert provides more details about the traffic that caused the alert.
2. Select the inbox of the [email protected] email account and click Get Messages.
You should see a message in the admin inbox with a subject of "Message meets Alert condition". If no email
appears in the inbox, wait 30 seconds, and then click Get Messages again.
4. Open another alert email and record the following information from a single web filter log:
Field Value
date
time
logid
subtype
level
sessionid
profile
catdesc
crscore
You will locate this log on the Local-FortiGate GUI in the next exercise.
5. Select the email of the log you recorded by clicking the star icon to the left of the email subject.
The star icon turns yellow.
If you would like to review more alert emails, click Get Messages in your admin inbox
again. You configured your alert email to send messages that meet the alert condition
every one minute.
In this exercise, you will view logs using both the Log & Report and FortiView menus of the Local-FortiGate
GUI. You will also configure filter options to locate specific logs.
In this exercise, you will examine the logs on the Local-FortiGate GUI, based on the traffic you generated from
the FIT VM and Nikto.
Forward Traffic
The first place you will examine logs is on the Forward Traffic page.
All security profile-related logs are tracked within the forward traffic logs, so you can search all forward traffic in
one place. This is helpful if you are looking to see all activity from a particular address, security feature, or traffic.
Security profile logs are still tracked separately in the GUI, but only appear when logs exist.
This filters on all Web activity greater than or equal to the Critical (50) risk
level.
If the information on which you are filtering does not appear in the table, you may
need to add the related column to the table. To do so, right-click any column in the
table and select the column you want to add. For example, to view the Threat Score
column, add Threat Score. At the bottom of the list, click Apply to refresh the table
with the new column.
5. View both the Details and Security tabs to see what information is available.
If this menu item does not display, you can refresh the page, or log out of the Local-
FortiGate GUI and log in again.
2. Locate the log in the alert email that you recorded in To view your alert emails on page 105 by using log filters.
3. After you locate the log, double-click the entry to view the log details.
As you can see, the log details in the alert email are the same as the log details on the GUI. The only
difference is the format. Alert emails provide the log detail information in raw format, while the GUI provides
the log detail information in a formatted format.
l View the GUI page that shows intrusion prevention logs only.
l Filter for a log with the attack name Web.Server.Password.Files.Access.
l View information about the attack on FortiGuard.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see View Logs in FortiView on page 111.
This takes you to the FortiGuard website, where you can gather more information about the specific attack,
such as the description of the attack, affected products, impact, and recommended actions.
FortiView is a comprehensive monitoring system for your network that integrates real-time and historical data into
a single view on your FortiGate.
2. Use the search settings to display the Web activity in a different way. For example:
l Select Categories and 1 hour to see the Web categories most accessed in the last hour.
Close both the FIT and LINUX PuTTY sessions to stop log generation.
In this lab, you will configure SSL deep inspection using a self-signed SSL certificate on FortiGate to inspect
outbound traffic. You will also import a web server certificate on FortiGate and configure inbound SSL inspection.
Objectives
l Configure and enable SSL deep inspection on outbound traffic.
l Import an external web server certificate.
l Configure and enable SSL deep inspection on inbound traffic.
Time to Complete
Estimated: 40 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file on each FortiGate.
Make sure to restore the correct configuration on each FortiGate using the following
steps. Failure to restore the correct configuration on each FortiGate will prevent you
from doing the lab exercise.
SSL deep inspection on outbound traffic allows FortiGate to inspect encrypted Internet-bound traffic, and apply
security profiles to that traffic to protect your network and end users. FortiGate employs a man-in-the-middle
(MITM) attack to inspect the traffic and apply security profiles such as antivirus, web filter, and application
control.
In this exercise, you will configure and enable SSL inspection on all outbound traffic.
By default, FortiGate includes two security profiles for SSL/SSH inspection: certificate-inspection and deep-
inspection, which you cannot modify. Because this exercise involves configuring FortiGate for SSL full
inspection, you will configure a new SSL/SSH inspection profile for full SSL inspection.
You must enable SSL inspection on a firewall policy to start inspecting traffic. However, you cannot enable
SSL inspection by itself. The firewall policy must have one or more other security profiles enabled, because
enabling SSL inspection tells FortiGate only how to handle encrypted traffic—you still need to tell FortiGate
which traffic to inspect. For the purposes of this lab, you will enable the default web filter security profile.
4. In the Logging Options section, enable Log Allowed Traffic, and select All Sessions.
5. Click OK.
FortiGate includes an SSL certificate called Fortinet_CA_SSL that you can use for full SSL inspection. It is signed
by a certificate authority (CA) called FortiGate CA, which is not public. Because the CA is not public, your browser
will display a certificate warning each time a user connects to an HTTPS site. This is because the browser is
receiving certificates signed by FortiGate, which is a CA it does not know and trust. You can avoid this warning by
downloading the Fortinet_CA_SSL certificate and installing it on all the workstations as a public authority.
In this procedure, you will first test access to an HTTPS site without the Fortinet_CA_SSL certificate installed.
Then, you will install the Fortinet_CA_SSL certificate and test again.
https://salesforce.com
2. Click Advanced.
Notice the certificate warning. This appears because the browser is receiving certificates signed by the
FortiGate CA's private key, and the corresponding CA certificate is not in the Local-Windows certificate store.
3. Leave the browser tab open and continue to the next procedure. Do not add the exception.
4. In Firefox, in the upper-right corner of the window, click the Open menu icon, and then click Options.
7. In the Certificate Manager window, click the Authorities tab, and then click Import.
Now that you have added the Fortinet_CA_SSL certificate to your browser, you will not receive any certificate
warnings when accessing a secure site.
The CA that signed this certificate is not public, but the browser is aware of it because you added it as a trusted
authority in the previous exercise.
https://salesforce.com
This time you are passed through to the site without any certificate warnings.
You can use SSL deep inspection on inbound traffic to protect internal resources, such as web servers, that users
can access on the Internet. Implementing inbound SSL deep inspection allows you to apply antivirus, IPS, and
web application firewall (WAF) on encrypted traffic destined for your web servers, to protect them from malicious
files and traffic.
In this exercise, you will import an external web server certificate to Local-FortiGate, and then configure SSL
deep inspection to protect a web server with an antivirus profile.
First, you will configure a virtual IP to map an external IP address to the web server's internal IP address. Then,
you will configure a firewall policy to allow access to the virtual IP.
After you complete the challenge, see Install the Training CA Certificate on page 121.
To configure a virtual IP
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and
leave the password field empty.
2. Click Policy & Objects > Virtual IPs.
3. Click Create New, and select Virtual IP.
4. Configure the following settings:
Field Value
Name VIP-WEB-SERVER
Interface port1
5. Click OK.
Field Value
Name Web_Server_Access
Source all
Destination VIP-WEB-SERVER
Schedule always
Service ALL
Action ACCEPT
NAT <disable>
3. Click OK.
Now, you will verify access to the web server URL, and then install the Training CA certificate on Firefox to
eliminate certificate errors.
After you complete the challenge, see Configure Inbound SSL Deep Inspection on page 126.
To verify access
1. On the virtual lab portal, click the Remote-Windows VM.
2. Open Firefox and access the web server using https://10.200.1.200.
A security warning opens.
7. Click Close.
8. Click Cancel.
5. Click Desktop > Resources > FortiGate-Security > Certificate-Operations > Training.crt, and then click
Open.
The Downloading Certificate window opens.
7. Click OK.
8. Click OK.
9. Restart Firefox.
10. Go to https://10.200.1.200, and then verify that the security warning is no longer displayed.
On Local-FortiGate, you will configure and enable SSL deep inspection on all inbound traffic destined to the web
server using the default certificate. You will also observe the changes to the end-user browser session on
Remote-Windows. Then, you will import the external web server certificate on Local-FortiGate, and use it to
perform SSL deep inspection to eliminate security errors.
Field Value
Name Inbound_SSL_Inspection
4. Click OK.
5. Click Policy & Objects > IPv4 Policy.
6. Edit the Web_Server_Access policy.
7. In the Security Profiles section, enable the following security profiles:
AntiVirus default
8. Click OK.
7. Click Close.
8. Click Cancel.
The webserver.p12 file contains the web server's certificate and private key.
In this lab, you will configure one of the most used security profiles on FortiGate: web filter. This includes
configuring a FortiGuard category-based filter, applying the web filter profile on a firewall policy, testing your
configuration, and basic troubleshooting.
You will also apply overrides to FortiGuard website categories and perform overrides on the web filtering profile.
The web filtering overrides allow you to execute different actions, rather than the configured actions on the web
filter security profile.
Objectives
l Configure web filtering on FortiGate.
l Apply the FortiGuard category-based option for web filtering.
l Troubleshoot the web filter.
l Read and interpret web filter log entries.
l Configure web rating overrides.
l Configure web profile overrides.
Time to Complete
Estimated: 25 minutes
Prerequisites
Before beginning this lab, you must clear your web browser history and restore a configuration file to the Local-
FortiGate.
2. Click History > Clear Recent History, and ensure the time range to clear is set to Everything.
3. Click Clear Now.
To configure FortiGate for web filtering based on FortiGuard categories, you must make sure that FortiGate has
a valid FortiGuard security subscription license. The license provides the web filtering capabilities necessary to
protect against inappropriate websites.
Then, you must configure a category-based web filter security profile on FortiGate and apply the security profile
on a firewall policy to inspect the HTTP traffic.
Finally, you can test different actions taken by FortiGate according to the website rating.
You will review the inspection mode and the license status according to the uploaded settings. You will also list
the FortiGuard distribution servers (FDS) that your FortiGate will use to send the web filtering requests.
Because of the reboot following the restoration of the configuration file, the web filter
license status may show "Unavailable". In this case, navigate to System >
FortiGuard, click Check Again to force an update, and OK to confirm.
4. Open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
5. At the login prompt, enter the user name admin (all lower case).
6. Enter the following commands to change from Flow-based to Proxy inspection mode.
7. Return to your browser where you are logged into the Local-FortiGate GUI and refresh the browser. (Alternatively,
you can log out of the Local-FortiGate GUI and log back in.)
8. Click System > Settings to verify that the Inspection Mode is now set to Proxy.
In order to configure web filter categories, you must first identify how specific websites are categorized by the
FortiGuard service.
2. Use the Web Filter Lookup tool and search for the following URL:
This is one of the websites you will use later to test your web filter.
As you can see, YouTube is listed in the Steaming Media and Download category.
3. Use the Web Filter Lookup tool again to find the web filter category for the following websites:
l http://www.skype.com/
l http://www.ask.com/
l http://www.bing.com/
You will test your web filter using these websites as well.
This table shows the category assigned to each URL, as well as the action you will configure your FortiGate
to take based on your web filter security profile:
You will review the default web filtering profile and configure the FortiGuard category-based filter.
Category Action
Unrated Block
The Edit Filter dialog box opens, allowing you to modify the warning interval.
Now that you have configured the web filter profile, you must apply this security profile to a firewall policy in order
to start inspecting web traffic.
You will also enable the logs to store and analyze the security events generated by the web traffic.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Test the Web Filter on page 136.
For the purposes of this lab, you will test the web filter security profile you configured for each category.
The get webfilter status and diagnose debug rating commands show the list of FortiGuard
FDS that your FortiGate uses to send web filtering requests. In normal operations, FortiGate sends the rating
requests only to the server at the top of the list. Each server is probed for round-trip time (RTT) every two
minutes.
Your lab environment uses a FortiManager at 10.0.1.241, which has been configured as a local
FDS server. It contains a local copy of the FDS web rating database.
FortiGate sends the rating requests to FortiManager instead of the public FDS servers. For this
reason, the output of the above command lists only the FortiManager IP address.
l
Field Value
URL www.bing.com
3. Click OK.
You will test the web rating override you created in the previous procedure. To confirm that FortiGate is taking the
local override, you will enable the real-time debug for the web filtering process.
4. Open a new browser tab, and try again to access the website www.bing.com.
The website is blocked.
The diagnostic output indicates that the URL matches a local rating instead of a FortiGuard rating.
So, http://www.bing.com/ is blocked, because you have overridden its category rating.
5. In your PuTTY session, press Enter a few times to get a fresh comman line and type the following command to
stop the real-time debug:
In this exercise, you will configure and test the authenticate action for web filtering categories.
First, you will override the category for www.bing.com to Proxy Avoidance. Then, you will set the action for this
FortiGuard category to Authenticate.
3. Double-click www.bing.com to verify the rating override and confirm the category and subcategory:
Field Value
4. Click Cancel.
Field Value
4. Click OK.
5. Click Apply.
To create a user
1. Continuing on the Local-FortiGate GUI, click User & Device > User Definition.
2. Click Create New.
3. Select Local User as the User Type.
4. Click Next, and then configure the following settings:
Field Value
Password fortinet
5. Click Next.
6. Click Next.
In this section, you will test access to a website using the authenticate action, and then analyze the logs made by
the security events.
2. Click Proceed.
You might receive a certificate warning at this stage. This is normal and is a direct
result of using a self-signed certificate. Accept the warning message to proceed with
the remainder of the procedure (click Advanced, click Add Exception, and then click
Confirm Security Exception).
Field Value
Username student
Password fortinet
The Web Filter logs section won't display if there are no web filtering logs. FortiGate
displays the section after creating logs. If the Web Filter menu does not appear in the
GUI, refresh your browser or log out of the Local-FortiGate GUI and log back in.
According to the logs, http://www.bing.com was initially blocked, but after clicking Proceed and
authenticating, the logs show a different action: passthrough.
Remember, http://www.bing.com is rated by FortiGuard as belonging to the Search Engines and Portals
category, where the action, by default, is set to Allow.
However, for this website, you changed the category to Security Risk.
As you have tested the web rating overrides, you will now test web profile overrides.
The web profile overrides feature changes the rules applied to inspected traffic. It authorizes some users, user
groups, or predefined source IPs, to use a different web filter profile.
In this procedure, you will allow users to override blocked categories. Those users must authenticate in order to
apply a different web filter profile.
Field Value
Switch applies to IP
Finally, you will test the global access for a blocked category, and authenticate to apply a new web filter profile.
You will also review the web filter logs to verify how actions change after the new web profile is applied.
2. Click Override.
You might receive a certificate warning at this stage. This is normal and is a direct
result of using a self-signed certificate. Accept the warning message to proceed with
the remainder of the procedure (click Advanced, click Add Exception, and then click
Confirm Security Exception).
Field Value
Username student
Password fortinet
FortiGate overrides the default profile and allows you to access the website.
3. Select a blocked entry and in the upper-right corner of the screen, click Details.
4. Now, select a passthrough entry and click Details.
Notice that the web profile used is different.
In this lab, you will configure and use the application control, in both profile-based and policy-based modes, to
apply an appropriate action to specified application traffic. You will view logs and monitor from FortiView. You will
also use the application control feature, along with traffic shaping, to alter the bandwidth that is available to an
application.
Objectives
l Configure an application control profile.
l Read and understand application control logs and monitor applications from FortiView.
l Configure and monitor traffic shaping for applications.
l Configure and test application control in NGFW policy-mode.
Time to Complete
Estimated: 35 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
In this exercise, you will create a profile-based application control profile in flow-based inspection mode. Flow-
based and proxy-based inspection modes share identical configuration steps for application control. The
FortiGate matches the traffic in this order:
1. Application overrides
2. Filter overrides
3. Categories
You will also view the application control logs and applications from FortiView to confirm that the applications are
logged correctly.
The configuration file for this exercise already has the application control categories set to monitor (except
Unknown Applications). This allows the applications to pass, but also records a log message.
In this exercise, you will configure filter overrides. The filter overrides will take precedence over application
categories.
4. Under the Filter Overrides section, click Add Filter to add a filter override.
5. On the Add Filter Overrides page, click Add Filter.
6. Click Behavior, and then click Excessive-Bandwidth.
8. Click Apply.
Now that you have configured the application control profile, you will apply it to the firewall policy.
After you complete the challenge, see Test the Application Control Profile on page 150.
Now that your configuration is complete, you will test the application control profile by going to the application
that you blocked in the application overrides configuration.
2. Return to the browser tab where you are logged in to the Local-FortiGate GUI, and click Security Profiles >
Application Control.
3. Edit the default application sensor again.
4. In the Options section at the bottom of the page, enable Replacement Messages for HTTP-based
Applications.
5. Click Apply.
6. Open a new web browser tab and go to the following URL: http://dailymotion.com.
FortiGate should display a block message.
In this exercise, you will configure application overrides. The application overrides will take precedence over filter
overrides and application categories.
After you complete the challenge, see Test Application Overrides on page 152.
This application control profile is already applied to a firewall policy that is scanning all
outbound traffic. You do not need to reapply the application control profile for the
changes to take affect.
Now that your configuration is complete, you will test the application control profile by going to the application
that you allowed.
View Logs
Now you will view the logs for the test you just performed.
To view logs
1. Return to your browser tab where you are logged in to the Local-FortiGate GUI, and click Log & Report >
Application Control.
The Application Control logs section will not display if there are no application
control logs. FortiGate will show it after creating logs. If the Application Control
menu item does not display in the GUI, refresh the browser or log out of the Local-
FortiGate GUI and log in again.
2. Use the Application Name log filter and search for Dailymotion.
You will see log messages with the action set to block.
4. Click Log & Report > Forward Traffic and search and view the log information for Dailymotion.
You will see more details about the log, including translated IP, bytes sent, bytes received, action, and
application.
FortiGate will not log information for application control events that have the action set to Allow. FortiGate
will only log application control events for applications with the action set to Monitor or Block. Applications
with the action set to Pass will be logged only in the Forward Traffic section and only if the firewall policy
is set to log All Sessions instead of just Security Events.
You can limit the bandwidth consumption of an application category, or of a specific application, by configuring a
traffic shaping policy. You must ensure that the matching criteria aligns with the firewall policy or policies to which
you want to apply shaping.
In this exercise, you will configure and apply traffic shaping to an application, to limit its bandwidth consumption.
You will be modifying the application override for the Dailymotion application to change the action from Allow
to Monitor. Then, you will apply traffic shaping in the next procedure.
5. Click Apply.
For the purposes of this lab, setting the action to Monitor ensures all application
control events are logged.
You will be configuring a traffic shaping policy using the preconfigured traffic shaper to limit the bandwidth use of
Dailymotion.
l Create a traffic shaping policy for the Dailymotion application only from port1.
l Apply DAILYMOTION_Shaper as Reverse Shaper.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Test Traffic Shaping on page 156.
3. Click Policy & Objects > Traffic Shaping Policy, and then click Create New.
4. Configure the following settings:
Field Value
Source all
Destination all
Service ALL
Application Dailymotion
Tip: Type Dailymotion in the search box in the right pane to locate it
easily.
5. Click OK.
You must ensure that the matching criteria aligns with the firewall policy or
policies to which you want to apply traffic shaping.
Now that your configuration is complete, you will test traffic shaping by playing a video on Dailymotion.
http://dailymotion.com
3. Return to your browser tab where you are logged in to the Local-FortiGate GUI, and click Policy & Objects >
Traffic Shapers.
4. Review the Bandwidth Utilization and Dropped Bytes columns for the DAILYMOTION_SHAPER .
You might need to refresh the FortiGate GUI to view the statistics on Traffic Shapers.
You will notice the bandwidth used by the Dailymotion application and FortiGate is dropping the packets
that are in excess of the configured bandwidth in the traffic shaper.
Monitor statistics are current as of the time that you requested the GUI page, so make
sure to view them while a video is downloading. Also, refresh the page few times to
get the results.
5. Click Log & Report > Forward Traffic and review the logs to display basic information regarding theTraffic
Shaper policy.
Add the Shaping Policy ID column tn the table so the page displays the traffic
shaper policy ID for the traffic.
In NGFW policy-based mode, application control is applied directly on a firewall policy, without the use of an
application control profile.
In this exercise, you will configure application control on a FortiGate operating in NGFW policy-based mode.
You will be configuring a new firewall policy and applying application control on the policy.
Field Value
Name Social_Media_Block
Source all
Destination all
Service ALL
Application Social.Media
Tip: From the right pane, click Application Category and then search
for Social.Media.
Action DENY
6. Click OK.
7. From the Seq.# column, drag the Social_Media_Block firewall policy above the ALLOW_ALL firewall policy.
Your firewall policy order should look like this:
When applying application control, you should have a policy that allows all
applications. Otherwise, you allow only specific applications and all other applications
(including web browsers) will be blocked.
Now that your configuration is complete, you will test application control by going to the application that you have
configured.
2. Try to visit websites that fall under application categories other than social media, such as http://dailymotion.com.
The pages load.
3. Return to your browser tab where you are logged in to the Local-FortiGate GUI, and click Log & Report >
Application Control.
The Application Control logs section will not display if there are no application
control logs. FortiGate will show the section after creating logs. If the Application
Control menu item does not display in the GUI, refresh your browser or log out of the
Local-FortiGate GUI and log back in.
Lab 9: Antivirus
In this lab, you will configure, use, and monitor antivirus scanning on Local-FortiGate in both flow-based and
proxy-based inspection modes.
Objectives
l Configure antivirus scanning in both flow-based and proxy inspection modes.
l Understand FortiGate antivirus scanning behavior.
l Scan multiple protocols.
l Read and understand antivirus logs.
Time to Complete
Estimated: 20 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
l Quick scan uses a compact antivirus database and performs faster scanning because it doesn’t buffer the file in
memory.
l Full scan uses the full antivirus database. It buffers the file locally, but transmits it simultaneously to the end client.
Everything is transmitted except the last packet. The last packet is delayed, and the whole file is sent to the
antivirus engine for scanning.
In this exercise, you will use antivirus in flow-based inspection mode to understand how FortiGate performs
antivirus scanning. You will use full-scan mode with and without deep inspection. You will observe the behavior of
antivirus scanning, with and without deep inspection, to understand the importance of performing full-content
inspection.
By default, the FortiGate inspection mode is set to flow-based, so all the security profiles will also be set to flow-
based inspection mode. In this procedure, you will verify the antivirus profile settings, and apply the antivirus
profile to a firewall policy.
Now that you've verified that the inspection mode is set to flow-based, you will review the antivirus profile to view
the settings.
Because the inspection mode is set to flow-based, by default, all the security profiles
will be set to flow-based as well.
Now that you have reviewed the antivirus profile, you must enable the antivirus profile on your firewall policy.
After you enable the antivirus profile on a firewall policy, it can scan for viruses and generate logs (based on
configured log settings).
l Edit the Full_Access firewall policy and enable the default antivirus profile.
l Use certificate-inspection profile for SSL inspection.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Test the Antivirus Configuration on page 165.
5. Keep the default values for the remaining settings, and then click OK to save the changes.
In this procedure, you will download the EICAR test file to your Local-Windows VM. The EICAR test file is an
industry-standard virus used to test antivirus detection without causing damage. The file contains the following
characters:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
http://eicar.org
2. In the upper-right corner of the EICAR webpage, click DOWNLOAD ANTI MALWARE TESTFILE.
3. Click the Download link on the left.
4. In the Download area using the standard protocol http section, download any EICAR sample file.
FortiGate should block the download attempt and insert a replacement message similar to the following
example:
FortiGate shows the HTTP virus message when it blocks or quarantines infected files.
In this section, you will test the flow-based antivirus configuration using the Save Link As method to download
the EICAR text file.
http://eicar.org
2. On the EICAR website, in the upper-right corner of the page, click DOWNLOAD ANTI MALWARE TESTFILE.
3. Click the Download link on the left.
4. In the Download area using the standard protocol http section, right-click eicar.com.txt and select Save
Link As.
6. On your desktop, right-click the eicar.com downloaded file, and click Edit with Notepad++ to open the file
you downloaded.
Is the content of the file what it's supposed to be?
When the last packet arrives, FortiGate buffers it and puts it on hold. Then, it sends the whole buffered file
to the IPS engine where rule match is checked and passed to the antivirus engine for scanning. If the
antivirus scan does not detect any viruses, and the result comes back clean, the last buffered packet is
regenerated and delivered to the client.
However, if a virus is found, the last packet is dropped. Even if the client has received most of the file, the
file will be truncated and the client will be not able to open a truncated file. FortiGate injects the block
message into the partially download file. The client can use Notepad to open and view the file.
The purpose of logs is to help you monitor your network traffic, locate problems, establish baselines, and make
adjustments to network security, if necessary.
3. Select theSecurity tab to view security logs, which provide information more specific to security events, such as
file name, virus or botnet, and reference.
4. To view antivirus security logs, click Log & Report > AntiVirus.
The AntiVirus section won't display if there are no antivirus logs. FortiGate displays
the AntiVirus section after creating logs. If the AntiVirus menu item does not
display in the GUI, refresh your browser or log out of the FortiGate GUI and log back in
again.
8. Click Close.
The Advanced Threat Protection Statistics widget provides statistics about the number of files submitted
and the results of those scans.
So far, you have tested unencrypted traffic for antivirus scanning. In order for FortiGate to inspect the encrypted
traffic, you must enable deep inspection on the firewall policy. After you enable this feature, FortiGate will filter
for traffic that is using the SSL encrypted protocol, which is very similar to a man-in-the-middle (MITM) attack.
To test antivirus scanning without SSL Inspection enabled on the firewall policy
1. Continuing on the Local-Windows VM, open a web browser and go to the following website:
http://eicar.org
FortiGate should not block the file, because you have not enabled full SSL inspection.
FortiGate should block the download and replace it with a message. If it doesn't, you may need to clear your
cache. In Firefox, click History > Clear Recent History > Everything.
In proxy-based inspection mode, each protocol's proxy buffers the entire file (or waits for oversize limit) and scans
it. The client must wait for the scan to finish.
In this exercise, you will configure antivirus scanning in proxy-based inspection mode, including associated
security features, such as proxy options with deep-inspection. Then, you will apply antivirus scanning to the
firewall policy. Finally, you will view the logs and summary information for the antivirus activity.
By default, flow-based inspection mode is enabled on FortiGate. You will change the inspection mode from flow-
based to proxy-based.
Changing from one inspection mode to another will result in the conversion of profiles
and removal or addition of security features, based on the selected mode.
Now that you've changed the inspection mode to proxy-based, you will view the antivirus profile to see the
changes.
If you do not see the mode set to NAT in the system information widget, please
refresh your browser.
2. Click Security Profiles > AntiVirus, and select the default antivirus profile.
3. Verify that Detect Viruses is set to Block and, in the Inspected Protocols section, make sure the FTP switch is
turned on.
This profile defines the behavior for virus scanning on the traffic that matches policies using that profile.
Now that the antivirus profile is configured, you must enable the antivirus profile on the firewall policy. After you
enable the antivirus profile on a firewall policy, it can scan for viruses and generate logs (based on configured log
settings).
When selecting an antivirus profile, Proxy Options and SSL/SSH Inspection are
automatically enabled. You can't disable Proxy Options or SSL/SSH Inspection,
but you can select any preconfigured profiles in the Proxy Options and SSL/SSH
Inspection drop-down menus.
4. Beside the Proxy Options profile, click the pencil icon to view the profile on the firewall policy tab.
This profile specifies how FortiGate’s proxies pick up protocols. For example, The FTP listening port is set to
port 21.
Now, you will test the proxy-based antivirus profile using FTP file transfer.
3. On the Remote site side of the application (right), right-click the eicar.com file, and then select Download.
The client should display an error message that the server aborted the connection. FortiGate sends the
replacement message as a server response.
In proxy-based inspection mode, FortiGate buffers the file to scan the content before
sending the file or a replacement message to the client.
Now, you will check and confirm the logs for the test you just performed.
The Details tab shows forward traffic log information along with the action taken.
In this lab, you will set up IPS profiles and denial of service (DoS) policies. You will also use a vulnerability
scanner and a custom script to generate attacks on Local-FortiGate.
Objectives
l Protect your network against known attacks using IPS signatures.
l Use rate based signatures to block brute force attacks.
l Mitigate and block DoS attacks.
Time to Complete
Estimated: 40 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
First, you will configure an IPS sensor that includes the signatures for known attacks on Windows operating
systems.
To configure IPS
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and
leave the password field empty.
2. Click Security Profiles > Intrusion Prevention.
3. In the upper-right corner, click the plus (+) icon to create a new sensor.
4. In the Name field, type WEBSERVER for the new sensor name.
5. In the IPS Filters section, click Add Filter.
All the signatures matching the filter are added to the IPS sensor.
8. Click OK.
9. Right-click the filter you created, and then click Monitor.
FortiGate will create an intrusion prevention log entry for each detected attack, without blocking it.
You will apply the new IPS sensor to a firewall policy that allows external access to the web server running on
Local-Windows.
l Configure a new virtual IP to map the external IP 10.200.1.200 to the internal IP 10.0.1.10, using
port1 as the external interface. Name the virtual IP VIP-WEB-SERVER.
l Create a new firewall policy to allow all inbound traffic to the virtual IP and enable the WEBSERVER
IPS sensor. Name the firewall policy Web_Server_Access_IPS.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Generate Attacks from the Linux Server on page 180
To create a virtual IP
1. Continuing on the Local-Fortigate GUI, click Policy & Objects > Virtual IPs.
2. Click Create New > Virtual IP.
3. Configure the following settings:
Field Value
Name VIP-WEB-SERVER
Interface port1
4. Click OK.
Field Value
Name Web_Server_Access_IPS
Source all
Destination VIP-WEB-SERVER
Schedule always
Service ALL
Action ACCEPT
NAT disabled
3. In the Security Profiles section, enable IPS, and from the drop-down list, select WEBSERVER .
The policy should look like the following example:
Configuring full SSL inspection would significantly increase the time required to
complete this lab. Therefore, for the purposes of this exercise, you will not configure
full SSL inspection.
4. Click OK.
You will run a Perl script to generate attacks from the Linux server located in front of the Local-FortiGate.
4. Leave the PuTTY session open (you can minimize it) so traffic continues to generate.
Do not close the LINUX PuTTY session or traffic will stop generating.
You will check the IPS logs to monitor for known attacks being detected by Local-FortiGate.
After you complete the challenge, see Tune the IPS Sensor on page 182.
3. Locate the relevant log entries for the following signatures using the log filter:
l Apache.Expect.Header.XSS
l LaVague.PrintBar.PHP.File.Inclusion
5. Review the FortiGuard encyclopedia pages for both signatures and record the affected products for each signature
in the table below:
Apache.Expect.Header.XSS
LaVague.PrintBar.PHP.File.Inclusion
You will modify the IPS sensor you created to block most of the attacks, and create individual rules that have
different actions for the two signatures you noted in the previous procedure.
l On Local-FortiGate, in the WEBSERVER IPS sensor, change the IPSFilter rule to Block
l Add the following individual IPS rules:
l LaVague.PrintBar.PHP.File.Inclusion | Action: Pass
l Apache.Expect.Header.XSS action | Action: Monitor
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Verify the IPS Sensor Tuning on page 184.
You will generate another attack from the Linux VM. This time, FortiGate should block most of the attacks.
2. Wait approximately 10 minutes for the script to run all the attacks. If, after 10 minutes, the script has not finished
running, press Ctrl+C to stop it.
l Verify that the WEBSERVER IPS sensor is now blocking attacks generated by the script.
l Locate the new log entry for the Apache.Expect.Header.XSS signature.
l Identify why there aren't any new logs for the LaVague.PrintBar.PHP.File.Inclusion signature
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
5. Use the log filter and search for any new logs for the LaVague.PrintBar.PHP.File.Inclusion signature.
Because the signature action is set to Pass, FortiGate won't generate any new logs for it.
In this exercise you will configure a rate based signature to detect and block a brute force FTP attack.
You will create a new IPS sensor, then enable and configure the appropriate signature to detect and block
FTP brute-force attacks. You will then apply the IPS sensor to all outbound traffic on Local-FortiGate.
Field Value
Threshold 5
Track By Source IP
Action Reset
7. Click OK.
You will use a custom Windows batch script to generate invalid login attempts to the FTP server located on the
Linux VM. You will then verify your configuration using the IPS logs.
You may need to remove any log filters you previously set.
Why are there only six log entries, when the script generated 10 login attempts?
Note that for Attempt 4, the server response is 530 Login incorrect. However, for Attempt 5, the
error message is Connection closed by remote host. This is where the rate based signature's
action triggers, and the FTP client's connections are reset. This Connection closed by remote
host message repeats until the script ends with Attempt 10.
In this exercise, you will configure the Local-FortiGate for DoS protection.
You will create a DoS policy to detect and block an icmp flood attack
After you complete the challenge, see Test the DoS Policy on page 190.
Field Value
Services ALL
7. Click OK.
You will generate an ICMP flood from the Linux VM. This will trigger the DoS policy on Local-FortiGate.
The command option -f causes the ping utility to run continuously, and not wait for
replies between ICMP echo requests. It also requires super-user privilege.
4. Enter password.
For every ping sent, the SSH session will display a period.
5. Leave the SSH connection open with the ping running (you can minimize the window).
The Anomaly logs section will not display if there are no anomaly logs. If the
Anomaly menu item does not display in the GUI, refresh the browser or log out from
the Local-FortiGate GUI and log back in again.
4. Go back to the PuTTY window and press Ctrl+C to stop the ping.
5. Close the PuTTY session.
In this lab, you will configure an SSL-VPN connection in tunnel and web modes. You will also manage user groups
and portals for an SSL-VPN.
Objectives
l Configure and connect to an SSL-VPN.
l Enable authentication security.
l Configure a firewall policy for SSL-VPN users to access private network resources.
l Customize the SSL-VPN portal for web mode.
l Configure FortiClient for the SSL-VPN connection in tunnel mode.
Time to Complete
Estimated: 25 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
On FortiGate, there are two modes you can configure to allow remote access through SSL-VPN: web mode and
tunnel.
In this exercise, you will test web mode, which will allow SSL-VPN users to connect from the Remote-Windows
VM, to resources located in the local subnet (10.0.1.0/24).
Now, you will configure the SSL-VPN settings to allow the remote connection shown in the following example:
Username student
Password fortinet
The group SSL_VPN_USERS has been preconfigured for the purpose of this lab.
To review the settings of this group, click User & Device > User Groups.
Field Value
3. In the Tunnel Mode Client Settings section, configure the following settings:
Field Value
4. In the Authentication/Portal Mapping section, select All Other Users/Groups, and then click Edit.
5. In the Portal drop-down list, select web-access, and then click OK.
6. Click Apply to save the changes.
7. Click OK to confirm the use of the built-in certificate.
Notice the warning message displayed on the top of this page. It indicates that you need to create a firewall
policy for SSL-VPN connections.
Now, you will create a firewall policy that allows traffic to the local subnet (10.0.1.0/24) from remote users
connected to the SSL-VPN portal.
Field Value
Name SSL-VPN-Access
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action ACCEPT
NAT Disabled
3. Click OK.
4. Click OK to confirm the use of the built-in certificate.
The SSL-VPN firewall policy will only allow traffic from users within the group SSL_
VPN_Users.
Now, you will test the SSL-VPN by accessing resources remotely within the local subnet (10.0.1.0/24) .
For this, you will connect to the SSL-VPN portal using the Remote-Windows VM, and then you'll perform an RDP
connection to the Local-Windows VM.
For SSL connections, FortiGate is using a built-in certificate, which is signed by a certificate authority that
the browser does not trust.
3. Click Advanced, click Add Exception, and then click Confirm Security Exception.
The remote login page opens.
Field Value
Host 10.0.1.10
3. Keep the default values for the remaining settings, and then click Launch.
4. Wait five seconds, and then click TRAININGAD\Administrator when it appears.
5. Enter the password password.
You are now remotetly connected to the Local-Windows VM.
In this exercise, you will customize the SSL-VPN portal with a new color and a predefined bookmark.
Field Value
Theme Red
9. In the Predefined Bookmarks section, click Create New, and then configure the following settings:
Name Local-Windows VM
Type HTTP/HTTPS
URL http://10.0.1.10
Now, you will connect again to the SSL-VPN portal on the Remote-Windows VM to access the resources in the
local subnet (10.0.1.0/24).
For this, you will access the Local-Windows VM using the predefined bookmark on the SSL-VPN Portal.
Notice that the SSL-VPN Portal looks different and provides fewer settings.
Now, you will examine the reverse HTTP proxy mechanism, to learn how SSL-VPN connections in web mode
work..
If you were on the local network while accessing the website, the address would be http://10.0.1.10.
But, because you are accessing it remotely through FortiGate's HTTP proxy, the URL is different.
https://10.200.1.1:10443 Indicates that the connection is SSL/TLS-encrypted, and that the portal is
on FortiGate's port1 SSL-VPN gateway.
10.0.1.10/ Indicates the destination IP address of the website inside your private
network, which you are accessing through the VPN.
FortiGate encrypts the connection to the browser, but the destination server's IP
address in the URL is displayed in clear text, not hidden from users. The secondary
connection, from FortiGate's HTTP proxy to the bookmarked website, is not
encrypted.
Now, you will monitor and disconnect an SSL-VPN user from the FortiGate GUI.
In this exercise, you will change the SSL-VPN settings to allow remote access to the resources in the local subnet
(10.0.1.0/24), but perform a connection in tunnel mode from the Remote-Windows VM.
You will use the remote access module of FortiClient 5.6.0, which supports Fortinet's SSL-VPN client.
Now, you will change the SSL-VPN portal mapping settings to use tunnel-access, in order to allow connections
in tunnel mode only.
The full-access setting available on FortiGate supports both web and tunnel mode.
Now, you will establish the routing address to use in tunnel mode.
4. Click OK.
SSL-VPN connections in tunnel mode require FortiClient. You will use FortiClient that is installed on the Remote-
Windows VM to test your configuration.
5. Click Apply.
6. Click Close.
Now, you will connect using the student account to test tunnel mode.
3. Click Connect.
4. Click Yes to accept the certificate.
The tunnel is connected.
http://10.0.1.10
This time, you are not using the reverse HTTP proxy as in the case of web-access mode. The IP traffic is
directly encapsulated over HTTPS and sent through the tunnel.
Now, you'll review the VPN events for both of the SSL-VPN connections you performed in this lab (web and tunnel
modes).
The second most recent tunnel-up log in the VPN event list, shows the SSL-VPN connection in tunnel mode
through FortiClient. Notice this log presents two IP addresses:
Notice the Tunnel Type indicator in the log details shown in the previous step.
In this lab, you will configure a dialup VPN between two FortiGate devices. You will also create a dialup VPN
between a FortiGate and FortiClient.
Objectives
l Deploy a dialup VPN between two FortiGate devices.
l Deploy a dialup VPN between FortiGate and FortiClient.
Time to Complete
Estimated: 45 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file on Remote-FortiGate and Local-FortiGate .
Make sure to restore the correct configuration on each FortiGate using the following
steps. Failure to restore the correct configuration on each FortiGate will prevent you
from doing the lab exercise.
In this exercise, you will configure dialup VPN between the Local-FortiGate and the Remote-FortiGate. The
Local-FortiGate will act as dialup server and Remote-FortiGate will act as dialup client.
Now, you will configure the IPsec VPN by creating phases 1 and 2.
Field Value
Name To Remote
4. Click Next.
5. In the Network section, configure the following settings:
Field Value
Interface port1
Field Value
Mode Aggressive
Peer ID fortinet
The peer ID shown in the configuration above was selected, which you need if you
have more than one dialup client.
Field Value
Although you have created a route-based IPsec tunnel, you do not need to add a static
route because it is a dialup VPN. FortiGate will dynamically add or remove appropriate
routes to each dialup peer, each time the peer's VPN is trying to connect.
Now, you will create two firewall policies between port3 and To Remote: one for each traffic direction.
Field Value
Name Remote_out
Source LOCAL_SUBNET
Destination REMOTE_SUBNET
Schedule always
Service ALL
Action ACCEPT
Field Value
Name Remote_in
Source REMOTE_SUBNET
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action ACCEPT
Name To local
5. Click Next.
6. In the Network section, configure the following settings:
Field Value
IP Address 10.200.1.1
Interface port4
Field Value
Mode Aggressive
Field Value
Local ID fortinet
The local ID should be same as the peer ID that you configured on the Local-FortiGate
that is acting as the dialup server.
Now the quick mode selectors in both sides mirror each other. If that is not the case,
the tunnel will not come up.
Now, you will create one static route, because the current VPN is route based.
Destination Subnet
10.0.1.0/24
Device To local
4. Click OK.
Create the Firewall Policies for VPN Traffic on Remote-FortiGate (Dialup Client)
Now, you will create two firewall policies between port6 and To Local: one for each traffic direction.
Field Value
Name Local_out
Source REMOTE_SUBNET
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action ACCEPT
Field Value
Name Local_in
Source LOCAL_SUBNET
Destination REMOTE_SUBNET
Schedule always
Service ALL
Action ACCEPT
Now that you have configured the VPN on both FortiGate devices, you will test the VPN.
The Status column of the VPN now contains a green up arrow, indicating that the tunnel is up.
No. With the current configuration, the tunnel will stay down until you manually bring it up or there is traffic
that should be routed through the tunnel. Because you are not generating traffic between 10.0.2.0/24
and 10.0.1.0/24 subnets yet, the tunnel is still down. If you had generated the required traffic while the
tunnel was down, it would have come up automatically.
You can only initiate a tunnel from Remote-FortiGate because it is a dialup client .
9. Open a new browser tab and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and leave the
password field empty.
10. Click Monitor > Routing Monitor.
Now, you will now create a dialup VPN between FortiGate and FortiClient.
Prerequisites
Before beginning this lab, you must restore a configuration file on Remote-FortiGate and Local-FortiGate.
Make sure to restore the correct configuration on each FortiGate using the following
steps. Failure to restore the correct configuration on each FortiGate will prevent you
from doing the lab exercise.
Field Value
Name FClient
4. Click Next.
5. Configure the following settings:
For the purpose of this exercise, the User Group training is preconfigured for you.
6. Click Next.
7. Configure the following settings:
Field Value
Subnet 255.255.255.0
8. Click Next.
9. Verify that Save Password is enabled.
10. Click Create.
The VPN wizard creates IPsec phases 1 and 2, as well as clientaddress range firewall address, and one
firewall policy that allows incoming traffic from the VPN to the internal subnet.
Although you have created a route-based IPsec tunnel, you do not need to add a static
route because it is a dialup VPN. FortiGate will dynamically add or remove appropriate
routes to each dialup peer, each time a peer's VPN is established or disconnected.
Now, you will configure the FortiClient IPsec client to connect to Local-FortiGate. You will use the FortiClient
installed on the Remote-Windows VM.
Field Value
fortinet
Username student
6. Click Apply.
7. Click Close.
Now, you will use FortiClient to connect to the dialup VPN you created on Local-FortiGate.
2. Click Connect.
Wait for few seconds.
While the dialup VPN is up, the Remote-Windows VM receives an IP address in the 172.20.1.1 -
172.20.1.5 range. FortiGate also installs a route to the subnet 10.0.1.0/24.
ipconfig /all
Now, you will test the dialup VPN by sending traffic from the Remote-Windows VM to the Local-Windows VM.
Now, you will disconnect the Remote-Windows VM from the dialup VPN.
In this lab, you will use data leak prevention (DLP) rules and sensors to block sensitive data from leaving the
private network.
Objectives
l Configure DLP to block ZIP files.
l Read and interpret DLP log entries.
l Set up DLP banning and quarantining.
l Configure DLP fingerprinting.
Time to Complete
Estimated: 30 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
There are multiple ways to configure DLP to prevent sensitive information from leaving your network.
In this exercise, you will configure DLP to block files by file type, and apply DLP to a firewall policy. Then, you will
test the configuration and view the logs.The DLP feature is only available in the proxy mode.
Enable DLP
By default, DLP is not enabled in the GUI. You will enable DLP to be visible in the GUI.
To enable DLP
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and
leave the password field empty.
2. Click System > Feature Visibility.
3. In the Security Features section, enable DLP.
4. Click Apply.
You will configure a new DLP sensor, and create a DLP filter to block ZIP files.
Field Value
Type Files
Tip: On right side of the screen, type the name in the search box, and
then click file types to add.
Action Block
6. Click OK.
7. Click Apply.
You can also block traffic based on a file name of *.zip, but it is not recommended. A
person could circumvent that type of DLP by changing the filename to, for example,
*.zp1, or *.txt.
By comparison, file type identification works by analyzing the binary layout of the file.
Now that you have created a DLP sensor, you will edit the existing firewall policy to apply the DLP sensor to it.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Test the DLP Sensor on page 232 .
Now, you will test the DLP sensor by trying to transmit a ZIP file by uploading the file to a web URL.
http://10.200.1.254/fileupload.html
Now, you will check the logs related to DLP for the test you performed previously.
4. On the right side of the screen, the Details tab shows the forward traffic log information, such as NAT translation,
NAT IP, policy ID, and security action.
You can also view DLP logs under Log & Report > Data Leak Prevention.
The DLP logs section will not display if there are no DLP logs. FortiGate will show it
after creating logs. If the DLP menu item does not display in the GUI, refresh your
browser or log out of the Local-FortiGate GUI and log back in again.
You can configure the DLP filter to quarantine IP addresses that are trying to leak sensitive information. The
quarantined IP address will be blocked from accessing the network so that you have time to investigate the issue.
Quarantine an IP Address
Now, you will modify the action of the previously configured DLP filter to quarantine the IP address.
To quarantine an IP address
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as admin and
leave the password field empty.
2. Click Security Profiles > Data Leak Prevention.
3. In the upper-right corner of the screen, from the drop-down menu, select No_ZIP_files.
6. Click OK.
7. Click Apply.
Now, you will test the quarantine action by trying to upload a ZIP file.
http://10.200.1.254/fileupload.html
5. On the Local-Windows VM, open a few new web browser tabs and go to the following websites:
l http://10.200.1.254
l http://10.200.3.254
A replacement message appears instead of the website. This occurs because the IP address that is sending
the request has been quarantined and is not allowed through the firewall policy on FortiGate.
Now, you will remove the quarantined IP address from the banned entry list so that you can access the network.
DLP fingerprinting is a technique that uses content-based filtering and identifies specific files using one or more
cyclic redundancy checks (CRC) for the files in the configured network share.
A network share is preconfigured on the Local-Windows VM with a user account of Administrator and share
name of DLPshare.
In the configuration that you uploaded at the beginning of this exercise, FortiGate is preconfigured to access the
network share.
In this procedure, you will first view the DLP configuration for the network share, and then you will configure a new
filter for DLP fingerprinting.
You will notice that the Local-FortiGate is configured to access the network share configured on Local-
Windows with an IP address of 10.0.1.10.
4. Enter the following commands to configure a new filter for DLP fingerprinting in the DLP sensor named No_ZIP_
files:
config dlp sensor
edit No_ZIP_files
config filter
edit 2
set proto http-post
set filter-by fingerprint
set fp-sensitivity Critical
set action block
end
end
The DLP fingerprinting filter can be configured using only the CLI. After it is
configured, it is visible on the GUI.
3. Click OK.
4. Click Save File.
5. Click OK.
The file saves to the Downloads folder.
7. Click the down arrow download icon on the top right of the browser.
8. Right-click the backup file for your configuration, and then click Open Containing Folder.
Now, you will test DLP fingerprinting for the file you added to the network share. DLP fingerprinting is configured
based on a schedule. For the purpose of this lab, we will trigger fingerprint checksums manually, using CLI
commands. This is because training is conducted at different times globally, and a configured schedule may not
work correctly.
http://10.200.1.254/fileupload.html
4. On the web page, click Browse, and go to C: > DLPshare > Local-FortiGate_
<yourtimestamp>.conf.
5. Click Open.
6. Click Submit the file.
The file upload should be blocked.
5. Close Notepad++.
Now, you will test DLP fingerprinting using the modified file in the network share. DLP fingerprinting is configured
based on schedule. For the purpose of this lab, you will trigger fingerprint checksums manually, using CLI
commands. This is because training is conducted at different times globally and using a configured schedule
might not work correctly.
Tip: You can press the up button on your keyboard twice to get that command you entered previously.
2. Run the following command to check the updated checksum:
http://10.200.1.254/fileupload.html
Fingerprinting breaks the file into chunks and performs checksums on each part. By
default, DLP will detect a match if any part's checksum from the fingerprint matches.
No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2018 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.