301 Student Lab Guide

7/18/2019 301 Student Lab Guide

http://slidepdf.com/reader/full/301-student-lab-guide 1/91

FortiGate Multi-Threat Security Systems IISecured Network Deployment and IPSec VPN

Student Lab Guide

Course 301



FortiGate Multi-Threat Security Systems

Secured Network Deployment and IPSec VPN

Student Lab Guide

Course 301

01-50003-0301-20131018-D

© Copyright 2013 Fortinet, Inc. All rights reserved. No part of this publication including text,

examples, diagrams, or illustrations may be reproduced, transmitted, or translated in any form

or by any means, electronic, mechanical, manual, optical, or otherwise, for any purpose,

without prior written permission of Fortinet, Inc.

Trademarks

Dynamic Threat Prevention System (DTPS), APSecure, FortiASIC, FortiBIOS, FortiBridge,

FortiClient, FortiGate, FortiGate Unified Threat Management System, FortiGuard, FortiGuard-

Antispam, FortiGuard-Antivirus, FortiGuard-Intrusion, FortiGuard-Web, FortiLog, FortiAnalyzer,

FortiManager, Fortinet, FortiOS, FortiPartner, FortiProtect, FortiReporter, FortiResponse,

FortiShield, FortiVoIP, and FortiWiFi are trademarks of Fortinet, Inc. in the United States and/orother countries. The names of actual companies and products mentioned herein may be the

trademarks of their respective owners.



P a g e | 1

Course 301 Secured Network Deployment and IPSec VPN

01-50003-0301-20131018-D

VIRTUAL LAB ENVIRONMENT BASICS ............................................................................... 3 Topology for Labs .............................................................................................................................................................................. 3 Logging in to the Virtual Lab Environment............................................................................................................................ 4

CLASSROOM LAB CONFIGURATION .................................................................................. 8

Lab Preparation (Optional) ........................................................................................................................................................... 9

MODULE 11 ................................................................................................................... 10

Lab 1: Router Configuration and Troubleshooting ............................................................................................ 10 Exercise 1 Connectivity Troubleshooting ............................................................................................................................ 11

Exercise 2 Configuring Dead Gateway Detection ............................................................................................................. 16 Exercise 3 Failover and Load-Balancing Using Static Routing ................................................................................... 18 Exercise 4 Dynamic Routing ...................................................................................................................................................... 22

MODULE 12 ................................................................................................................... 25

Lab 1: Virtual Networking ........................................................................................................................................... 25 Exercise 1 Creating VDOMs and VDOM Objects ................................................................................................................ 26

MODULE 13 ................................................................................................................... 31

Lab 1: Transparent Mode VDOMs ............................................................................................................................. 31 Exercise 1 Transparent VDOM ................................................................................................................................................. 32 Exercise 2 InterVDOM Link .................................................................................................................................................... .... 33

MODULE 14 ................................................................................................................... 36

Lab 1: High Availability ................................................................................................................................................ 36 Exercise 1 Configuring and Testing the HA Cluster ........................................................................................................ 38

MODULE 15 ................................................................................................................... 41

Lab 1: Advanced IPSec VPN ......................................................................................................................................... 41

Exercise 1 Configuring IPSec VPNs ......................................................................................................................................... 42 Exercise 2 Testing the IPSec VPN Configuration .............................................................................................................. 45 Exercise 3 Configuring Semi-Redundant IPSec VPNs ..................................................................................................... 47 Exercise 4 Testing the Semi-Redundant IPSec VPN Configuration .......................................................................... 48 Exercise 5 Configuring OSPF ..................................................................................................................................................... 50 Exercise 6 Testing the OSPF Configuration ........................................................................................................................ 53 Exercise 7 Enabling Bi-Directional Forwarding Detection .......................................................................................... 55



P a g e | 2


01-50003-0301-20131018-D

Lab 2: IPSec VPN with FortiClient ............................................................................................................................. 57 Exercise 1 Configuring the FortiGate as a VPN Gateway .............................................................................................. 58 Exercise 2 Configuring FortiClient Connect ........................................................................................................................ 60

Exercise 3 Testing the FortiGate to FortiClient IPSec VPN Connection ................................................................. 61

MODULE 16 ................................................................................................................... 62

Lab 1: Intrusion Prevention System ........................................................................................................................ 62 Exercise 1 Defining IPS Sensors ............................................................................................................................................... 63 Exercise 2 Defining DoS Policies .............................................................................................................................................. 65 Exercise 3 Creating Custom Signatures ................................................................................................................................ 68

MODULE 17 ................................................................................................................... 69

Lab 1: Fortinet Single Sign On .................................................................................................................................... 69 Exercise 1 Installing FSSO on the Windows Server................................................................................................ ......... 70 Exercise 2 Configuring FSSO on the FortiGate Unit ........................................................................................................ 72 Exercise 3 Testing FSSO On Authentication ....................................................................................................................... 73

MODULE 18 ................................................................................................................... 74

Lab 1: Certificate Operations ..................................................................................................................................... 74 Exercise 1 Create a Certificate Request ................................................................................................................................ 75 Exercise 2 SSL Deep Inspection ............................................................................................................................................... 77

MODULE 19 ................................................................................................................... 82

Lab 1: Data Leak Prevention ...................................................................................................................................... 82 Exercise 1 Blocking Files by Type ........................................................................................................................................... 83 Exercise 2 Blocking Leakage of Credit Card Information ............................................................................................. 86 Exercise 3 DLP Fingerprinting .................................................................................................................................................. 87

MODULE 21 ................................................................................................................... 88

Lab 1: Case Study Scenario .......................................................................................................................................... 88 Background ........................................................................................................................ ................................................................ 88

APPENDIX A: ADDITIONAL RESOURCES........................................................................... 89



Virtual Lab Environment Basics

P a g e | 3


01-50003-0301-20131018-D

This section provides details of the virtual lab environment that will be used for the hands-on labs inthis course. Steps are included for connecting to the virtual environment along with troubleshootingtips to help students easily navigate the lab configuration.

Alert: The following section is only applicable to the Fortinet hosted virtual labenvironment. Please ignore this section if you are using an alternate classroom labenvironment unless otherwise directed by your trainer. If you are uncertain, consult yourtrainer to find out which lab setup documentation you must follow.

The network diagram below shows the configuration of the virtual environment that students will usein the course.




P a g e | 4


01-50003-0301-20131018-D

1. Run the TrueLab System Checker to verify the compatibility of your computer with the virtuallab environment.

Use the URL that is specific to your location.

Americas:

http://truelab.hatsize.com/syscheck

EMEA:

http://truelab.hatsize.com/syscheck/frankfurt/

APAC:

http://truelab.hatsize.com/syscheck/singapore/

Click Run if a security warning window appears.

The TrueLab System Checker will determine whether a connection can be established fromthe PC to the TrueLab environment. It can also help troubleshoot connectivity problemsrelated to the Java Virtual Machine, company firewall, or proxy server.

If the PC is successfully able to connect to the TrueLab virtual lab environment a Successmessage will be displayed.




P a g e | 5


01-50003-0301-20131018-D

If a status of Failed is displayed, verify the on-screen messages to identify potential problemareas or click the Troubleshooter link to help diagnose any problems that were encountered.For assistance with troubleshooting speak to your instructor.

2. If a status of SUCCESS is displayed, log in to the virtual lab portal by browsing to thefollowing URL:

https://remotelabs.training.fortinet.com/

Enter the username and password provided by the instructor and click LOGIN .

Alternatively, you may have received log in credentials for the following URL:

http://virtual.mclabs.com/

Check with your instructor if you are not certain about which portal to use.

3. Select the time zone for your location from the drop-down menu and click UPDATE .

By selecting the proper time zone you ensure that the class schedule is accurate.




P a g e | 6


01-50003-0301-20131018-D

4. The virtual lab Java applet is launched. Select a resolution for the applet and click Open toaccess the Windows 2003 Server device in the virtual lab environment. This will serve as theprimary student machine for the classroom exercises.

Note: If for any reason the connection to the virtual Windows 2003 Server is lost, regainaccess by selecting Operations > Disconnect and then Operations > Connect to Primary fromthe menu.

5. To connect to other virtual machines in this environment go to Operations > Connect toSecondary and select one of the available machines in the list.

The instructor will provide a description of each of the virtual systems available to you in thevirtual lab environment.




P a g e | 7


01-50003-0301-20131018-D

Troubleshooting Tips

It is not recommended to connect to the virtual lab environment using a wireless (Wi-Fi)

connection or a VPN tunnel. For optimal performance, connect to the lab environmentthrough a dedicated LAN connection.

Ensure that the company network or firewall policies are not blocking Java applets.

Students should ensure that the following settings are configured on their computer:

− Screen savers should be disabled on the computer

− The Power Scheme used on the computer should be set to Always on

− In the Java Control Panel (located in the Windows Control Panel) ensure that Javaconsole is set to Show console. It is recommended that the Java console be left openas it often provides useful logs for troubleshooting.

If you get disconnected unexpectedly from any of the virtual machines (or from the virtuallab portal) please reattempt a connection. If unable to reconnect repeatedly after multipleattempts, please notify the instructor.

If during the labs, particularly when reloading configuration files, you see a messagesimilar to the one shown below, go to the console and enter the following CLI command:

execute update-now

This message indicates that the FGT VM is waiting for a response from the authenticationserver. The command ‘execute update-now’ will resend the request and force a response.



Classroom Lab Configuration

P a g e | 8


01-50003-0301-20131018-D

The following diagram illustrates the classroom network configuration that will be used for the labs inthis course. Each student has an identical lab environment and has full control of their lab devices.

Each student will manage the following devices located in the same network segment:

− Windows 2003 Server (full control with RDP access)

− 2 FortiGate devices

− Windows XP (student working device)

− Unix Server (with command line access)



L

P a g e | 9


01-50003-0301-20131018-D

At various points throughout this lab guide, you will be instructed to load different configuration files whichcontain objects and settings needed to complete the exercises.

In order to load these configuration files, you will first need to configure some minimum networkingrequirements. This must be done since the Student and Remote FortiGate devices in the virtual networkingenvironment are provisioned from a raw VM image.

The following steps will guide you through the required preparation. These steps MUST be performedbefore proceeding. If you have already performed these steps as part of attending the 201 Course, thenthese are not required as the environment has already been prepared.

1. Connect to the console of the Student FortiGate device and enter the CLI commands shown below.

(In the virtual lab applet, go to Operations > Connect to Secondary > Student.)conf system interface

edit port3

set ip 10.0.1.254/24

set allowaccess https ping ssh

end

2. Connect to the console of the Remote FortiGate device and enter the CLI commands shown below.(In the virtual lab applet, go to Operations > Connect to Secondary > Remote.)

conf system interface

edit port4

set ip 10.200.3.1/24

set allowaccess https ping ssh

end

conf route static

edit 0

set device port4

set gateway 10.200.3.254

end



Module 11 Lab 1: Router Configuration and Troubleshooting

P a g e | 10


01-50003-0301-20131018-D

The aim of this lab will be for students to set up a router configuration and test various scenarios tolearn how the FortiGate unit makes routing decisions. Students will also work with diagnostics anddebugging commands to troubleshoot their router set-ups.

Students will complete the following tasks:

– Select suitable CLI commands for troubleshooting connectivity issues

– Identify the configuration objects for dead gateway detection and describe the correct usageof this technique

– Describe the fail-over and load-balancing techniques available with static routing anddescribe how to apply a routing policy which takes precedence of the routing table decision

– Identify basic dynamic routing configuration settings and use CLI commands to obtain thestatus of these protocols

Estimated time to complete this lab: 50 minutes



Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1

P a g e | 11


01-50003-0301-20131018-D

From the Windows host you will connect to an external web site (or http://10.200.3.254) and

observe the output of the following diag commands. Note that the web page will need to be re-loaded for each command tested in the steps below.

You will need to define a filter in order to use these commands more easily. In this example, you

could use the source address of the Windows host (10.0.1.10), the service HTTP (port 80) or the

destination address of your target server.

1. From the Windows host, you first will need to connect to each FortiGate device and restorethe configuration files that are needed for this lab.

Connect to the GUI on the Remote FortiGate (10.200.3.1) and restore the following

configuration file: Resources\Module11\Remote\remote-routing.conf .

The Remote FortiGate device will reboot.

Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the

following configuration file: Resources\Module11\Student\\student-routing.conf .

The Student FortiGate device will reboot.

Note: Upon reboot you may receive a message similar to the following: “waitingfor authentication” which relates to the VM license. Use the CLI command‘execute update-now’ to force the check.

2. From the CLI of the Student FortiGate device (either use console or SSH), execute thefollowing commands. In this example, a filter for the source address is used:

diag sniffer packet any ‘host 10.0.1.10’ 4

If you are connecting via SSH from that IP you will want to add a negate filter so that yourSSH connection is not also captured by the sniffer.

diag sniffer packet any ‘host 10.0.1.10 and not port 22’ 4




P a g e | 12


01-50003-0301-20131018-D

Now connect to an external web site and observe the output.

STUDENT # diagnose sniffer packet any 'host 10.0.1.10 and not port

22' 4

interfaces=[any]

filters=[host 10.0.1.10 and not port 22]

8.425242 port3 in 10.0.1.10.4680 -> 10.200.3.254.80: syn 2724505985

8.425574 port3 out 10.200.3.254.80 -> 10.0.1.10.4680: syn 3099662156ack 2724505986

8.426190 port3 in 10.0.1.10.4680 -> 10.200.3.254.80: ack 3099662157

8.426218 port3 in 10.0.1.10.4680 -> 10.200.3.254.80: psh 2724505986ack 3099662157

8.426516 port3 out 10.200.3.254.80 -> 10.0.1.10.4680: ack 2724506380

Here we see the three-way handshake complete and the first exchange of data. Note,because of the NAT action we do not see the traffic on the outgoing interface.

3. Next execute the following commands to look at the session table (negating port 22 ifnecessary):

diag sys session filter src 10.0.1.10

diag sys session filter dport 22

diag sys session filter negate dport

diag sys session list




P a g e | 13


01-50003-0301-20131018-D

You will see various sessions listed such as DNS and HTTP. Look for the HTTP session justestablished,

session info: proto=6 proto_state=02 duration=115 expire=4timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0use=3

origin-shaper=

reply-shaper=

per_ip_shaper=

ha_id=0 policy_dir=0 tunnel=/

state=may_dirty

statistic(bytes/packets/allow_err): org=48/1/1 reply=0/0/0 tuples=2

orgin->sink: org pre->post, reply pre->post dev=4->2/2->4gwy=10.200.1.254/0.0.0.0

hook=post dir=org act=snat 10.0.1.10:4699->10.0.3.254:80(10.200.1.1:65115)

hook=pre dir=reply act=dnat 10.0.3.254:80->10.200.1.1:65115(10.0.1.10:4699)

pos/(before,after) 0/(0,0), 0/(0,0)

src_mac=

misc=0 policy_id=1 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0

serial=0000006e tos=ff/ff ips_view=0 app_list=0 app=0

dd_type=0 dd_mode=0per_ip_bandwidth meter: addr=10.0.1.10, bps=264

Note the NAT action in bold. The action in the originator direction is Source NAT (act=snat)here the original IP address and port number are replaced with the new IP address and portnumbers. (How this new IP address and port number is accessed will be discussed more inthe 201 Firewall Policy module).

4. Next execute the following commands to review the debug flow output, using a filter for thespecific host address and service:

diag debug flow filter addr 10.200.1.254

diag debug flow filter dport 80

diag debug flow show console enable

diag debug flow show function enable

diag debug enable

diag debug flow trace start 20

Note that it is generally better to filter on address and port as opposed to source ordestination address or port as this restricts you to one direction of traffic.




P a g e | 14


01-50003-0301-20131018-D

A sample debug flow output is provided below with notes:

STUDENT # id=13 trace_id=21 func=resolve_ip_tuple_fast line=4048msg="vd-root received a packet(proto=6, 10.0.1.10:4742->10.200.3.254:80) from port3."

SYN received on ingress interface.

id=13 trace_id=21 func=init_ip_session_common line=4176msg="allocate a new session-000000ed"

New session ID generated.

id=13 trace_id=21 func=vf_ip4_route_input line=1602 msg="find aroute: gw-10.200.1.254 via port1"

Originator direction gateway lookup, this happens once for the session provided there is nogateway change. FortiOS is routing first.

id=13 trace_id=21 func=get_new_addr line=2347 msg="find SNAT: IP-10.200.1.1, port-65158"

SNAT value lookup.

id=13 trace_id=21 func=fw_forward_handler line=621 msg="Allowed byPolicy-1: SNAT"

Firewall policy match.

id=13 trace_id=21 func=__ip_session_run_tuple line=2290 msg="SNAT10.0.1.10->10.200.1.1:65158"

SNAT applied to packet (note this is post routing).

id=13 trace_id=22 func=resolve_ip_tuple_fast line=4048 msg="vd-rootreceived a packet(proto=6, 10.200.3.254:80->10.200.1.1:65158) fromport1."

SYN ACK received from server.

id=13 trace_id=22 func=resolve_ip_tuple_fast line=4082 msg="Find anexisting session, id-000000ed, reply direction"

Matches an existing session ID.




P a g e | 15


01-50003-0301-20131018-D

id=13 trace_id=22 func=__ip_session_run_tuple line=2304 msg="DNAT10.200.1.1:65158->10.0.1.10:4742"

DNAT applied on reply direction to inverse SNAT action.

id=13 trace_id=22 func=vf_ip4_route_input line=1602 msg="find aroute: gw-10.0.1.10 via port3"

Reply direction gateway lookup.

id=13 trace_id=23 func=resolve_ip_tuple_fast line=4048 msg="vd-rootreceived a packet(proto=6, 10.0.1.10:4742->10.200.3.254:80) fromport3."

ACK received from client.

id=13 trace_id=23 func=resolve_ip_tuple_fast line=4082 msg="Find anexisting session, id-000000ed, original direction"

Matches an existing session ID.

id=13 trace_id=23 func=ipv4_fast_cb line=50 msg="enter fast path"

Matches an established session.

Debug flow can be combined with other debug commands, such as packet sniffer and

application debug to aid troubleshooting, however for most connectivity issues the debugflow is a very good tool.

Discuss the output of these commands in a group discussion with your Instructor.




P a g e | 16


01-50003-0301-20131018-D

When there are different paths to the same destination, Dead Gateway Detection can be used toprovide a fail-over mechanism whereby a detect server is configured. The detect server is anaddress of a reachable upstream device. The FortiGate unit then uses an echo/echo replymechanism, typically ICMP ping, but UDP echo and TCP echo are also supported. If the device failsto respond after a configured number of retries, then the static routes associated with that interfaceare removed from the routing database.

When a FortiGate unit is configured as part of a site-to-site VPN, the detect server is often the VPNremote gateway.

This is the example we shall use in our virtual lab, therefore the Student FortiGate device has twoDead Gateway Detection entries:

First Entry:

Interface: port1

Gateway IP: 10.200.1.254

Ping Server: 10.200.3.1

Second Entry:

Interface: port2

Gateway IP: 10.200.2.254


Refer to the network diagram provided at the beginning of this lab guide to verify the FortiGatedevice IP addresses.

1. From the GUI on the Student FortiGate device, go to Router > Static > Settings and checkthe above Dead Gateway Detection configuration. The detect server is enabled on theinterface through the CLI.

From the Student FortiGate device run a packet sniffer as follows:

diagnose sniffer packet any ‘icmp’ 4

At this stage, you should observe the request/response traffic on port1, however there is noresponse on port2 because of the Remote FortiGate unit’s current configuration.




P a g e | 17


01-50003-0301-20131018-D

2. Connect to the GUI on the Remote FortiGate device and go to Router > Static > Settings.Click Create New and configure the following two Dead Gateway Detection objects:

First:

Interface: port4

Gateway IP: 10.200.3.254


Second:

Interface: port5

Gateway IP: 10.200.4.254


3. Again, from the Student FortiGate device run a packet sniffer:

diagnose sniffer packet any ‘icmp’ 4

You should now observe the echo request/reply on port2 . By adding the gwdetect entry thishas created a route back to this source in the kernel routing table and therefore thesegateway detect packets now pass the RPF checking. You should now observe ICMP echorequest/reply for both the local and remote gateway detection traffic.

4. You can see the gateway detection entries as special entries in the kernel routing table.Look for the destination and gateways entered.

get router info kernel

tab=254 vf=0 scope=0 type=1 proto=14 prio=010.200.1.1/255.255.255.255/0->10.200.3.1/32 pref=0.0.0.0gwy=10.200.1.254 dev=2(port1)

tab=254 vf=0 scope=0 type=1 proto=14 prio=010.200.2.1/255.255.255.255/0->10.200.4.1/32 pref=0.0.0.0gwy=10.200.2.254 dev=3(port2)




P a g e | 18


01-50003-0301-20131018-D

1. Currently the routing is set up in a fail over configuration. On the Student FortiGate device,the following routes are configured:

0.0.0.0/0 port1 10.200.1.254 distance 10

0.0.0.0/0 port2 10.200.2.254 distance 20

The same method of higher distance is configured on the Remote FortiGate device.With this configuration, the higher distance route is prevented from being used in the routingtable.

Check this by entering the following command on the Student FortiGate device:

get router info routing-table all

You should observe that there is only one default route.

2. Next, enter the following command:

get router info routing-table database

You should note that in the routing database, the second default route is present but not aselected route.

3. Execute the same commands used above from the CLI on the Remote FortiGate device. Youshould observe a similar configuration.

Stop and Think

Under which conditions will the second default route listed in the routing table be used?

Discussion

If the primary link fails, the redundant path (second default route) will be used. This failurecould occur if the link goes down or if the Dead Gateway Detection associated with thatinterface fails.

4. Open a web browser on the Windows Server, and try to connect to the GUI of the Remote

FortiGate unit (10.200.4.1) on port5.

You should observe that this connection fails. This is because there is no route back to thesource on port4. Only a route back for the gateway detect peer is available on the routingtable.

Therefore, if we want incoming traffic on an interface from an unknown source IP we requirea default route for that interface in the routing table.In order to have both default routes in the routing table they must both be of equal distance.




P a g e | 19


01-50003-0301-20131018-D

5. On the Student and Remote FortiGate devices, set the distance of the second default routesto be the same as the primary default route.

6. Next, enter the following commands:get router info routing-table all

get router info routing-table database

You should observe that the route is now selected and appears in the routing table.

Open a web browser on the Windows Server, and connect to the GUI of the Remote

FortiGate unit (10.200.4.1) on port5. Now you should observe that this connection is

successful.

7. We now have a multi-path configuration as there are two available paths for the default route.FortiOS supports Equal Cost Multi Path routing for static routes. In order to configure ECMP,a value called priority is used.

The priority is configured in the static route object. The priority is not used/visible in therouting table. The priority is a value issued in the Forwarding Information Base (FIB).

Tip: What is the FIB?

The FIB is generated by the routing process on the system and is the actualtable used for packet forwarding when sessions are established. It is useful tothink of the routing table as the management plane and the FIB as theforwarding plane. A useful example to illustrate this separation is HA. In an HAcluster, the management plane and forwarding plane are present on the primarydevice, however only the forwarding plane is present on the secondary deviceand this is put in place and updated by the management plane of the primary

device.

8. By default the priority value is 0, therefore, for multiple paths to the same destination in staticrouting, ECMP routing is enabled.

This can be observed by entering the command below used to view the FIB:

get router info kernel

Observe the two entries with destination 0.0.0.0/0 and look for the ‘ prio’ value. Both

entries should have prio=0.

By default ECMP uses the source hash technique for traffic distribution, which means samesource IP and same gateway. In our example, as all traffic is coming from the same sourceaddress, the Windows Sever, it will use the same gateway, so this is not an effective

example of load balancing. Therefore, for the purposes of this example, we will adjust thedistribution settings so that traffic from the same source IP is distributed. (You may be facedwith a similar scenario in your production network).




P a g e | 20


01-50003-0301-20131018-D

9. Change the ECMP distribution method on the Student FortiGate device in Router > Static >Settings. Set the ECMP load balance method to Spillover and set the Spillover Threshold to1(1Kbps)on port1. Leave the port2 setting at 0. (For demonstration purposes we will use this

very low spill-over threshold of 1Kbps).This will enable spill-over where a new gateway is chosen after a higher numbered interfaceis over subscribed.

10. On the virtual Windows Server, open a web browser and connect to a random web site togenerate HTTP traffic.

11. Back in the CLI on the Student FortiGate device, run the following commands:

diagnose sys session filter dport 80

diagnose sys session list | grep dev

Locate the interface pairs by identifying the section dev=4->3/3->4 in the output:

12. From the web browser again on the Windows Server, connect to several other web sites.With the low spill over threshold set, sessions should be distributed across both links. Youcan examine this from the output of the above diagnose command.

Since this command outputs the interface numbers and not their names, use the output ofthe following CLI command to match the interface number to its name:

diag netlink interface list

Alternatively, use the following packet sniffer command to filter TCP packets on port 80 withthe SYN flag set:

diag sniffer packet any ‘tcp[13]&2==2 and port 80’ 4




P a g e | 21


01-50003-0301-20131018-D

13. Next, it may be undesirable to load balance all traffic and there may be hosts and/orprotocols which we would like to use a particular gateway for. This can be achieved withpolicy routing which takes precedence over the routing table.

In this example, you will create a policy route to force all outgoing HTTPS traffic on theStudent FortiGate device to use the gateway: 10.200.2.254. Go to Router > Static >

Policy Route. Click Create New and use the following settings to create your policy route:

Protocol: 6 (TCP)

Incoming Interface: port3

Destination Ports: From: 443 To: 443

Outgoing Interface: port2

Gateway Address: 10.200.2.254

Note: Dead gateway detection also affects policy routes as well as staticroutes, therefore if these do not work, check your detect server settings.

14. The policy route configuration created above can be tested with the following sniffer command and by connecting to an HTTPS enabled web site.

Enter the following command from the CLI on the Student FortiGate device:

diag sniffer packet any ‘port 443’ 4

From the web browser on the Windows Server, connect to the following web site:

https://mail.google.com

Alternatively, you can use https://10.200.3.254 as a target and the packet sniffer filter:

diag sniffer packet any ‘host 10.200.3.254’ 4




P a g e | 22


01-50003-0301-20131018-D

We will now go through a simple BGP configuration that will show us the steps to set up a BGP peerrelationship between the Student and Remote FortiGate devices. In this lab, you will configuredynamic routing using the GUI and CLI and run some CLI diagnostic commands.

1. On the Student FortiGate device, go to Router > Dynamic > BGP and set the followingparameters:

Local As: 65501

Router ID : 0.0.0.1

Click Apply .

2. Next add the BGP neighbor to be announced in BGP using the following details:Neighbor IP: 10.200.3.1

Remote As: 65502

Click Add / Edit.

3. From the CLI of the Student FortiGate device edit the BGP settings and enable multi-hopBGP by entering the CLI commands shown below. This step is required because the BGPpeer is not the next hop.

config router bgp

config neighbor

edit 10.200.3.1

set ebgp-enforce-multihop enable

end

In addition, configure BGP to redistribute all the connected networks.

config redistribute "connected"

set status enable

end

4. On the Remote FortiGate device, go to Router > Dynamic > BGP and set the followingparameters:

Local As: 65502

Router ID: 0.0.0.2

Click Apply .




P a g e | 23


01-50003-0301-20131018-D

5. Now add the BGP neighbor to be announced in BGP using the following details:

Neighbor IP: 10.200.1.1

Remote As: 65501

Click Add / Edit .

6. From the CLI of the Remote FortiGate device, edit the BGP settings and enable multi-hopBGP by entering the CLI commands shown below. This step is required because the BGPpeer is not the next hop.

config router bgp

config neighbor

edit 10.200.1.1

set ebgp-enforce-multihop enable

end

In addition, configures BGP to redistribute all the connected networks.

config redistribute "connected"

set status enable

end

7. Check the routing table of both the Student and Remote FortiGate devices. From the GUI goto Router > Monitor > Routing Monitor , or from the CLI enter ‘get router info routing-table all’.

You should see BGP routes to the announced network of the remote AS.

At this stage we have routing information on the FortiGate devices however there are some

issues that would need to be resolved: the Linux router is not aware of the 10.0.1.0/24

and the 10.0.2.0/24 networks. You would need to add static routes to the Linux router for

this traffic to be forwarded correctly. This is an example of a common deployment, albeit theother way round, where multi-hop BGP is used between routers however it is the FortiGatedevice in between the two routers which is configured with static routes.




P a g e | 24


01-50003-0301-20131018-D

8. From the CLI, run the following command to show routing information for BGP:

get router info bgp summary

9. From the CLI, enable dynamic routing diagnostic output. The following commands willdecode the BGP packets being sent and received between the two peers.

diag debug enable

diag ip router bgp all enable

diag ip router bgp level info

10. While the debug is running, from the GUI of the Remote FortiGate device, change the local AS value to 65522. Observe the error in the debug message now that the remote AS valueno longer matches what is configured for that IP address.

id=0 msg="BGP: 10.200.3.1-Outgoing [DECODE] Open: Bad Remote-AS (65522), expected

65502"id=0 msg="BGP: 10.200.3.1-Outgoing [FSM] State: OpenSent Event: 22"id=0 msg="BGP: 10.200.3.1-Outgoing [ENCODE] Msg-Hdr: Type 3"id=0 msg="BGP: %BGP-3-NOTIFICATION: sending to 10.200.3.1 2/2 (OPEN MessageError/Bad Peer AS.) 4 data-bytes [ff f2 00 00]"

11. On the Remote FortiGate device, change the AS value back to 65502. You should obseverin the debug output that the configuration error is resolved.

12. Enter the following commands to switch off the BGP debug.

diag ip router bgp level none

diag ip router bgp all disable

Disable debugging and reset debug output to defaults.

diag debug disable

diag debug reset



Module 12 Lab 1: Virtual Networking

P a g e | 25


01-50003-0301-20131018-D

The aim of this lab is for students to gain experience working with VDOMs and to be familiar with theVLAN configuration objects.

− Configure and test VDOMs




Module 12 Lab 1: Virtual Networking Exercise 1

P a g e | 26


01-50003-0301-20131018-D

1. From the Windows Server, you first will need to connect to the Student FortiGate device andrestore the configuration file that is needed for this lab.


following configuration file: Resources\Module12\Student\Student-vdom.conf


2. Before enabling VDOMs run the following CLI command:

diag sys vd list

This command lists the configured VDOMs. Observe that there are already VDOMs in place,there is the ‘root’ VDOM which is the default VDOM for all interfaces and there are two others

‘vsys_ha’ and ‘vsys_fgfm’. These other VDOMs are special VDOMs used for HA andFortiManager respectively. We will not be discussing them further in this lab however, thepoint is to demonstrate that enabling VDOMs enables the possibility to create more VDOMs.VDOMs in themselves are fundamental to FortiOS and not a separate feature.

3. On the Student FortiGate device, go to System > Dashboard > Status and in the SystemInformation widget, click the Enable link for Virtual Domain.

You will be logged out of the FortiGate unit and will need to log back in again.

4. Once logged back into the Student FortiGate device, the GUI will automatically display theGlobal Configuration. To access the root VDOM, click Virtual Domains which is displayedat the bottom of the left-hand menu of the GUI.

5. Go to Global > VDOM > VDOM. Create and enable a new VDOM in NAT mode calledcustomer .

Note that the customer VDOM is now listed and you can select it from the VDOM list byclicking Virtual Domains in the lower left-hand corner of the GUI.

6. Create an administrative user for the customer VDOM. In the Global Configuration, go toGlobal > Admin > Administrators and create a new administrator with the following details:

Administrator: customer-admin

Type: Regular

Password: Fortinet

Admin Profile: prof_admin

Virtual Domain: customer

This administrator will only have permission to edit settings within the customer VDOM. Thisadministrator will only be able to log in through an interface that is assigned to the customer VDOM.




P a g e | 27


01-50003-0301-20131018-D

7. You will now place the port3 interface which connects to the internal network, in the customerVDOM. Before trying to move the interface however, you will first need to ensure the port3 interface is not referenced by any objects such as firewall policies, DNS, routing etc.

Go to Global > Network > Interface and note the value listed in the Ref. column for port3. Ifthe value is zero, you can simply edit the interface settings and select the customer vdomfrom the Virtual Domain drop-down list.

For non-zero Ref. values, click on the value and note the object usage references. Removeany objects that reference port3. For example, if port3 is referenced by the system DNS, youwill need to go to System > Network > DNS Server (in the root VDOM) and delete the DNSService on port3. Once all references have been removed, you will be able to move the port3interface to the customer VDOM.

Leave the port1 and port2 interfaces in the root vdom. This will provide a separation betweenthe customer firewall and the firewall that is providing Internet or external access. This is acommon usage scenario and there typically would be several customer type VDOMsconnecting to the single root vdom providing external access. An example of such usage isan airport where each airline and airport service has their own virtual firewall connected to

the root firewall providing the network services.

Now port3 is in the customer vdom and port1 and port2 are in the root vdom.

8. Go to the CLI and look at the routing table for each VDOM:


You may have difficulty entering this command. This is because you need to be in thecontext of your VDOM to enter this command.

To enter the customer vdom context enter the following CLI commands:

config vdom

edit customer




P a g e | 28


01-50003-0301-20131018-D

Note that the VDOM name entered is case sensitive. Afterwards check the routing tablewith the following CLI commands:


next

Now go to the root vdom to view the routing table. Be careful with this command because theVDOM names are case sensitive!! If you enter Root , you will in fact create a new vdom calledRoot in addition to the root vdom.

edit root


9. Next you will create an inter-vdom link to the connect the two vdoms.

On the Student FortiGate device, go to Global > Network > Interface. Click

next to CreateNew displayed in the top left hand corner of the page and select VDOM link . Create a newVDOM Link using the following details:

Name: vlink

Interface #0 vlink0

Virtual Domain: root

IP/Network Mask: 10.10.100.1/30

AdministrativeAccess:

HTTPS, PING, SSH

Interface #1 vlink1

Virtual Domain: customer

IP/Network Mask: 10.10.100.2/30

AdministrativeAccess:

HTTPS, PING, SSH

After creating the inter-VDOM links, note that the VDOM links created along with two sub-interfaces have been placed within the root and customer VDOMs. These interfaces havebeen named vlink0 and vlink1. These are point-to-point interfaces that allow communicationbetween the root and services VDOMs. IP addresses are not required on these interfaces,but can help with troubleshooting routing issues (for example, when using traceroute).




P a g e | 29


01-50003-0301-20131018-D

10. A default route is required for the customer VDOM using the newly created inter-VDOM linkinterface.

Click Virtual Domains > customer > Router > Static > Static Route and create a new route

using the following details:

Destination IP/Mask: 0.0.0.0/0

Device: vlink1

Gateway: 10.10.100.1

11. A route for the internal network is required for the root VDOM using the newly created inter-VDOM link interface.

Go to Virtual Domains > root > Router > Static > Static Route. Create a new route using thefollowing details:


Device: vlink0

Gateway: 10.10.100.2

12. In the root VDOM create a Zone for port1 and port2. Go to Virtual Domains > root > System> Network > Interface. Click next to Create New and create a new Zone.

Assign a name of External and specify port1 and port2 as Interface Members.

13. A firewall policy must be created to allow traffic from the customer VDOM out to the Internetthrough the interfaces. Still in the root VDOM, go to Policy > Policy > Policy and create a

new policy for traffic to External with the following details:

Policy Type: Firewall

Policy Subtype: Address

Incoming Interface: vlink0

Source Address: all

Outgoing Interface: External

Destination Address: all

Schedule: always

Service: ALL

Action: ACCEPT

Enable NAT: enabled




P a g e | 30


01-50003-0301-20131018-D

14. Switch to the customer VDOM, create a second policy that allows traffic from the port3interface to the vlink1 interface with the following details:




Source Address: all

Outgoing Interface: vlink1


Schedule: always

Service: ALL

Action: ACCEPT

Enable NAT: Disabled

15. After that, you will need to reconfigure DNS forwarding on port3 . Still in the customer VDOM go to System > Network > DNS Server and configure DNS Service on Interface andconfigure port3 to forward to system DNS. Connect to an external web site and ensure thatthe count field of the firewall policy is incrementing on both the outgoing policy of thecustomer VDOM and the outgoing policy of the root VDOM.

16. From a DOS prompt on the Windows Server, run the following trace route command andverify the path over the inter-vdom link.

tracert –d 4.2.2.2

17. In a web browser on the Windows Server, log in to the customer VDOM (10.0.1.254) by

entering the customer-admin username and password in the login screen.

You can access the customer VDOM on port3 because it is a member interface of thatVDOM.

18. Navigate through the GUI and select the various menu items to see what the VDOMadministrator has the ability to control.

Since the customer-admin administrator has access to the customer VDOM only, they willnot automatically be placed into the Global Configuration, nor will they have access to it. Thedisplay of the GUI will change as the service-admin user has access to only the VDOMspecific objects. Logout from the customer VDOM.



Module 13 Lab 1: Transparent Mode VDOMs

P a g e | 31


01-50003-0301-20131018-D

The aim of this lab is for students to configure two transparent mode VDOMs and to enable UTMinspection to all traffic in the ‘root’ VDOM. An inter -vdom link will be used to inter-connect the twoVDOMs.

– Configure two transparent mode VDOMs

– Create and use VDOM objects




Module 13 Lab 1: Transparent Mode VDOMs Exercise 1

P a g e | 32


01-50003-0301-20131018-D



following configuration file: Resources\Module13\Student\Student-tp.conf


2. On the Student FortiGate device, go to System > Dashboard > Status and in the SystemInformation widget, click the Enable link for Virtual Domain.

You will be logged out of the FortiGate unit and will need to log back in again.

3. Once logged back into the Student FortiGate device, the GUI will automatically display theGlobal configuration.

4. Go to Global > VDOM > VDOM and click Create New to add new VDOM. Configure thefollowing settings:

Name: inspect

Enable: enabled

Operation Mode: Transparent

Management IP/Netmask: 10.200.1.200/24

Default Gateway: 10.200.1.254




P a g e | 33


01-50003-0301-20131018-D

1. Enter the following CLI commands to create an inter-vdom link:config global

config system vdom-link

edit link

set type ethernet

end

end

2. Next, configure the inter-vdom link interfaces, by entering the following CLI commands:

config global

config system interface

edit link0

set vdom root

set ip 10.200.1.1/24

set allowaccess ping ssh

next

edit link1

set vdom inspect

end

end

3. Go to Global > Network > Interface and review the inter-vdom link interfaces created above.Note that link0 and link1 are internal ethernet interfaces that allow communication betweenthe root and inspect VDOMs. An IP address is only configurable on the NAT/Route modevdom interface.

4. Go to the GUI and review the new VDOM tree display by selecting Virtual Domains andreviewing the root and inspect vdoms.

5. Next, you will move the port1 interface to the inspect VDOM. Go to Global > Network >Interface and edit the port1 interface. From the Virtual Domain drop-down list select theinspect VDOM. This is possible because the port1 interface is not referenced by any firewall

policies or routing. Also ensure that Ping access is enabled on port1.




P a g e | 34


01-50003-0301-20131018-D

6. Go to the inspect VDOM and create the following polices to allow traffic between the port1and link1 interfaces initiated in either direction:



Incoming Interface: any

Source Address: All

Outgoing Interface: any


Schedule: always

Service: ALL

Action: ACCEPT

From the Firewall Policy display of the inspect VDOM, right-click on the Security Profiles fieldand select the default Antivirus profile. A message will prompt you that this change has beensaved.

7. In the root VDOM go to Policy > Policy > Policy and create a new policy for port3 to link0 using the following settings. Note that you may create this policy by performing a copy andpaste of the existing outgoing policy and changing the outgoing interface.




Source Address: all

Outgoing Interface: link0


Schedule: always

Service: ALL

Action: ACCEPT

Enable NAT: enabled

Logging Options: Log all sessions




P a g e | 35


01-50003-0301-20131018-D

8. To direct traffic from your Windows host to the inspect VDOM, in the root VDOM, create anew static route pointing to the inter-vdom link using the following settings:


Device: link0

Gateway: 10.200.1.254

Click OK .

Increase the cost of the priority of the port2 default route to 5 , so that this is not the preferredroute.

Test by running a tracert –d 10.200.3.1 from your Windows Server and check that

your hops are 10.0.1.254 and 10.200.1.254.

Run a continuous ping to 10.200.1.254.

9. Download the Eicar virus test file from the web site:

http://eicar.org.

Check for a traffic log message in the root VDOM and a UTM message in the inspect VDOM.

10. From the GUI on the Student FortiGate device, go to Global > Dashboard. Click Dashboard

in the top left-hand corner of the page and then click Add Dashboard . Add a new singlewidth dashboard with the name of your choice.

11. Click +Widget and add the Top Sessions widget. Edit the widget and set Report by: to All .Edit the column settings and add Virtual Domain. Check that there is a session reported ineach VDOM.



Module 14 Lab 1: High Availability

P a g e | 36


01-50003-0301-20131018-D

The aim of this lab is to set up a high availability cluster configuration using FortiGate devices in thestudent environment. Different HA modes will be used to set up various HA configurations andstudents use diagnostics and debug commands to observe HA functionality and behavior on theFortiGate unit.

– Set up an HA cluster using FortiGate devices in the student environment

– Execute and interpret diagnostic output

– Test HA synchronization and failover




Module 14 Lab 1: High Availability HA Lab Topology

P a g e | 37


01-50003-0301-20131018-D

The virtual lab environment has been wired to allow an HA cluster to be configured using theexisting devices as shown in the following network diagram.



Module 14 Lab 1: High Availability Exercise 1

P a g e | 38


01-50003-0301-20131018-D

1. From the Windows Server, you first will need to connect to each FortiGate device and restorethe configuration files that are needed for this lab.


configuration file: Resources\Module14\Remote\remote-ha.conf.



following configuration file: Resources\Module14\Student\student-ha.conf.


2. Open the console on both the Student and Remote FortiGate devices. This allows you toobserve the standard error messages sent to the console which provide useful statusinformation, such as:

slave succeeded to sync external files with master

Wait 4 to 5 minutes for units to synchronize. You can check on the status by issuing the

command “diag sys ha showcsum” on both Student and Remote. Checksums will match

if units are in synch. In the sample config of the Remote FortiGate unit, the command should

read: set group-name training.

The Student FortiGate device configuration contains the following HA settings.

config system ha

set mode a-a

set priority 200

set group-name training

set password Fortinet

set session-pickup enable

set hbdev port2 50

end

The Remote FortiGate device configuration contains the following HA settings.

config system ha

set mode a-a

set priority 100

set group training

set password Fortinet

set session-pickup enable

set hbdev port2 50

end




P a g e | 39


01-50003-0301-20131018-D

3. To verify if the cluster has been established, enter the following CLI command:

get system status

View the Current HA mode line. You should observe that the Student FortiGate unit is a-amaster , and the Remote FortiGate device is a-a backup.

Connect to the GUI of the cluster (10.0.1.254) and go to System > Config > HA to see

status information of the cluster members.

4. Next you will test the session sync. To do this load a few pages from several web sites andfrom the CLI look at the session table entries of both the Student and Remote FortiGatedevices using the following CLI commands:

diag sys session filter dport 80


From the CLI enter the command:

diag sys session stat

If you are using SSH/Telnet instead of the console, use the following command to access theslave CLI from the master,

execute ha manage <id> (use ? to list the id values)

exit (to return to master)

You should observe that the session count is greater on the master device than on thebackup device. The reason for this is because all management traffic goes to and from themaster and all non-TCP traffic is handled by the master. By default, only TCP sessionsdestined for proxy inspection are load balanced between the master and backup units.

5. To test fail-over, view a long YouTube video and at the same time run a continuous ping to apublic IP address.

To simulate a failover, reboot the Student FortiGate device by entering the command:

execute reboot

6. Because of the failover condition, the Remote FortiGate device is now master . Check thisfrom the CLI as follows:

get sys stat




P a g e | 40


01-50003-0301-20131018-D

7. Check the HA status of the Student FortiGate device when it returns to the cluster. Does it

rejoin as backup or as master ? You can use the command diag sys ha status to see

all cluster members.

You should observe the device joins as slave and not master.

From the Remote FortiGate device, execute the following command to make the StudentFortiGate device become master again:

diagnose sys ha reset-uptime

By resetting the HA uptime it forces the cluster to use the next value to determine the masterwhich is the unit priority, You should observe that the Student FortiGate device is nowmaster . Check the system uptime to see that this remains unchaged, it is the HA uptime that

is reset, get sys perf status.

8. The following is for information purposes only and gives some insight into the ha-syncprocess, which is the process responsible for the FGCP packets that communicate cluster

status and build the cluster.

On the Student FortiGate device enter:

diag debug enable

diag debug application ha-sync 255

On the Remote FortiGate device enter:

execute reboot

On the Student FortiGate device observe the debug output as the slave reboots and startscommunicating with the cluster.

9. Important: Before proceeding to the next lab, connect to https://10.0.1.254 and go toSystem > Config > HA and for the REMOTE device click the Disconnect from cluster icon toremove it as an HA cluster member.

When prompted,configure port3 with the IP address 10.0.1.251/24 and allow HTTP

access.

STUDENT # execute ha disconnect FGVM010000006759 port3 10.0.1.251 255.255.255.0Sending cmd to HA member 0



Module 15 Lab 1: Advanced IPSec VPN

P a g e | 41


01-50003-0301-20131018-D

The aim of this lab is for students to work with some of the more advanced capabilities of IPSecVPNs. Students configure advanced VPN settings used in hub-spoke and partial meshedconfigurations.

− Students use debugging and diagnostics commands to observe IPSec VPN traffic and events

− Dynamic routing protocols will be introduced to demonstrate a redundant VPN path and failover




Module 15 Lab 1: Advanced IPSec VPN Exercise 1

P a g e | 42


01-50003-0301-20131018-D

You will now configure a site-to-site tunnel between Student port1 and Remote port4. In thisexample use interface based IPsec. In a later exercise, you will configure an IP address on thisIPsec interface in order to configure dynamic routing.

Below are the settings to configure the Student FortiGate device. Once you have completed thesesteps, you will then need to configure the Remote FortiGate device. Note that the steps for this areintentionally not provided since the objective of this exercise is for the student to determine thecorrect settings on their own, based on the Student device settings that are given. You can also usethe network diagram (located at the beginning of this lab guide) for additional guidance.


Connect to the GUI on the Remote FortiGate (10.200.3.1) and restore the followingconfiguration file: Resources\Module15\Remote\remote-ipsec2.conf.



following configuration file: Resources\Module15\Student\student-ipsec2.conf.


2. From the GUI on the Student FortiGate Device, go to VPN > IPsec > AutoKey (IKE) and create a new Phase 1 for an IPSec VPN as follows:

Name: Remote_1

Remote Gateway: Static IP Address

IP Address: 10.200.3.1

Local Interface: port1

Mode: Main

Authentication Method: Preshared Key

Pre-shared Key: fortinet

Click Advanced and set the following:

Enable IPSec Interface Mode: Enabled

P1 Proposal

1-Encryption: AES256

Authentication: SHA1

DH Group:: 5

XAuth Disabled

Dead Peer Detection: Enabled

Leave other fields at their default value.




P a g e | 43


01-50003-0301-20131018-D

3. Create a new Phase 2 for the VPN as follows:

Name: P2_Remote_1

Phase 1: Remote_1 (the name assigned to Phase 1 above)

Click Advanced and set the following:

P2 Proposal

1-Encryption: AES256

Authentication: SHA1

Enable replay detection: Enable

Enable perfect forward secrecy: Enable

DH Group: 5

Autokey Keep Alive: Enable

4. Go to Router > Static > Static Route and create a new static route for the IPSec VPN with thefollowing details:


Device: Remote_1

5. Go to System > Network > Interface, and create a new zone with the following settings:

Zone Name: VPN

Interface Members: Remote_1

6. Create two firewall policies between port3 and VPN in both directions with the followingdetails:




Source Address: STUDENT_INTERNAL

Outgoing Interface: VPN

Destination Address: REMOTE_INTERNAL

Schedule: always

Service: ALL

Action: ACCEPT




P a g e | 44


01-50003-0301-20131018-D



Incoming Interface: VPN

Source Address: REMOTE_INTERNAL


Destination Address: STUDENT_INTERNAL

Schedule: always

Service: ALL

Action: ACCEPT

7. Repeat the configuration on the Remote FortiGate device using the above settings and thenetwork diagram for guidance.

Use the name Student_1 for the Phase 1 object on port4 on the Remote FortiGate device.

Use the name P2_Student_1 for the Phase 2 object on the Remote FortiGate device.

The route associated with this interface is to 10.0.1.0/24, the internal network of the

Student FortiGate device.

8. Create the VPN zone and incoming and outgoing firewall policies.



Module 15 Lab 1: Advanced IPSec VPN VPN Connection Troubleshooting

P a g e | 45


01-50003-0301-20131018-D

1. From a command prompt on the Windows Server confirm that you can successfully ping thefollowing IP addresses in the Remote environment:

ping 10.0.2.10

ping 10.0.2.254

2. From the Student FortiGate device, enter the following CLI command. This sets the pingoptions for the FortiGate unit to ping from the port3 interface:

exec ping-options source 10.0.1.254

3. From the Student FortiGate device, enter the following CLI command to ping the Remote environment through the VPN set up on the Student FortiGate unit:

exec ping 10.0.2.254

4. From the GUI on the Student FortiGate device go to VPN > Monitor > IPSec Monitor.

Confirm that the Remote_1 IPSec VPN is UP . A green arrow should be displayed in theStatus column for the connection.

Troubleshooting will be required if the Status column displays a red arrow or the VPNconnects but ping traffic cannot be passed through the connection.

Any connectivity issues should be fixed before continuing. If the IPSec VPN connection is down,review all settings and re-enter the pre-shared keys.

1. Can the Remote gateway address be pinged? (This is the IP address of the externalinterface on the Remote FortiGate device.)

Can the Remote device ping the gateway address of the Student device?

If each other’s external addresses cannot be pinged in the clear (and ping is enabled on theinterfaces), then basic connectivity for the VPN has not been established.

Note: Be sure to force the pings out to the correct interface. This may meanshortening the distance value that was configured on the static route being tested.

Can ping be used successfully from the Student FortiGate device to the external interface onthe Remote FortiGate device? Clear the ping-options settings first.

exec ping 10.200.3.1

Can the Remote device ping the Student FortiGate unit?



Module 15 Lab 1: Advanced IPSec VPN VPN Connection Troubleshooting

P a g e | 46


01-50003-0301-20131018-D

2. If the VPN still does not connect, use the following debug commands on one side of the VPN,for example on the Student FortiGate device:

diag debug enable

diag vpn ike log-filter dst-addr4 10.200.3.1

diag debug app ike -1

Examine the output. It can usually direct to the point of failure.

To turn off the debug enter the following command (keep on typing right through the scrollingoutput):

diag debug reset

3. On the Remote FortiGate device (10.0.1.254) , attempt to send traffic. You can either usea continuous ping to the internal interface or click the up arrow on the VPN Monitor.

4. If the tunnel is connected but not forwarding traffic, the issue may with the zones, routes, orpolicies.

Verify that the virtual interfaces are listed as part of the zone.

Verify the static route and confirm that it is listed in the routing monitor.

Verify that there are two firewall policies and that they are to and from the IPSec interface( and )

Verify that the ping is leaving the interface. Run the following command on the sendingFortiGate unit:

diag sniff packet port1 icmp

Verify that the ping is arriving at the interface. Run the following command on the receivingFortiGate unit:

diag sniff packet port1 icmp

Alternately, you can use diag debug flow.

Speak with your instructor for further guidance if these steps do not help resolve the issue.




P a g e | 47


01-50003-0301-20131018-D

In this exercise, a second route-based VPN will be created from port2

port5 .

1. Repeat the configuration steps of exercise 1, this time the VPN is from Student FortiGateport2 to Remote FortiGate port 5

Use the name Remote_2 for the Phase 1 object on port2 on the Student FortiGate device

Use the name P2_Remote_2 for the Phase 2 object on the Student FortiGate device

Use the name Student_2 for the Phase 1 object on port5 on the Remote FortiGate device

Use the name P2_Student_2 for the Phase 2 object on the Remote FortiGate device

2. Add a second route to the remote network. This time using the second IPSec interface andusing a higher distance of 20 .

3. Add the new IPSec interfaces to the zone VPN and enable intra-zone traffic.




P a g e | 48


01-50003-0301-20131018-D

1. From the IPsec Monitor bring up the second tunnel.

2. From the DOS prompt on the Windows Server run continuous pings toIP addresses in theRemote environment can be successfully pinged:

ping –t 10.0.2.10

ping –t 10.0.2.254

3. To test the VPN fail-over, in the root VDOM on the Student FortiGate device, go to System >Network > Interface and edit port1. Set the Administrative Status to DOWN, alternatively usethe example in the note below.

Note: When changing the administrative status of an interface, affected sessionswill not fail back when the primary path is brought back up.

Alternatively, an upstream device failure can be simulated by executing thefollowing command from a command prompt on the LINUX host:ifconfig eth3 down

(To access the LINUX device, use PuTTY to connect using SSH to10.200.1.254.

Log in with the username of root and the password of password .)

This will create a more realistic failure and will require DPD and DGD to detect thefailure.

Also when the primary path is brought back up using the following command, theaffected sessions will fail back:

ifconfig eth3 up

4. Enter the following commands from the CLI on the Student FortiGate device to observe thesession fail-over:

diag sys session filter dst 10.0.2.10





P a g e | 49


01-50003-0301-20131018-D

Sample output:

session info: proto=1 proto_state=00 duration=401 expire=59 timeout=0flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3

origin-shaper=

reply-shaper=

per_ip_shaper=

ha_id=0 policy_dir=0 tunnel=Remote_2/

state=may_dirty

statistic(bytes/packets/allow_err): org=16020/267/1 reply=14220/237/1tuples=2

orgin->sink: org pre->post, reply pre->post dev=4->18/18->4

gwy=10.0.2.10/10.0.1.10hook=pre dir=org act=noop 10.0.1.10:768->10.0.2.10:8(0.0.0.0:0)

hook=post dir=reply act=noop 10.0.2.10:768->10.0.1.10:0(0.0.0.0:0)


serial=00000231 tos=ff/ff ips_view=0 app_list=0 app=0

dd_type=0 dd_mode=0

per_ip_bandwidth meter: addr=10.0.1.10, bps=762

total session 1

Observe in the above output that the interface pair used for traffic ingress and egress willupdate to reflect the VPN failover. For example, the value dev=4->17/17->4 will change to

reflect the new interface pair.

In order to see the name to number mapping, locate the ifindex value in the output of thefollowing CLI command:

diag netlink interface list

5. Important: Before proceeding, change the Administrative Status of the port1 interface on theStudent FortiGate device back to UP .




P a g e | 50


01-50003-0301-20131018-D

1. On the Student FortiGate device, go to Router > Static > Static Route and increase the

distance for Remote_1 from 10 to 210 and the distance for Remote_ 2 from 20 to 220.Repeat this on the Remote FortiGate device.

From the CLI use get router info routing-table all to check the change to the

distance for the IPsec interface routes.

2. On the Student FortiGate device, go to System > Network > Interface and edit each of theIPSec interfaces in the VPN zone to add the Local IP and Remote IP address values fromthe chart below:

Interface Names IP Remote IP

Remote_1 172.16.1.1 172.16.2.1Remote_2 172.16.1.2 172.16.2.2

3. On the Student FortiGate device, go to Router > Dynamic > OSPF .

Enter the Router ID of 0.0.0.1. Click Apply before continuing.

Areas

Click Create New to define an area with an IP address of 0.0.0.0. Accept the defaults for

the remaining parameters.

NetworksClick Create New to define the internal subnet for the OSPF networks. Set the IP/Netmask

value to 10.0.1.0/24. Leave the Area value as the default of 0.0.0.0.

Repeat this step to add the IPSec interface subnet of 172.16.0.0/12.

InterfacesClick Create New to create new OSPF interfaces for the two IPSec interfaces with the valuesfrom the chart below:

Interface Names Interface IP COST

R1_OSPF Remote_1 172.16.1.1 10

R2_OSPF Remote_2 172.16.1.2 20

Accept the defaults for the remaining parameters.




P a g e | 51


01-50003-0301-20131018-D

4. To make the VPNs redundant, the cost of the redundant VPN routes must be lowered (thedefault cost is 1500) by typing the following CLI commands from the root VDOM:

config router ospf

config ospf-interface

edit R1_OSPF

set mtu 1436

next

edit R2_OSPF

set mtu 1436

next

end

end

5. Repeat all the previous steps of this exercise for the Remote FortiGate device.

For the OSPF configuration (Router > Dynamic > OSPF ) on the Remote FortiGate device,

enter the Router ID of 0.0.0.2. Click Apply before continuing

Use the following values for the IPSec interface addresses:

Interface Names IP Remote IP

Student_1 172.16.2.1 172.16.1.1

Student_2 172.16.2.2 172.16.1.2

Use the following values for the OSPF configuration:

Areas

Click Create New to define an area with an IP address of 0.0.0.0. Accept the defaults for

the remaining parameters.

NetworksClick Create New to define the internal subnet for the OSPF networks. Set the IP/Netmask

value to 10.0.2.0/24. Leave the Area value as the default of 0.0.0.0.

Repeat this step to add the IPSec interface subnet of 172.16.0.0/12.

InterfacesClick Create New to create new OSPF interfaces for the two IPSec interfaces with the valuesfrom the chart below:

Interface Names Interface IP Cost

S1_OSPF Student_1 172.16.2.1 10

S2_OSPF Student_2 172.16.2.2 20




P a g e | 52


01-50003-0301-20131018-D

6. Next enter the following CLI commands:

config router ospf

config ospf-interfaceedit S1_OSPF

set mtu 1436

next

edit S2_OSPF

set mtu 1436

next

end

end




P a g e | 53


01-50003-0301-20131018-D

In this exercise, you will run the commands given from the Student FortiGate device, however notethat they can also be used on the Remote FortiGate device with equal effect.

1. At this point each student should have two active tunnels. On the Student FortiGate device,go to VPN > Monitor > IPSec Monitor and verify that the status of the displayed tunnels is UP.

The IPSec VPNs can also be viewed using the following CLI command:

diag vpn tunnel list

2. After a few minutes, the OSPF routes should appear in Router > Monitor > Routing Monitor .The OSPF routes can also be viewed using the following CLI command :

get router info routing-table ospf

3. Check the OSPF adjacencies and LSAs in the routing table by typing the following CLIcommand:

get router info ospf neighbor

Sample output:

OSPF process 0:

Neighbor ID Pri State Dead Time Address Interface

0.0.0.2 1 Full/- 00:00:34 172.16.2.1 Remote_1

0.0.0.2 1 Full/- 00:00:36 172.16.2.2 Remote_2

4. Type the following CLI command to display all the learned networks:

get router info ospf database router lsa

5. Type the following CLI command to display all the routes learned by OSPF


Sample output:

0 10.0.2.0/24 [110/11] via 172.16.2.1, Remote_1, 00:00:14

6. From the DOS prompt on the Windows Server confirm that the following IP addresses in theRemote environment can be successfully pinged:

ping 10.0.2.10

ping 10.0.2.254

7. On the Student FortiGate device, set the administrative status for the port1 interface to

DOWN (or from the Linux host enter: ifconfig eth3 down). This will cause a new path to

be selected.




P a g e | 54


01-50003-0301-20131018-D

8. Check the session failover display for all the routes learned by OSPF by running thefollowing from the CLI:


Sample output:

0 10.0.2.0/24 [110/11] via 172.16.2.2, Remote_2, 00:00:14

9. Clear any active filters with the following CLI command:

diag sys session filter clear

10. Define a new filter with the following command:

diag sys session filter dst 10.0.2.10

11. Run the following command to display the matching sessions:diag sys session list

Sample output:

session info: proto=1 proto_state=00 duration=15 expire=56 timeout=0flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4

origin-shaper=

reply-shaper=

per_ip_shaper=

ha_id=0 hakey=788

policy_dir=0 tunnel=Remote_2/

state=may_dirty rem

statistic(bytes/packets/allow_err): org=240/4/1 reply=120/2/1tuples=2

orgin->sink: org pre->post, reply pre->post dev=4->18/18->4gwy=172.16.2.2/10.0.1.10

hook=pre dir=org act=noop 10.0.1.10:768->10.0.2.10:8(0.0.0.0:0)

hook=post dir=reply act=noop 10.0.2.10:768->10.0.1.10:0(0.0.0.0:0)


serial=000073d6 tos=ff/ff ips_view=0 app_list=0 app=0

dd_type=0 dd_rule_id=0

per_ip_bandwidth meter: addr=10.0.1.10, bps=27169

total session 1

12. Important: Before proceeding, change the administrative status for the port1 interface on the

Student FortiGate device back to UP (or from the Linux host enter : ifconfig eth3

down).




P a g e | 55


01-50003-0301-20131018-D

1. For faster failover, BFD can be implemented. Enable BFD by entering the following CLIcommands on the Student FortiGate device:

config sys settings

set bfd enable

end

2. Enable BFD on the IPSec interfaces by entering the following CLI commands:

config sys interface

edit Remote_1

set bfd enable

next

edit Remote_2

set bfd enable

next

end

3. Enable BFD on the OSPF interfaces, by entering the following CLI commands:

config router ospf

set bfd enable

config ospf-interface

edit R1_OSPF

set bfd enable

next

edit R2_OSPF

set bfd enable

end

end




P a g e | 56


01-50003-0301-20131018-D

4. Repeat the previous steps of this exercise on the Remote FortiGate device.

5. To display the BFD neighbors, enter the following CLI command in the roo t VDOM:

get router info bfd neighbor

There should be two BFD neighbors with a status of UP .

6. Test failover and failback by running continuous pings. You should observer fewer pingfailures with this protocol enabled.



Module 15 Lab 2: IPSec VPN with FortiClient Exercise 1

P a g e | 57


01-50003-0301-20131018-D

In this lab, an IPSec VPN will be created between the Student FortiGate unit and the FortiClientinstallation on a Windows XP host in the Remote environment.

− Configure an IPSec VPN between the Student FortiGate unit and FortiClient Connect





P a g e | 58


01-50003-0301-20131018-D



following configuration file: Resources\Module15\Student\student-ipsec3.conf.



configuration file: Resources\Module15\Remote\remote-ipsec3.conf.


2. On the Student FortiGate device, go to VPN > IPSec > Auto Key (IKE) and click Create FortiClient VPN .

Configure a new FortiClient VPN using the following details:

Name: FClient

Local Outgoing Interface: port1

Authenticated Method: Pre-shared Key

Pre-Shared Key: fortinet

User Group: training

Address Range Start IP: 172.20.1.1

Address Range End IP: 172.20.1.5

Subnet Mask: 255.255.255.0

Enable IPv4 Split Tunnel: STUDENT_INTERNAL

DNS Server: Use System DNS

Create the following Firewall Address object for the VPN clients:

Address Name: VPN-CLIENTS

Type: IP Range

Subnet/IP Range: 172.20.1.1-172.20.1.5

Interface: FClient




P a g e | 59


01-50003-0301-20131018-D

3. On the Student FortiGate device, go to Policy > Policy > Policy and create a FClient port3policy to allow inbound connections with the following details:



Incoming Interface: FClient

Source Address: VPN-CLIENTS


Destination Address: STUDENT_INTERNAL

Schedule: always

Service: ALL

Action: ACCEPT

4. Create a port3 FClient policy to allow outbound connections with the following details:




Source Address: STUDENT_INTERNAL

Outgoing Interface: FClient

Destination Address: VPN-CLIENTS

Schedule: always

Service: ALL

Action: ACCEPT

5. Go to Router > Static > Static Route and create a new static route with the following details:


Device: FClient




P a g e | 60


01-50003-0301-20131018-D

1. Connect to the console of the external Windows host. (In the virtual lab applet, go toOperations > Connect to Secondary > WinXP . The virtual Windows XP device desktop willbe displayed.)

2. In the FortiClient console, go to Remote Access and Configure VPN.

3. Add a new configuration with the following details:

Configuration Name: FC_VPN

Type IPSec VPN

Description: Student FortiGate

Remote Gateway: 10.200.1.1

Authentication Method: Preshared Key

Preshared Key: fortinet

Authentication (XAuth): Save Login

Username: student




P a g e | 61


01-50003-0301-20131018-D

1. In Remote Access of the FortiClient console, select the FC_VPN, enter the password‘F0rtinet’ for student and click Connect .

If using the hosted virtual lab the connection to the host console is affected by the routingchange: In the virtual lab applet in the WinXP image, go to Operations > Disconnect . After afew moments, return to the Operations menu and click Connect to Secondary > WinXP toreturn to the Windows XP device.

2. Within a few moments, the external Windows host device should receive an IP addresswithin the 172.20.1.1 - 172.20.1.5 range identified on the DHCP server on the

FortiGate unit at the other end of the IPSec VPN tunnel. Use the following command in theDOS Command Prompt on the Windows host device to confirm this:

ipconfig /all

3. Enter the following command in the DOS Command Prompt on the Windows host to displaythe routing table information.

route print

Locate the 10.0.1.0/24 network entry in the output.

4. From the Windows host, attempt to ping both the Windows Server (10.0.1.10) and the

port3 interface of the FortiGate device (10.0.1.254).

5. Return to the Windows Server device and attempt to ping the virtual Windows host running

FortiClient (172.20.1.1).

6. On the Student FortiGate device go to Router > Monitor > Routing Monitor and locate thestatic route for the FortiClient installation on the external Windows host.

7. Next go to VPN > Monitor > IPSec Monitor to view the details of the FClient-0 VPNconnection.

Alternately use the following CLI command in the root VDOM:

diag vpn tunnel list

8. On the Student FortiGate device, go to VPN > Monitor > IPSec Monitor . Note the Proxy IDDestination. On the external Windows host go to the IPSec VPN Connections window of the

FortiClient C onnect console and click Disconnect .



Module 16 Lab 1: Intrusion Prevention System

P a g e | 62


01-50003-0301-20131018-D

The aim of this lab is for students to set up DoS policies and IPS profiles on their FortiGate devices.Packet crafter software will be used to attempt to flood one of the FortiGate units and the resultinglog entries will be examined on both units.

– Configure DoS policies and IPS profiles

– Read and interpret Attack log entries

– Execute diagnostics commands and interpret output




Module 16 Lab 1: Intrusion Prevention System Exercise 1

P a g e | 63


01-50003-0301-20131018-D



following configuration file: Resources\Module16\Student\student-ips.conf


2. On the Student FortiGate device, go to Security Profiles > Intrusion Protection > IPSSignatures to view the installed signatures. Click the signature name link to view moreinformation about the signature from the Fortinet web site.

Protocol decoders are used as part of signature matching. HTTP decoder ports areautomatically detected; IPS detects HTTP at the application layer and does not rely on the

TCP port number.

3. Next go to Security Profiles > Intrusion Protection > IPS Sensor and click the plus sign (+) inthe upper-right corner of the Edit IPS Sensor window to create a new sensor. Set the Namefor the new sensor to LINUX_SERVER and click OK .

4. In the Edit IPS Sensor window, click Create New and configure a new IPS filter with thefollowing settings:

Sensor Type: Filter Based

Severity: All

Target: server

OS: Linux

Action: Signature Defaults

Packet Logging: Enabled

5. On the Student FortiGate device, edit the “ALL” services port3 port1 firewall policy. UnderSecurity Profiles, set IPS to ON and select LINUX_SERVER from the drop-down list.

6. From a command prompt on the virtual Windows Server, change directory to the Resources\Module16\nikto-2.1.5 folder as follows:

C:> cd \

C:> cd Documents and Settings\Administrator\Desktop\\Module16\nikto-2.1.5

7. Next run the following command:

nikto.pl -host 10.200.1.254

The test will stop by itself once it has finished.You can use CTRL+C to stop the utility.




P a g e | 64


01-50003-0301-20131018-D

8. On the Student FortiGate device, go to Log & Report > Security Log > Intrusion Protectionand locate the multiple entries for the attacks generated by the nikto utility.

If the exploits are not logged, verify the following items:

Is the LINUX_SERVER IPS sensor selected in the policy?

Is the traffic matching the correct policy?

If none of these items apply, please discuss this further with your instructor.

9. In the log display window, right-click any of the column titles to display Column Settings andadd the Status field to the display. Move this column accordingly for easier viewing.

Look at the Status field of the log entries and note that for some of the attacks discovered bythis sensor, the Status value appears as detected . This indicates that a signature wasmatched and that the traffic was allowed to pass.

In the spaces below, record the names for two of the detected signatures. The signaturename appears in the Message column of the log.

Signature 1: ____________________________________

Signature 2: ____________________________________

10. You will now modify the IPS sensor and change the action for these two signatures to Block .Go to UTM Security Profiles > Intrusion Protection > IPS Sensor and edit theLINUX_SERVER sensor.

Create a new filter and set the Type to Specify Signatures. Click in the search field located

on the left-hand side of the window (close to the top) and enter the name the first signatureidentified in the previous step.

Select the signature.

Set the Action to Block All and enable Packet Logging.

Repeat this procedure for the second signature name recorded earlier.

11. Move the newly created signatures before the Default filter in the IPS filter list using drag &drop.

12. From a command prompt on the Windows Server, run the vulnerability scan again by

executing the following command::

nikto.pl -host 10.200.1.254

13. Now examine the log entries again. Go to Log & Report > Security Log > Intrusion Protection and locate the log messages which should indicate that the attacks were blocked. The Status field should indicate a status of dropped which includes any of the following actions:dropped packet, dropped session or cleared session.




P a g e | 65


01-50003-0301-20131018-D

In this exercise, DoS policies will be used to test basic flood protection on the network.

1. On the Student FortiGate device, go to Policy > Policy > DoS Policy and edit the displayedDoS policy. Configure the following settings:


Source Address: all


Service: ALL

Anomalies:

Status

Logging

Action:

set the Threshold for icmp_flood to 200.

enable

enable

Block

2. Open an SSH connection and login to the Linux host. Enter the username root with apassword of password .

Run the ping command with the flood option against the external server using the following

syntax:

ping -f 10.200.1.200

The command options used here will cause the ping utility to run continuously and not waitfor replies between ICMP echo requests.

Some pings will be blocked as the packets per second exceed the configured threshold. Theperiods displayed from the ping utility represent packet loss because there was no response.

Leave this window open with the ping test still running.

3. Go to Log & Report > Security Log > Intrusion Protection and examine the logs. Note that theICMP flood has been blocked; this is indicated by the Status field entry clear_session.




P a g e | 66


01-50003-0301-20131018-D

4. From the CLI on the Student FortiGate device, run the following diag command to verify thecurrent counter thresholds :

diagnose ips anomaly list

Sample output:

list nids meter:

id=icmp_flood ip=10.200.1.254 dos_id=1001 exp=932 pps=21 freq=20

total # of nids meters: 1.

5. To demonstrate policy ordering we will now create a second DoS policy that allows thepreviously blocked traffic. This time, the Service parameter will be set to ICMP to make thispolicy more specialized than the first one you created.

Go to Policy > Policy > DoS Policy and click Create New . Configure the following settings:


Source Address: all


Service: ALL_ICMP

Anomalies:

Status

Logging

Action:

set the Threshold for icmp_flood to 200.

enable

enable

Pass

6. Return to the window running an SSH connection to the Linux host.You should observe that the result is the same as before. Excess traffic is being blocked atthe same frequency. Examine the logs and note the same attack log message as before.

7. From the CLI examine the anomaly counters using the following command:


Sample output:

list nids meter:



The PPS stops at the same value, since the more specific DoS sensor is applied after thegeneral sensor.

8. Use drag & drop to re-order the DOS policies so that the ALL_ICMP policy with the actionPass is first.




P a g e | 67


01-50003-0301-20131018-D

9. Ensure the ping test is still running and examine the anomaly counters again as follows:


Sample output:

list nids meter:



Note that pings are no longer blocked at the same rate and the anomaly counters for thePPS are much higher than the previous value but less than the configured threshold; thetraffic is allowed. You can also observe this from the logs. The entries will appear similar tothe following. Modify the Column-Settings to list the Sensor field. This displays the sensorthat was applied. You should also observe that the periods have stopped printing on theconsole as the packets are no longer dropped.

This test uses a simple example of ICMP. When enabling DoS protection in your network, becareful not to block traffic from servers that generate high amounts of traffic, such as DNS,mail, or web proxy. By creating different sensors with different thresholds, DoS protection canbe optimized for any network.




P a g e | 68


01-50003-0301-20131018-D

The custom signature created in this exercise will detect the RETR (GET) command on the FTPcontrol session in the direction of the server and generate an attack log event.

1. On the Student FortiGate device, go to Security Profiles > Intrusion Protection > IPSSignatures and click Create New . Enter the name ftp_get for the new custom signature andtype the following string in the Signature field:

F-SBID( --protocol tcp; --dst_port 21; --flow from_client; --pattern RETR;)

2. On the Student FortiGate device, go to UTM Security Profiles > Intrusion Protection > IPSSensor and edit the LINUX_SERVER sensor created earlier. Create a new filter and set theSensor Type to Specify Signatures. Click the ftp_get signature created in the previous stepand set the Action to Reset and enable Packet Logging .

Move this filter to the top of the list.

3. On the Student FortiGate device, enter the following CLI command to trace the session:

diagnose sniffer packet any ‘port 21’ 4

4. From a command prompt on the Windows Server, open a connection to the FTP server listedbelow. Log in as an anonymous user:

10.200.1.254

Change to the /pub folder and use the GET command to retrieve the file called test.text .For example, in a command prompt window enter the following commands:

ftp

open 10.200.1.254

<Enter the username of anonymous with a blank password when prompted>

ftp> cd pub

ftp> get test.text

5. The connection to the remote host should be closed.

In the CLI, examine the trace output to verify that the reset action was applied to the session.You should see a TCP reset sent out to the client on port3 and the server on port1.

Alternately, On the Student FortiGate device go to Log & Report > Security Log > IntrusionProtection, and locate the attack log entry to verify that the reset action taken as shownbelow:



Module 17 Lab 1: Fortinet Single Sign On

P a g e | 69


01-50003-0301-20131018-D

In this lab, Fortinet Single Sign On will be configured to allow the FortiGate unit to collectauthentication information from Windows Active Directory. Once a user logs into a Windows domain,they will not be required to perform any further authentication operations to access protected webresources.

− Install software on Windows systems

− Identify the differences between Normal and Polling mode operation

− Understand communications (mechanics, ports etc.)

− Configure groups

− Enable and utilize NLTM

− Monitor, Diagnose and Troubleshoot FSSO




Module 17 Lab 1: Fortinet Single Sign On Exercise 1

P a g e | 70


01-50003-0301-20131018-D



following configuration file: Resources\Module17\Student\Student-sso.conf


2. On the Windows Server, double-click the Fortinet Single Sign On installation file located inResources\Module17 , and click Run to launch the Fortinet Single Sign On Agent InstallationWizard .

Proceed though the wizard to install the agent on the Windows Server.

3. When prompted for the Windows Server Administrator account password to use to run theservice, enter password . Click Next .

4. In the Install Options window, accept the default settings and click Next .

5. Click Install to complete the installation.

6. At the end of the Single Sign On Agent installation, the Launch DC Agent Install Wizard option will be selected.

Click Finish to complete the Single Sign On Agent Installation. This launches the DomainController Agent Installation Wizard .

7. In the Install DC Agent Wizard , accept the Collector Agent IP Address of 10.0.1.10 and theCollector Agent Listening Port of 8002.

Click Next .

8. Select the TRAININGAD:trainingAD.training.lab domain to monitor. Click Next .

9. Only the student account needs to be monitored in this exercise. Expand the TRAININGAD domain and disable all the users in the TRAININGAD domain EXCEPT for student . ClickNext .

10. Set the Working Mode to Polling Mode and Check Windows Security Event Logs. Click Next.




P a g e | 71


01-50003-0301-20131018-D

11. In the virtual Windows Server, click Start > All Programs > Fortinet > Fortinet Single Sign On Agent > Configure Fortinet Single Sign On Agent .

Perform the following tasks in the Fortinet Single Sign On Agent Configuration window:

Change the Require authenticated connection from FortiGate password to fortinet.

Click Show Monitored DCs to verify communication between the Collector Agent and

Domain Controller Agent. The IP address of 10.0.1.10 should show as being logged in.

Click Close.

Click Select Domains to Monitor and verify the TRAININGAD:trainingAD.training.labdomain is selected. Click OK.

Click Set Group Filters. Click Add and enable the Default filter. Click Advanced andexpand the domain name of TRAININGAD. From the expanded list select the check boxfor Users. Click Add , then OK and OK .

12. Click Save&close to close the Fortinet Single Sign On Agent Configuration window.




P a g e | 72


01-50003-0301-20131018-D

1. On the Student FortiGate device, go to User & Device > Authentication > Single Sign-On andcreate a new entry with the following settings:

Type:

Name:

Fortinet Single-Sign-on Agent

TrainingDomain

Primary Agent IP/Name: 10.0.1.10

Password: fortinet

Click Apply & Refresh, you should observe that the ‘trainingad/users’ group is displayed.

2. Enter the following CLI commands to monitor communications between the FSSO Collector

Agent and the FortiGate unit:diag debug en

diag debug application auth 8256

Return to this output after you have tested the configuration.

3. On the Student FortiGate device, go to User & Device > User > User Group and create anew user group with the following details:

Name: Training

Type: Fortinet Single Sign On (FSSO)

Add TRAININGAD/USERS as members to the group.

4. Edit the port3 port1 firewall policy for ANY and set the Policy Subtype to User Identity .

Create a new authentication rule using the following settings:

Destination Address: All

Group(s): Training

Schedule: Always

Service: ALL

Log Options: Log Security Events




P a g e | 73


01-50003-0301-20131018-D

1. On the Windows Server, click Start > Run and enter the program name of mstsc.exe tolaunch Windows Remote Desktop.

2. Enter the remote computer IP address of 10.0.1.10 and log in with the following

credentials:

Username: student

Password: Fort1net

3. From a web browser on the Windows Server, attempt to connect to a web site. You shouldbe able to access the web site without being prompted for user authentication.

4. Observe the output from the diag command still running in the CLI.

5. Type the CLI commands shown below to display which users re currently logged on usingFSSO:

diag debug application auth 0

diag debug authd fsso list

Review the debug output. Note that you may see two IP address for user ‘student’ becausethis host has two NICs.



Module 18 Lab 1: Certificate Operations

P a g e | 74


01-50003-0301-20131018-D

The aim of this lab is for students to lay the ground work for all SSL-based inspection that aFortiGate unit is capable of performing. Students learn the details of how inspection is performedand the encryption functions used. In addition, the certificate is examined to understand its generallayout and contents.

− Create different certificate signing requests (CSRs)

− Use OpenSSL for certification signing requests

− Load signed certificates into the FortiGate unit and configure them for various purposes includingadministrative use (GUI access) SSLVPN and deep inspection

− Identify what a certificate can be used for




Module 18 Lab 1: Certificate Operations Exercise 1

P a g e | 75


01-50003-0301-20131018-D

This lab was designed and tested using Firefox. Each browser, while accomplishing the same objective,has a different method of configuration. Instructions are provided for doing specific steps using Firefoxonly. If you select another browser you will need to accomplish the same things, and instructions are notprovided.

Note: The steps for creating certificates vary depending on the software that is

used. OpenSSL is a free open source application and not endorsed by FortinetTechnologies in any way. This software has been pre-installed and configured tooperate according to the lab requirements. This is NOT a standard set-up.

1. On the Windows 2003 Server open a command line window and change to a directory whereyou can save and load files from.

2. Type CREATECA and follow the on screen prompts

Use the name “NewCA” for the certificate that you are creating.

Note: You will be prompted to enter details regarding the signing authority. Enterwhatever information you desire, so long as it is valid for that field (for example: anemail is: [email protected]).

Several files will be created automatically by this utility. A certificate file (.CRT) akey file (.key) and a text file that contains the password you used (.pass)

3. Connect to the GUI on the Student FortiGate device using HTTP (HTTPS will be used later)and go to System > Certificates > Local Certificates.

Click Generate to create a certificate request and enter the Certificate Name: “MyCert ”. For

Subject Information choose host IP and enter 10.0.1.254.

You may leave all the other fields blank however in recommended best practices, these fieldsshould be populated.

Note: If Certificates do not appear in the GUI as an option, check the administratorsettings and enable the option to make them display.

This certificate will be used in place of the administrative GUI. In order to avoid a

certificate warning the Subject Information must be set correctly.

Notice: You can choose to work in any directory, but Firefox defaults to downloadingfiles into the “downloads” directory. You can access this directory by typing:

CD “My Documents”\downloads




P a g e | 76


01-50003-0301-20131018-D

Once created, the certificate will display in the GUI showing a status of PENDING. Select thecertificate and download it to the folder used in step 2.

4. From the command prompt type SIGNCSR and follow the on screen prompts to sign thecertificate request. When prompted for filenames do not enter the file extension.

Note: If you forget what the password you used to create this new Certificate Authority was, open the .PASS file in a text editor and it will show you. This filewas created automatically during step 2.

5. On the Student FortiGate device, select the pending certificate request and IMPORT theLocal CRT file that was just created.

6. Connect to the GUI on the Student FortiGate device using HTTPS as follows:

https://10.0.1.254

There will be a warning message in the browser. Check the technical details and observe

that there is an error with the issuer chain (the CA is not trusted), AND the certificate is notvalid for this location. Or click on the padlock icon to see the security exception added earlier.

7. From the CLI on the Student FortiGate device, enter the following to configure themanagement GUI to use the new certificate.

conf sys global

set admin-server-cert MyCert

end

Note: The certificate name must match EXACTLY. Use the ? to view the list ofavailable certificates. If the name contains a space, put the certificate name in

‘single quotations’.

8. Connect to the GUI on the Student FortiGate device using HTTPS as follows:

https://10.0.1.254

There will still be a server warning message. Check the technical details and observe thatthe only error is with the issuer chain (the CA is not trusted) but the certificate is valid for thatlocation (assuming you used the correct IP when creating the request).

Note: The behavior change will be immediate but your browser may use localcached information. If you still see the old certificate, be sure to clear out yourbrowsers cache and then refresh the page.

Since the authority that signed the certificate is not public, the browser cannot findany information about it in the certificate repository. Just like the original certificateit is still perfectly “valid” but for security purposes the browser will give you awarning.




P a g e | 77


01-50003-0301-20131018-D

1. On the Student FortiGate device, go to the Local Certificates section and select the import option. Change the dropdown selection from “Local Certificate” to Certificate.

2. You will be prompted for the following: a certificate file, a key file, and a password.

Note: If you forget what the password you used to create this newCertificate Authority was, open the .PASS file in a text editor to find outwhat you used. It was created automatically with the CREATECA utility.

Browse to the files and information you created in step 2 of Exercise 1. These files arenamed: NewCA.crt and NewCA.key .

Select the imported certificate and view the certificate detail.




P a g e | 78


01-50003-0301-20131018-D

3. From the GUI on the Student FortiGate device go to Policy > Policy > SSL/SSH Inspection

Options, and select the default profile. Enable HTTPS deep inspection as follows:




P a g e | 79


01-50003-0301-20131018-D

4. Next go to UTM Security Profiles > Antivirus > Profile, and select the default profile. ConfirmHTTP virus scanning is enabled as follows:

Modify the outbound firewall policy and enable the default antivirus profile and enable SSLinspection.

.

5. Open a new web browser window or tab and clear the recent browsing history. Next, connect

to the web site:

https://support.fortinet.com/

Make note of the certificate details and leave this window open.

Note: You should be presented with a self signed certificate warning that shows a

certificate signed by Fortinet. Otherwise try flushing out the browsers cache andmake sure the profiles are properly enabled on the correct Firewall policy.




P a g e | 80


01-50003-0301-20131018-D

6. On the Student FortiGate unit, change the SSL decryption certificate to the one that wasloaded in the earlier step. Edit the SSL/SSH Inspection Options profile and set the CA(Certificate Authority) Certificate to use the file loaded in step 2 (NewCA).

7. Open a new web browser window or tab and connect to the web site:https://support.fortinet.com/

You will still get an error because the certificate signer is unknown. Make note of thecertificate details and compare with the certificates in the other window for the same URL.

Visit some additional HTTPS web sites and examine the certificates.

Note: In order to get r id of the self signed certificate warning you will need to loadthe certificate used by the SSL Proxy into the browsers root certificate repository.

To add the CA cert to the Firefox browsers certificate repository go to Tools > Options > Advanced > Encryption > View Certificates . Import the NewCA certificate (created in step 2of exercise 1) on the Authority tab and allow it to identify websites.




P a g e | 81


01-50003-0301-20131018-D

8. Reload the web page: https://support.fortinet.com. The certificate is now trusted

and no warning messages appear.

Note: Since the authority you created in exercise 1 is now known by the browseryou can also access the GUI of the FortiGate device without any warning at thispoint. The certificate is valid for the destination you are visiting (assuming youentered the correct IP information in the request) and the organization that signedit is now in the browsers list of known Certificate Authorities.

FortiGate units have multiple interfaces. In NAT mode each one has a different IPaddress so you need to either setup DNS so you can access the FortiGate deviceby name (and use a hostname in your certificate), or create a certificate that isvalid for multiple IP addresses.

Separate browsers use separate certificate repositories. This means that custom

CAs must be loaded into them independently.



Module 19 Lab 1: Data Leak Prevention

P a g e | 82


01-50003-0301-20131018-D

This lab will demonstrate how to use data leak prevention rules and sensors to block thetransmission of sensitive data outside the network.

− Configure DLP to block encrypted files, the leakage of credit card information and oversize files

− Set up DLP banning and quarantining

− Configure DLP Fingerprinting

− Read and interpret DLP log entries




Module 19 Lab 1: Data Leak Prevention Exercise 1

P a g e | 83


01-50003-0301-20131018-D

1. Select Security Profiles > Data Leak Prevention > File Filter and review the file filter calledall_executables

1.

2. From the GUI on the Student FortiGate device, go to Security Profiles > Data LeakPrevention > Sensor . Create a sensor called Training (Click Create New in the upper right-hand corner of the Edit DLP Sensor window.)

3. In the Edit DLP Sensor window, create a new rule that uses the default file filterall_executables with the following settings:

Filter: Files

File type included in: all_executables

Examine the Following services: HTTP

Action: Block

4. Go to Policy > Policy > Policy and edit the firewall to enable the DLPsensor called Training .

5. To test the DLP sensor, an executable file must be sent using HTTP.

In a web browser on the virtual Windows Server, connect to the following URL:

http://www.sendspace.com

6. On the sendspace web page, click Browse and locate the putty.exe executable file on thedesktop of the virtual Windows 2003 Server.

Enter the email address of a recipient along with your own email address in the appropriatefields then click Upload .

7. From the GUI on the Student FortiGate device, locate the Forward Traffic log and locateentry with a blocking security action for this attempted data leak. .

Notice: Using a file name of *.exe is also possible. The obvious weakness however,is changing the filename to something like *.ex1, or *.txt. File type identification worksby examining the layout of the file. Not all file types has a strict design so manycannot be identified in this fashion.




P a g e | 84


01-50003-0301-20131018-D

8. Right-click the putty.exe file and select Add to “putty.7z” to save it as a .7z compressed filetype.

9. Return to the sendspace web page and attempt to transfer the zipped file putty.7z . The filewill be blocked.

10. Check the log events generated by the sensor for this blocked transfer.

11. Right-click the putty.exe file again and select Add to archive… to save it as a .7z compressed

file type.




P a g e | 85


01-50003-0301-20131018-D

Rename the archive to putty-password.7z and set the archive password to: test .

12. Return to the sendspace web page and attempt to transfer the encrypted zipped file “ putty- password.7z ”. The file will be transmitted successfully.

Note: Password protected archives cannot have their contents scanned or be

identified by file type only by pattern (name).

13. Edit the sensor ‘’Training’ and add a second filer to block encrypted files. Note this filter willmatch all encrypted files and not just encrypted executables.

Filter: Files

Encrypted Enable


Action: Block

14. Return to the sendspace web page and attempt to transfer the encrypted zipped file “ putty- password.7z ”. This time the file will be blocked.




P a g e | 86


01-50003-0301-20131018-D

1. Create a new DLP filter in the Training DLP sensor with the following details:

Filter: Files

Containing: Credit Card #


Action: Block

2. In a web browser on the virtual Windows Server, connect to the following URL:

http://www.sendspace.com

3. On the sendspace web page, click Browse and locate the creditcards.txt file inResources\Module19.

Enter the email address of a recipient along with your own email address in the appropriatefields then click Upload .

The file will appear to upload, then a DLP warning message will get displayed (or a reset ifflow based inspection was used).

4. Edit the Training DLP sensor and change the action for the credit card file filter to QuratineIP,On the sendspace.com web site, attempt to send the creditcard.txt file once again. The filedownload will be blocked.

5. From the GUI on the Student FortiGate device, go to User & Device > Monitor > BannedUser and locate the banned entry in the list.

6. Select and delete the banned entry.

Notice: This can be done for different CC types individually (you can find regular

expressions for them on the internet). Hard coding the patterns allows for much fasterdetection. The patterns detectable are Visa, Mastercard or American Express, Diner’sClub, Discover, JOB

Notice: If you try to visit other web sites now you will be blocked and a replacementmessage appears with a block message.




P a g e | 87


01-50003-0301-20131018-D

This exercise demonstrates how to work with document finger printing.

1. Back up the configuration of the Student FortiGate device and save it to the Windows 2003Server desktop.

2. From the GUI on the Student FortiGate device, go to Security Profiles > Data LeakPrevention > Document Fingerprinting. In the Manual Document Fingerprints section, uploada new document to fingerprint.

Click Create New and locate the configuration file on the Windows 2003 Server that youcreated in step 1.

Set the Sensitivity Level to Critical.

3. Create a new DLP filter in the Training DLP sensor with the following details:

Filter: Files

File Finger Print: Critical

Examine the Following Services: HTTP

Action: Block

Click OK to save the change to the filter and click Apply to save the change to the sensor.

4. On the sendspace.com web site, attempt to send the configuration file. The file download willbe blocked.

5. Open the configuration file in a text editor that can handle word wrap (for example, Notepad )and make some changes to the configuration and save them.

6. On the sendspace.com web site, attempt to send the configuration file again. The filedownload will most likely be blocked (depending on the number of changes that were made).

Notice: Fingerprinting breaks the file into chunks and does rolling checksums on eachpart. Changes in one section do not affect all checksums. The default settings allowfor a single chunk checksum to trigger a match.



Module 21 Lab 1: Case Study Scenario

P a g e | 88


01-50003-0301-20131018-D

The aim of this lab is to introduce students to working with multiple FortiGate device features at onceto implement a solution based on customer needs.

− Fulfill the customer’s requirements for the installation, based on the supplied description.


School KIDZ will be replacing the exterior firewall with a FortiGate device

As a school, one of the top priorities is to prevent students from viewing/accessinginappropriate material on the Internet

Virus scanning is also needed, as is protection from hacking attempts. These functionswill need to be integrated with the school’s current Active Directory system and mustprovide separate access for students and teachers

The school also wants to ensure that the students are not permitted to run inappropriatesoftware of any kind, similar to Cabos.

The firewall must not cause any noticeable or significant delays.

The school currently has an internal exchange server for email which also needsprotection. Ideally the solution should be redundant.

Key Aspect/Features of Installation: 18Optional Features: 3



Appendix A

1. Fortinet Documentation: http://docs.fortinet.com

The documentation web site contains all Fortinet manuals, white papers and guides forFortinet products.

2. Fortinet Knowledge Base: http://kb.fortinet.com

This site is useful for finding working examples and tips for Fortinet products.

3. Fortinet Web Site: http://www.fortinet.com

The Fortinet web site contains all hardware and product specifications.

4. FortiGuard Web Site: http://www.fortiguard.com

This site is suitable for finding information about the FortiGuard Subscription Services.

5. FortiCare Web Site: https://support.fortinet.com

The FortiCare web site is used to interface with Fortinet support, register devices you havepurchased and download firmware updates.

6. Fortinet User Forums: http://support.fortinet.com/forum/

These are user-led and run forums that discuss many different topics surrounding the use of

Fortinet devices.

http://docs.fortinet.com/



http://kb.fortinet.com/



http://www.fortinet.com/



http://www.fortiguard.com/






http://support.fortinet.com/forum/







