High Performance Security

Workshop
- hands-on lab -

1. Lab objectives

 Understand the various actions that can be set in a firewall policy

 Understand policy order
 Configure proxy-based and flow-based antivirus scanning
 Configure application control in the student lab environment
 Create an identity-based policy
 Configure IPS profiles (optional)

2. Lab topology

High Performance Security Workshop 1

3. Lab 1: Firewall Policies

The Lab environment has been preconfigured for this workshop, allowing administrative access
to the FGStudent_X and FGRemote_X devices. You will configure firewall policies and apply
security profiles on the configured firewall policies in the following exercises.

Exercise 1: Creating Firewall Objects and Rules

1. Connect via RDP to the StudentX server using Administrator / admin login credentials.
Using Firefox Web browser open a new tab and access FGStudent_X GUI with
https://10.1.X.254.

Accept the FortiGate unit’s self-signed certificate or security exemption if a security

warning appears. HTTPS is the recommended protocol for administrative access to the
FortiGate unit. Other available protocols include SSH, PING, SNMP, HTTP and Telnet.

Note: To access the FortiGate GUI using a standard web browser, cookies and JavaScript
must be enabled for proper rendering and display of the graphical user interface.

At the login screen, enter the default username of admin and leave the password blank.

2. From the GUI on the FGStudent_X device, go to Policy & Objects > Addresses and verify if
the following address object exists. If it does not exist, create a new one with the following
settings:

Address Name: Student_X_Internal

Type: IP/Netmask
Subnet/IP Range: 10.1.X.0/255.255.255.0
Interface: any

3. The unrestricted internal->wan1 policy will need to be temporarily disabled in the policy
list. To do this, go to Policy & Objects > IPv4 Policy, right-click the Seq.# column of the
internal->wan1 policy and click Disable in the pop-up menu.

4. Next click Create New to add a new firewall policy to provide general Internet access from
the internal network. Configure the following settings:

Incoming Interface: internal

Source Address: Student_X_Internal
Outgoing Interface: wan1
Destination Address: all
Schedule: always
Service: HTTP, HTTPS, DNS, ALL_ICMP, SSH

High Performance Security Workshop 2

 Action: ACCEPT
NAT: ON
Use Outgoing Interface Address: Enabled
Logging Options: Log All Sessions Enabled
Comments: General Internet access

When creating firewall policies, keep in mind that the FortiGate device is a stateful
firewall, therefore a firewall policy only needs to be created for the direction of the
originating traffic.

5. From the StudentX server, open a web browser and connect to various external web
servers.

6. On the FGStudent_X device go to Policy & Objects > IPv4 Policy and right-click any of the
column headings. In the pop-up menu, make sure that the Count column is enabled and
if not enable it. This column displays packet and bytes count for each firewall policy. Move
this column left or right in the policy table accordingly, for easier viewing.

7. Using putty or other terminal, connect via SSH to the FGStudent_X device – 10.1.X.254.
Login with user admin and no password, then enter the following command to see the
source NAT action:

get system session list

Sample Output:

PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT

tcp 3599 10.1.1.1:3931 - 10.1.1.254:443 -
tcp 3494 10.1.1.1:3922 10.100.1.1:64338 74.125.137.138:80 -
tcp 3599 10.1.1.1:3932 - 10.1.1.254:443 -
tcp 3494 10.1.1.1:3923 10.100.1.1:64339 74.125.134.101:80 -
udp 179 10.1.1.254:1024 - 10.1.1.1:514 -

High Performance Security Workshop 3

8. Note that the new source address being applied is that of the destination interface wan1
(10.100.X.1).

Exercise 2: Policy Action

1. Use the same steps you performed earlier to create a second firewall policy. Configure
the following settings:

Incoming Interface: internal

Source Address: Student_X_Internal
Outgoing Interface: wan1
Destination Address: Click Create and configure the following:
Name: WAN1_GW
Type: IP/Netmask
Subnet/IP Range: 10.100.X.254/255.255.255.255
Schedule: always
Service: PING
Action: DENY
Log Violation Traffic: ON

2. From the StudentX server, open a command prompt window and ping the wan1 gateway
as follows:

ping –t 10.100.X.254

Provided you have not changed the rule ordering, the ping should still work as it matches
the ACCEPT policy and not the DENY policy just created. This demonstrates the behavior
of policy ordering. The second policy was never checked because the traffic matched the
first policy.

3. From the GUI on the FGStudent_X device, go to Policy & Objects > IPv4 Policy and right-
click any of the column headings. In the pop-up menu, select ID and click Apply
afterwards. Move this column accordingly for easier viewing. By default only the
sequence number of the firewall policy is displayed in the GUI.

High Performance Security Workshop 4

4. Next, left-click the Seq.# for the DENY policy created previously and drag this policy
upwards to position it before the General Internet access policy.

5. Return to the StudentX server and examine the command prompt window still running
the continuous ping. You should observe that this traffic is now blocked.

High Performance Security Workshop 5

4. Lab 2: Antivirus Scanning

Exercise 1: Antivirus Testing

1. Go to Security Profiles > AntiVirus and edit the default profile.

Configure the following details to enable AV scanning on HTTP:

Inspection Mode: Proxy

Virus Scan and Block: Select HTTP and deselect all other settings

2. Go to Policy & Objects > IPv4 Policy and edit the General Internet access policy defined
earlier. Turn on AntiVirus and select the default antivirus profile. Click OK.

3. Next go to Security Profiles > Proxy Options and examine the UTM proxy options. The
default profile is displayed. These settings determine how FortiOS handles each
protocol. For example, which port numbers to use, whether to use client comforting,
or Block Oversized File/Email and so on.

4. Go to System > Replacement Message. From the top right-hand corner select
Extended View and under Security modify the Virus Block Page as you wish.

The HTML editor that is displayed allows you to see the changes as you are making
them. Click Save shown above the editor window to apply your changes.

5. On the virtual StudentX server, launch a web browser and access the following web
site:

http://eicar.org

6. On the Eicar web page, click Download Anti Malware Test File (located in the top right-
hand corner of the page) and then click the Download link that appears on the left.
Download the eicar.com file from the Download section area using the HTTP protocol.
The download attempt will be blocked by the FortiGate unit and a replacement
message will be displayed similar to the following (should also include any
customization you made earlier):

High Performance Security Workshop 6

 The Eicar file is an industry-standard used to test antivirus detection. The file contains
the following characters:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

7. The HTTP virus message is shown when infected files are blocked or have been
quarantined. In the message that is displayed, click the link to the Fortinet Virus
Encyclopedia to view information about the detected virus.

8. Go to the Eicar download page again. This time, select the eicar.com file from the
Download area using the secure, SSL enabled HTTPS protocol section. The download
should be successful.

9. To enable inspection of SSL encrypted traffic on the FGStudent_X unit, go to Security

Profiles > SSL Inspection and edit the deep_inspection profile. Under SSL Inspection
Options, enable the HTTPS protocol on port 443. After that, choose the
deep_inspection SSL Inspection profile in the firewall policy.

10. To ensure that there are no existing sessions prior to deep scanning the
communication exchange, connect to the CLI of the FGStudent_X device and enter the
following command:

High Performance Security Workshop 7

 diag sys session filter dport 443
diag sys session clear

11. Return to the Eicar web page and attempt to download the eicar.com file from the
Download area using the secure SSL enabled HTTPS protocol section. This time, the
download will be blocked by the FortiGate unit and the replacement message will be
displayed. (If this is not the case, you may need to clear your recent browsing history
as the object may be cached.)

12. Go to Security Profiles > AntiVirus and change the Inspection Mode for the default
antivirus profile to Flow-based. Click Apply. If the option doesn't appear, ask the
instructor to guide you through the CLI.
Try downloading the eicar.com (with/without SSL) file again. What happens now
when the virus is detected?

13. Go to Policy & Objects > IPv4 Policy and change the SSL inspection profile for the
General Internet access policy to certificate_inspection.

High Performance Security Workshop 8

5. Lab 3: Application Control

Exercise 1: Creating an Application Control List

1. Go to Security Profiles > Application Control and review the default application control
sensor. (Ensure you are selecting the sensor named default.)

2. On the Edit Application Sensor page, check the settings for the Video/Audio category.

What are the expected actions for this category?

Enable Traffic shaping for the Video/Audio category and select the shared-1M-pipe
traffic shaper. Click Apply.

Go to Policy & Objects > Traffic Shapers. Edit the shared-1M-pipe traffic shaper and
set the maximum bandwidth to 100 Kbps.

3. Go to Policy & Objects > IPv4 Policy and edit the General Internet access policy. Ensure
that Application Control is turned ON and that the default application control sensor
is selected and enable Log all Session under Logging Options.

4. You will now test the application control configuration. From the virtual StudentX
server, open a web browser and connect to Dailymotion website:

http://dailymotion.com

5. On the Dailymotion web site, attempt to play a few videos.

Check the traffic shaper monitor in FortiView > Traffic Shaping. Observe how the
traffic shaper is dropping packets while some content is still delivered to you.

6. Check the application monitor in FortiView > Applications. If you can’t see this menu
than enter the following commands from CLI in order to enable the UTM monitors:

config system global

set gui-utm-monitors enable
end

Logout the management GUI and log back in.

7. Go to Security Profiles > Application Control and edit the default sensor again. Click
Add Signatures under Application Overrides to add a new application filter.

High Performance Security Workshop 9

8. In the search field shown above the Application Name column enter 8tracks. A
window displays with a description of the application including popularity, and a
reference link that you can click to obtain more rating information from the
FortiGuard Center.

Click on the signature row to select the signature and click Use Selected Signatures.
Set the Action field for the filter to Block and click Apply.

Go to www.8tracks.com to test the application sensor.

9. Return the web browser, and attempt to access the following web site:

http://proxite.us

10. On the proxy web page, scroll down to the bottom and enter the URL of 8tracks. Click
Go. You should observe this does allow some connectivity to the site. What action can
be taken to stop this?

You can set the action to block for the Proxy category.

High Performance Security Workshop 10

6. Identity-based Policy

Exercise 1: User Identity-based Firewall Policy

1. From the StudentX server, you first will need to connect to the FGStudent_X device
and restore the configuration file that is needed for this lab.

Connect to the GUI on the FGStudent_X device (10.1.X.254) and restore the following
configuration file: Desktop\Resources\Module4\Student\FGStudent_X_auth.conf.

The FGStudent_X device will reboot.

2. When the device has rebooted review the user configuration for this lab.

Go to User & Device > User Definition to review the local user settings
Go to User & Device > User Groups to review the user group configuration.

3. On the StudentX server, open a web browser and connect to a new web site. At the
login prompt, enter the following credentials:

Username: Student
Password: F0rtinet

You should observe that after successful authentication, you are redirected to your
destination web site.

4. From the GUI on the FGStudent_X device go to Policy & Objects > IPv4 Policy and
review the outgoing firewall policy with authentication configured.

Enable the policy that permits all unauthenticated traffic.

5. Next, open a command prompt and try to ping 10.100.X.2.

What happens?

You should observe that this is permitted because there is an accept rule for this
traffic.

To force authentication on ICMP and SSH traffic add ALL_ICMP and SSH to the identity
policy rule for the training user group, and then disable the policy that allows
unauthenticated ICMP and SSH traffic.

High Performance Security Workshop 11

 Make your configuration change and test again. It still works if the user is still
authenticated.

6. Go to Firewall > User Monitor to view the details of the authenticated user.

7. From the CLI, view the IP addresses and users which have successfully authenticated
to the FortiGate unit with the following command:

diagnose firewall auth list

Clear all authenticated sessions with the following command:

diagnose firewall auth clear

Caution: Be careful using this command on a live FortiGate unit.

Exercise 2: Device Identity-based Firewall Policy

In this exercise you will create a firewall policy that uses email captive portal. Once the
device is learnt, access to a test web server should be granted to your device.

1. Go to Policy & Objects > IPv4 Policy and delete any existing firewall policies. Then create
two new device identity firewall policies using the following settings:

Policy 1:

Incoming Interface: internal

Source Address: Student_X_Internal
Source Device Type: Linux PC
Outgoing Interface: wan2
Destination Address: all
Schedule: always
Service: HTTP
Action: ACCEPT
Enable NAT: Enabled. Select Use Outgoing Interface Address

Click OK. Click OK on the Enable Device Identification Warning.

High Performance Security Workshop 12

 Policy 2:

Incoming Interface: internal

Source Address: Student_X_Internal
Source Device Type: Collected Emails
Outgoing Interface: wan2
Destination Address: all
Schedule: always
Service: HTTP, HTTPS, ALL_ICMP, SSH, TELNET, SMTP, POP3,
FTP
Action: ACCEPT
Enable NAT: Enabled. Select Use Outgoing Interface Address

Click OK.

2. In the policy table view, drag the Linux PC identity-based policy after the Collected Emails
identity-based policy and disable the Collected Emails device identity-based policy.

3. You will now create a general access firewall policy. Click Create New and configure the
following:

Incoming Interface: internal

Source Address: all
Outgoing Interface: wan2
Destination Address: all
Schedule: always
Service: ALL
Action: Accept
Enable NAT: Enabled. Select Use Outgoing Interface Address
Enable this policy: OFF

4. You will now test the device policy. First, execute the following CLI commands to disable
the email DNS check for the captive portal. (This step is required for the purposes of this
lab.)

config system settings

set email-portal-check-dns disable
end

5. From StudentX web browser, connect to http://10.200.X.254.

What happens? If you followed the example as given, nothing should happen because
you have only allowed Linux PCs and you are connecting from the Windows PC. If access

High Performance Security Workshop 13

 to http page is allowed, please check if the device is already learned. To do this, go to User
& Device > Device Inventory and delete the 10.1.X.1 address associated object.

Once done, try to access http://10.200.X.254 again.

From the CLI use debug flow to confirm this:

diag debug flow filter addr 10.200.X.254

diag debug flow show func en
diag debug flow show cons en
diag debug enable
diag debug flow trace start 20

The following message is displayed: “Denied by forward policy check”.

6. Edit the Linux PC policy and add Windows PC as a second Device type.

7. From your web browser, connect to http://10.200.X.254 again. You should now get to the
webpage.

8. Go to User & Device > Custom Devices & Groups and check the new device. It is located
unde Windows PC group. This device is a dynamic device. These devices may update and
are stored to the flash to speed up detection. Use the following command to list the
devices from CLI:

diag user device list

9. Go to User & Device > Device Inventory and delete the Windows device listed in there.

10. Perform a show from the CLI to confirm there are no devices in the configuration file.

show user device

Edit the policies created at step 2. Remove Windows PC device type from the first policy
and enable the Collection Emails policy.

Try to access the http://10.200.X.254 webpage again. When prompted add an email
address and click OK. Once email is collected, you should be redirected to http page. The
Collected Emails device sub-policy will match in this case.

11. From the GUI, go to User & Device > Device Inventory and edit your device from the device
list. Add an alias called myDevice. This creates a static device in the configuration file.

High Performance Security Workshop 14

 Perform the following show command to confirm that the device now appears in the
configuration file.

show user device

12. Go to User & Device > Custom Devices & Groups. Note that your device is already a
member of several predefined device groups. Click Create New and add a new device
group called myDevGroup. From the Members drop-down list, select myDevice and click
OK.

Note that your device is still a member of the predefined groups and is now a member of
the Custom type group called myDevGroup.

13. From the StudentX server, test that you can open a Telnet connection to 10.200.X.254.
You should observe the login prompt on the FGRemote_X device CLI menu.

14. Now add a new policy blocking Telnet:

Incoming Interface: internal

Source Address: Student_X_Internal
Source Device Type: myDevGroup
Outgoing Interface: wan2
Destination Address: all
Schedule: always
Service: TELNET
Action: DENY
Log Violation traffic: ON

Click OK.

Use drag-and-drop to reorder the policies so that this policy is first in the list.

15. Perform a telnet test to see if you can open a Telnet connection to 10.200.X.254. You
should observe that the connection now fails to establish.

High Performance Security Workshop 15

7. IPsec VPN

Exercise 1 – Route-based IPSec VPN

1. From the StudentX server, you need to connect to the FGStudent_X device and restore the
Desktop\Resources\Module7\Student\FGStudent_X_ipsec.conf configuration file.

The FGStudent_X device will reboot.

2. From the RemoteX server, connect to the FGRemote_X device and restore the
Desktop\Resources\Module7\Remote\FGRemote_X_ipsec.conf configuration file.

3. From the GUI of FGStudent_X device go to VPN > IPsec Tunnels and click Create New.

4. Configure the following settings:

Name: ToRemote
Template Type: Site to Site
Remote Device Type: FortiGate
NAT Configuration: No NAT between sites

5. Click Next.

6. Configure the following settings:

Remote Device: IP Address

IP Address: 10.100.X.2
Outgoing interface: wan1
Authentication Method: Pre-shared Key
Pre-shared Key: fortinet

7. Click Next.

8. Configure the following settings:

Local Interface: internal

Local Subnets: 10.1.X.0/24
Remote Subnets: 10.2.X.0/24

9. Click Create. You should see the following screen:

High Performance Security Workshop 16

10. Click Show Tunnel List. You will see the VPN you have just created:

11. To review the objects created by the VPN wizard log on FGStudent_X and go to VPN > IPsec
Tunnels.

12. Select the VPN and click Edit. Observe the quick mode selectors that the wizard configured
for you:

High Performance Security Workshop 17

 You will need this information to configure the other FortiGate. The quick mode selctors in
both sides must mirror each other. In other words, the Local Address in one side must match
the Remote Address in the other side.

13. Go to Network > Interfaces.

14. Click on the plus sign added to port1. You will see a new virtual interface named ToRemote
(matching the phase 1 name).

Note: What does this virtual interface tell us about the VPN created by the wizard? Is it policy-
based or route-based?

High Performance Security Workshop 18

The wizard created the VPN using a route-based configuration. The FortiGate automatically adds
an IPsec virtual interface for each VPN configured as route-based. This does not happen in a
policy-based configuration.

15. Go to Policy & Objects > Addresses and observe two new Firewall address objects:
ToRemote_local_subnet_1, and ToRemote_remote_subnet_1.

16. Go to Policy & Objects > IPv4 Policy and observe the new two firewall policies: one from
Internal to ToRemote and one from ToRemote to Internal. You will see that the Action in
both cases is Accept.
17. Go to Network > Static Routes and look at the static route added by the wizard.

Exercise 2 – Policy-based IPSec VPN

For learning purposes, you will do the configuration on both FortiGates differently. During this
exercise, you will create the VPN on the Remote-FortiGate side without using the wizard and
using a policy-based configuration.

Unhiding the Policy-based VPN Settings

Policy-based configuration is hidden from the GUI by default. You will un-hide it.

1. To do so, from the RemoteX device go to System > Feature Select.

2. Enable Policy-based IPsec VPN.

3. Click Apply.

Creating a Policy-based VPN

You will create the phases 1 and 2.

4. To create a policy-based VPN, on the RemoteX device, go to VPN > IPsec Tunnels.

5. Click Create New.

6. Type the name ToLocal and select Custom as the template name.

7. Click Next.

8. Disable the setting Enable IPsec Interface Mode:

9. Configure the following settings:

High Performance Security Workshop 19

 Remote Gateway: Static IP Address
IP Address: 10.100.X.1
Interface: FGRemote_X_WAN1
Mode Config: Disabled
NAT Transversal: Disabled

Dead Peer Detection: On Idle

Method: Pre-shared Key
Pre-shared Key: fortinet

10. Leave the other parameters with its default values and scroll down the windows to display the
phase 2 settings. Click the pencil icon to edit the Phase 2 Selectors:

11. Enter 10.2.X.0/24 as the Local Address and 10.1.X.0/24 as the Remote Address:

High Performance Security Workshop 20

12. Click OK.

Note: Now the quick mode selectors in both sides mirror each other. If that is not the case, the
tunnel will not come up.

Creating a Policy-based VPN

The last step is to create a firewall policy to allow traffic. In a policy-based configuration only one
policy is required to allow traffic initiated at either side. The policy is applied bi-directionally.
1. From the RemoteX device GUI, go to Policy & Objects > IPv4 Policy.

2. Click Create New.

3. Configure the following settings:

Name: VPN traffic to Local

Incoming Interface: FGRemote_X_LAN
Outgoing Interface: FGRemote_X_WAN1
Source: Remote_X_Internal
Destination Address: Student_X_Internal
Schedule: always
Service: ALL
Action: IPsec
VPN Tunnel: ToLocal
Allow traffic to be initiated from the remote site: Enabled

4. Click OK.

Note: This is probably the first time you see the action IPsec for a firewall policy. In previous
exercises the available actions were Accept and Deny only. The action IPsec is displayed in the
GUI only when the policy-based VPN settings are not hidden.

High Performance Security Workshop 21

Moving a Firewall Policy

The new policy was created below the firewall policy for Internet traffic. You will need to move it
up for the VPN traffic to match it.

1. From the RemoteX device GUI, go to Policy & Objects > IPv4 Policy.

2. Expand the list of firewall policies from FGRemote_X_LAN to FGRemote_X_WAN1.

3. Drag and drop the policy for VPN traffic to Local to the top:

Note: In the previous exercise, the VPN wizard added a static route for the VPN traffic. Why don’t
you need to add a static route in this case?

The VPN wizard creates the IPsec using route-based configuration, which always requires
additional routes (usually static routes) to route the traffic through the IPsec virtual interface. This
is usually not required in policy-based configuration. What policy-based configuration requires is
the VPN traffic matching a firewall policy with the action IPsec. As traffic from 10.2.X.0/24 to
10.1.X.0/24 matches the existing default route, and so the IPsec firewall policy from internal to
wan1, no additional routes are needed.

Exercise 3 – Testing and Monitoring the VPN

1. From the StudentX device GUI, go to Monitor > IPsec Monitor. Observe that the VPN is
currently down.

2. Right click the VPN and select Bring Up:

High Performance Security Workshop 22

The Status of the VPN will show the green up arrow, indicating that the tunnel is up.

Note: Do I always have to manually bring the tunnel after creating?

No. With the current configuration, the tunnel will stay down until either you manually bring it up
or there is traffic that should be routed through the tunnel. As you are not generating traffic
between 10.1.X.0/24 and 10.2.X.0/24 yet, the tunnel was still down. If you had generated the
required traffic while the tunnel was down, it would have gone up automatically.

3. Open a command prompt window on the Student X Server and execute the following
command to ping RemoteX Server:

ping 10.2.X.1

The ping should work.

4. Go back to the StudentX GUI and go to Monitor > IPsec Monitor.

5. Click Refresh to refresh the screen. You will observe that counters for Incoming Data and
Outgoing Data have increased. This indicates that the traffic between 10.1.X.1 and 10.2.X.1
is successfully being encrypted and routed through the tunnel:

Congratulations. You have successfully configured an IPsec VPN between two FortiGate devices.

High Performance Security Workshop 23