FortiGate Multi-Threat Security Systems II Secured 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, FortiGuardAntispam, 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/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
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
Page |1 Course 301 Secured Network Deployment and IPSec VPN 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
Page |2 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Virtual Lab Environment Basics
This section provides details of the virtual lab environment that will be used for the hands-on labs in this course. Steps are included for connecting to the virtual environment along with troubleshooting tips to help students easily navigate the lab configuration.
Alert: The following section is only applicable to the Fortinet hosted virtual lab environment. Please ignore this section if you are using an alternate classroom lab environment unless otherwise directed by your trainer. If you are uncertain, consult your trainer to find out which lab setup documentation you must follow.
The network diagram below shows the configuration of the virtual environment that students will use in the course.
Page |3 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Virtual Lab Environment Basics
1. Run the TrueLab System Checker to verify the compatibility of your computer with the virtual lab 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 from the PC to the TrueLab environment. It can also help troubleshoot connectivity problems related 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 Success message will be displayed.
Page |4 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Virtual Lab Environment Basics
If a status of Failed is displayed, verify the on-screen messages to identify potential problem areas 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 the following 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.
Page |5 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Virtual Lab Environment Basics
4. The virtual lab Java applet is launched. Select a resolution for the applet and click Open to access the Windows 2003 Server device in the virtual lab environment. This will serve as the primary student machine for the classroom exercises. Note: If for any reason the connection to the virtual Windows 2003 Server is lost, regain access by selecting Operations > Disconnect and then Operations > Connect to Primary from the menu. 5. To connect to other virtual machines in this environment go to Operations > Connect to Secondary 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 the virtual lab environment.
Page |6 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Virtual Lab Environment Basics
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 environment through 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 Java console is set to Show console. It is recommended that the Java console be left open as it often provides useful logs for troubleshooting. If you get disconnected unexpectedly from any of the virtual machines (or from the virtual lab portal) please reattempt a connection. If unable to reconnect repeatedly after multiple attempts, please notify the instructor.
If during the labs, particularly when reloading configuration files, you see a message similar 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 authentication server. The command ‘execute update-now’ will resend the request and force a response.
Page |7 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Classroom Lab Configuration
The following diagram illustrates the classroom network configuration that will be used for the labs in this 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)
Page |8 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
L
At various points throughout this lab guide, you will be instructed to load different configuration files which contain objects and settings needed to complete the exercises. In order to load these configuration files, you will first need to configure some minimum networking requirements. This must be done since the Student and Remote FortiGate devices in the virtual networking environment are provisioned from a raw VM image. The following steps will guide you through the required preparation. These steps MUST be performed before proceeding. If you have already performed these steps as part of attending the 201 Course, then these 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
Page |9 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting
The aim of this lab will be for students to set up a router configuration and test various scenarios to learn how the FortiGate unit makes routing decisions. Students will also work with diagnostics and debugging 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 usage of this technique – Describe the fail-over and load-balancing techniques available with static routing and describe 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 the status of these protocols
Estimated time to complete this lab: 50 minutes
P a g e | 10 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1
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 reloaded 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 restore the 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: “waiting for 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 the following 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 your SSH 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 | 11 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1
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 3099662156 ack 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 2724505986 ack 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 if necessary): 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 | 12 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1
You will see various sessions listed such as DNS and HTTP. Look for the HTTP session just established, session info: proto=6 proto_state=02 duration=115 expire=4 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=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->4 gwy=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=0 per_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 port numbers. (How this new IP address and port number is accessed will be discussed more in the 201 Firewall Policy module). 4. Next execute the following commands to review the debug flow output, using a filter for the specific 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 or destination address or port as this restricts you to one direction of traffic.
P a g e | 13 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1
A sample debug flow output is provided below with notes:
STUDENT # id=13 trace_id=21 func=resolve_ip_tuple_fast line=4048 msg="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=4176 msg="allocate a new session-000000ed" New session ID generated. id=13 trace_id=21 func=vf_ip4_route_input line=1602 msg="find a route: gw-10.200.1.254 via port1" Originator direction gateway lookup, this happens once for the session provided there is no gateway change. FortiOS is routing first. id=13 trace_id=21 func=get_new_addr line=2347 msg="find SNAT: IP10.200.1.1, port-65158" SNAT value lookup. id=13 trace_id=21 func=fw_forward_handler line=621 msg="Allowed by Policy-1: SNAT" Firewall policy match. id=13 trace_id=21 func=__ip_session_run_tuple line=2290 msg="SNAT 10.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-root received a packet(proto=6, 10.200.3.254:80->10.200.1.1:65158) from port1." SYN ACK received from server. id=13 trace_id=22 func=resolve_ip_tuple_fast line=4082 msg="Find an existing session, id-000000ed, reply direction" Matches an existing session ID.
P a g e | 14 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1
id=13 trace_id=22 func=__ip_session_run_tuple line=2304 msg="DNAT 10.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 a route: 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-root received a packet(proto=6, 10.0.1.10:4742->10.200.3.254:80) from port3." ACK received from client. id=13 trace_id=23 func=resolve_ip_tuple_fast line=4082 msg="Find an existing 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 debug flow is a very good tool. Discuss the output of these commands in a group discussion with your Instructor.
P a g e | 15 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 2
When there are different paths to the same destination, Dead Gateway Detection can be used to provide a fail-over mechanism whereby a detect server is configured. The detect server is an address of a reachable upstream device. The FortiGate unit then uses an echo/echo reply mechanism, typically ICMP ping, but UDP echo and TCP echo are also supported. If the device fails to respond after a configured number of retries, then the static routes associated with that interface are 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 VPN remote gateway. This is the example we shall use in our virtual lab, therefore the Student FortiGate device has two Dead 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
Ping Server:
10.200.4.1
Refer to the network diagram provided at the beginning of this lab guide to verify the FortiGate device IP addresses.
1. From the GUI on the Student FortiGate device, go to Router > Static > Settings and check the above Dead Gateway Detection configuration. The detect server is enabled on the interface 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 no response on port2 because of the Remote FortiGate unit’s current configuration.
P a g e | 16 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 2
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
Ping Server:
10.200.1.1
Second: Interface:
port5
Gateway IP:
10.200.4.254
Ping Server:
10.200.2.1
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 this has created a route back to this source in the kernel routing table and therefore these gateway detect packets now pass the RPF checking. You should now observe ICMP echo request/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=0 10.200.1.1/255.255.255.255/0->10.200.3.1/32 pref=0.0.0.0 gwy=10.200.1.254 dev=2(port1) tab=254 vf=0 scope=0 type=1 proto=14 prio=0 10.200.2.1/255.255.255.255/0->10.200.4.1/32 pref=0.0.0.0 gwy=10.200.2.254 dev=3(port2)
P a g e | 17 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3
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 routing table. 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 a selected route. 3. Execute the same commands used above from the CLI on the Remote FortiGate device. You should 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 failure could occur if the link goes down or if the Dead Gateway Detection associated with that interface 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 the source on port4. Only a route back for the gateway detect peer is available on the routing table. Therefore, if we want incoming traffic on an interface from an unknown source IP we require a 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 | 18 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3
5. On the Student and Remote FortiGate devices, set the distance of the second default routes to 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 the routing 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 actual table used for packet forwarding when sessions are established. It is useful to think of the routing table as the management plane and the FIB as the forwarding plane. A useful example to illustrate this separation is HA. In an HA cluster, the management plane and forwarding plane are present on the primary device, however only the forwarding plane is present on the secondary device and 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 static routing, 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 same source IP and same gateway. In our example, as all traffic is coming from the same source address, 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 the distribution settings so that traffic from the same source IP is distributed. (You may be faced with a similar scenario in your production network).
P a g e | 19 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3
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 to 1(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 interface is over subscribed. 10. On the virtual Windows Server, open a web browser and connect to a random web site to generate 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. You can examine this from the output of the above diagnose command. Since this command outputs the interface numbers and not their names, use the output of the 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 with the SYN flag set: diag sniffer packet any ‘tcp[13]&2==2 and port 80’ 4
P a g e | 20 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3
13. Next, it may be undesirable to load balance all traffic and there may be hosts and/or protocols which we would like to use a particular gateway for. This can be achieved with policy routing which takes precedence over the routing table. In this example, you will create a policy route to force all outgoing HTTPS traffic on the Student 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 static
routes, 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 | 21 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 4
We will now go through a simple BGP configuration that will show us the steps to set up a BGP peer relationship between the Student and Remote FortiGate devices. In this lab, you will configure dynamic 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 following parameters: 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-hop BGP by entering the CLI commands shown below. This step is required because the BGP peer 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 following parameters: Local As:
65502
Router ID:
0.0.0.2
Click Apply.
P a g e | 22 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 4
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-hop BGP by entering the CLI commands shown below. This step is required because the BGP peer 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 go to 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 the other way round, where multi-hop BGP is used between routers however it is the FortiGate device in between the two routers which is configured with static routes.
P a g e | 23 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 4
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 will decode 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 value no 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 Message Error/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 obsever in 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
P a g e | 24 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking
The aim of this lab is for students to gain experience working with VDOMs and to be familiar with the VLAN configuration objects.
− Configure and test VDOMs
Estimated time to complete this lab: 45 minutes
P a g e | 25 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking Exercise 1
1. From the Windows Server, you first will need to connect to the Student FortiGate device and restore the configuration file that is needed for this lab. Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the following configuration file: Resources\Module12\Student\Student-vdom.conf The Student FortiGate device will reboot. 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 and FortiManager respectively. We will not be discussing them further in this lab however, the point 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 System Information 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 the Global Configuration. To access the root VDOM, click Virtual Domains which is displayed at 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 called customer. Note that the customer VDOM is now listed and you can select it from the VDOM list by clicking 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 to Global > 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. This administrator will only be able to log in through an interface that is assigned to the customer VDOM.
P a g e | 26 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking Exercise 1
7. You will now place the port3 interface which connects to the internal network, in the customer VDOM. 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. If the value is zero, you can simply edit the interface settings and select the customer vdom from the Virtual Domain drop-down list. For non-zero Ref. values, click on the value and note the object usage references. Remove any objects that reference port3. For example, if port3 is referenced by the system DNS, you will need to go to System > Network > DNS Server (in the root VDOM) and delete the DNS Service on port3. Once all references have been removed, you will be able to move the port3 interface to the customer VDOM.
Leave the port1 and port2 interfaces in the root vdom. This will provide a separation between the customer firewall and the firewall that is providing Internet or external access. This is a common usage scenario and there typically would be several customer type VDOMs connecting to the single root vdom providing external access. An example of such usage is an 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: get router info routing-table all You may have difficulty entering this command. This is because you need to be in the context 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 | 27 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking Exercise 1
Note that the VDOM name entered is case sensitive. Afterwards check the routing table with the following CLI commands: get router info routing-table all next
Now go to the root vdom to view the routing table. Be careful with this command because the VDOM names are case sensitive!! If you enter Root, you will in fact create a new vdom called Root in addition to the root vdom. edit root get router info routing-table all 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 Create New displayed in the top left hand corner of the page and select VDOM link. Create a new VDOM Link using the following details: Name: vlink Interface #0
vlink0
Virtual Domain:
root
IP/Network Mask:
10.10.100.1/30
Administrative Access:
HTTPS, PING, SSH
Interface #1
vlink1
Virtual Domain:
customer
IP/Network Mask:
10.10.100.2/30
Administrative Access:
HTTPS, PING, SSH
After creating the inter-VDOM links, note that the VDOM links created along with two subinterfaces have been placed within the root and customer VDOMs. These interfaces have been named vlink0 and vlink1. These are point-to-point interfaces that allow communication between 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 | 28 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking Exercise 1
10. A default route is required for the customer VDOM using the newly created inter-VDOM link interface. 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 interVDOM link interface. Go to Virtual Domains > root > Router > Static > Static Route. Create a new route using the following details: Destination IP/Mask:
10.0.1.0/24
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 Internet through 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 | 29 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking Exercise 1
14. Switch to the customer VDOM, create a second policy that allows traffic from the port3 interface to the vlink1 interface with the following details: Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
all
Outgoing Interface:
vlink1
Destination Address:
all
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 and configure port3 to forward to system DNS. Connect to an external web site and ensure that the count field of the firewall policy is incrementing on both the outgoing policy of the customer VDOM and the outgoing policy of the root VDOM. 16. From a DOS prompt on the Windows Server, run the following trace route command and verify 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 that VDOM. 18. Navigate through the GUI and select the various menu items to see what the VDOM administrator has the ability to control. Since the customer-admin administrator has access to the customer VDOM only, they will not automatically be placed into the Global Configuration, nor will they have access to it. The display of the GUI will change as the service-admin user has access to only the VDOM specific objects. Logout from the customer VDOM.
P a g e | 30 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs
The aim of this lab is for students to configure two transparent mode VDOMs and to enable UTM inspection to all traffic in the ‘root’ VDOM. An inter-vdom link will be used to inter-connect the two VDOMs.
– Configure two transparent mode VDOMs – Create and use VDOM objects
Estimated time to complete this lab: 45 minutes
P a g e | 31 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs Exercise 1
1. From the Windows Server, you first will need to connect to the Student FortiGate device and restore the configuration file that is needed for this lab. Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the following configuration file: Resources\Module13\Student\Student-tp.conf The Student FortiGate device will reboot. 2. On the Student FortiGate device, go to System > Dashboard > Status and in the System Information 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 the Global configuration. 4. Go to Global > VDOM > VDOM and click Create New to add new VDOM. Configure the following 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 | 32 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs Exercise 2
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 between the root and inspect VDOMs. An IP address is only configurable on the NAT/Route mode vdom interface. 4. Go to the GUI and review the new VDOM tree display by selecting Virtual Domains and reviewing 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 the inspect 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 | 33 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs Exercise 2
6. Go to the inspect VDOM and create the following polices to allow traffic between the port1 and link1 interfaces initiated in either direction: Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
any
Source Address:
All
Outgoing Interface:
any
Destination Address:
all
Schedule:
always
Service:
ALL
Action:
ACCEPT
From the Firewall Policy display of the inspect VDOM, right-click on the Security Profiles field and select the default Antivirus profile. A message will prompt you that this change has been saved. 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 and paste of the existing outgoing policy and changing the outgoing interface. Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
all
Outgoing Interface:
link0
Destination Address:
all
Schedule:
always
Service:
ALL
Action:
ACCEPT
Enable NAT:
enabled
Logging Options:
Log all sessions
P a g e | 34 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs Exercise 2
8. To direct traffic from your Windows host to the inspect VDOM, in the root VDOM, create a new static route pointing to the inter-vdom link using the following settings: Destination IP/Mask:
0.0.0.0/0
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 preferred route. 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 single width 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 in each VDOM.
P a g e | 35 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 14 Lab 1: High Availability
The aim of this lab is to set up a high availability cluster configuration using FortiGate devices in the student environment. Different HA modes will be used to set up various HA configurations and students use diagnostics and debug commands to observe HA functionality and behavior on the FortiGate unit.
– Set up an HA cluster using FortiGate devices in the student environment – Execute and interpret diagnostic output – Test HA synchronization and failover
Estimated time to complete this lab: 45 minutes
P a g e | 36 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 14 Lab 1: High Availability HA Lab Topology
The virtual lab environment has been wired to allow an HA cluster to be configured using the existing devices as shown in the following network diagram.
P a g e | 37 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 14 Lab 1: High Availability Exercise 1
1. From the Windows Server, you first will need to connect to each FortiGate device and restore the 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\Module14\Remote\remote-ha.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\Module14\Student\student-ha.conf. The Student FortiGate device will reboot. 2. Open the console on both the Student and Remote FortiGate devices. This allows you to observe the standard error messages sent to the console which provide useful status information, 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 | 38 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 14 Lab 1: High Availability Exercise 1
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-a master, 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 and from the CLI look at the session table entries of both the Student and Remote FortiGate devices using the following CLI commands: diag sys session filter dport 80 diag sys session list 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 the slave CLI from the master, execute ha manage
(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 the backup device. The reason for this is because all management traffic goes to and from the master and all non-TCP traffic is handled by the master. By default, only TCP sessions destined 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 a public 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 this from the CLI as follows: get sys stat
P a g e | 39 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 14 Lab 1: High Availability Exercise 1
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 Student FortiGate 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 master which is the unit priority, You should observe that the Student FortiGate device is now master. 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-sync process, 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 starts communicating with the cluster. 9. Important: Before proceeding to the next lab, connect to https://10.0.1.254 and go to System > Config > HA and for the REMOTE device click the Disconnect from cluster icon to remove 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.0 Sending cmd to HA member 0
P a g e | 40 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN
The aim of this lab is for students to work with some of the more advanced capabilities of IPSec VPNs. Students configure advanced VPN settings used in hub-spoke and partial meshed configurations.
− 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
Estimated time to complete this lab: 45 minutes
P a g e | 41 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 1
You will now configure a site-to-site tunnel between Student port1 and Remote port4. In this example use interface based IPsec. In a later exercise, you will configure an IP address on this IPsec interface in order to configure dynamic routing. Below are the settings to configure the Student FortiGate device. Once you have completed these steps, you will then need to configure the Remote FortiGate device. Note that the steps for this are intentionally not provided since the objective of this exercise is for the student to determine the correct settings on their own, based on the Student device settings that are given. You can also use the network diagram (located at the beginning of this lab guide) for additional guidance. 1. From the Windows Server, you first will need to connect to each FortiGate device and restore the 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\Module15\Remote\remote-ipsec2.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\Module15\Student\student-ipsec2.conf. The Student FortiGate device will reboot. 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: Authentication: DH Group::
AES256 SHA1 5
XAuth
Disabled
Dead Peer Detection:
Enabled
Leave other fields at their default value. P a g e | 42 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 1
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: Authentication:
AES256 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 the following details: Destination IP/Mask:
10.0.2.0/24
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 following details:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
STUDENT_INTERNAL
Outgoing Interface:
VPN
Destination Address:
REMOTE_INTERNAL
Schedule:
always
Service:
ALL
Action:
ACCEPT
P a g e | 43 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 1
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
VPN
Source Address:
REMOTE_INTERNAL
Outgoing Interface:
port3
Destination Address:
STUDENT_INTERNAL
Schedule:
always
Service:
ALL
Action:
ACCEPT
7. Repeat the configuration on the Remote FortiGate device using the above settings and the network 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.
P a g e | 44 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN VPN Connection Troubleshooting
1. From a command prompt on the Windows Server confirm that you can successfully ping the following 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 ping options 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 the Status column for the connection. Troubleshooting will be required if the Status column displays a red arrow or the VPN connects 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 external interface 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 the interfaces), then basic connectivity for the VPN has not been established.
Note: Be sure to force the pings out to the correct interface. This may mean shortening 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 on the Remote FortiGate device? Clear the ping-options settings first. exec ping 10.200.3.1 Can the Remote device ping the Student FortiGate unit?
P a g e | 45 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN VPN Connection Troubleshooting
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 scrolling output): diag debug reset 3. On the Remote FortiGate device (10.0.1.254) , attempt to send traffic. You can either use a 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, or policies. 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 sending FortiGate unit: diag sniff packet port1 icmp Verify that the ping is arriving at the interface. Run the following command on the receiving FortiGate 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 | 46 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 3
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 FortiGate port2 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 and using a higher distance of 20. 3. Add the new IPSec interfaces to the zone VPN and enable intra-zone traffic.
P a g e | 47 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 4
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 the Remote 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 use the example in the note below.
Note: When changing the administrative status of an interface, affected sessions will not fail back when the primary path is brought back up. Alternatively, an upstream device failure can be simulated by executing the following command from a command prompt on the LINUX host: ifconfig eth3 down (To access the LINUX device, use PuTTY to connect using SSH to 10.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 the failure. Also when the primary path is brought back up using the following command, the affected sessions will fail back: ifconfig eth3 up
4. Enter the following commands from the CLI on the Student FortiGate device to observe the session fail-over: diag sys session filter dst 10.0.2.10 diag sys session list
P a g e | 48 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 4
Sample output:
session info: proto=1 proto_state=00 duration=401 expire=59 timeout=0 flags=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/1 tuples=2 orgin->sink: org pre->post, reply pre->post dev=4->18/18->4 gwy=10.0.2.10/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) misc=0 policy_id=3 id_policy_id=0 auth_info=0 chk_client_info=0 vd=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 will update 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 the following CLI command: diag netlink interface list 5. Important: Before proceeding, change the Administrative Status of the port1 interface on the Student FortiGate device back to UP.
P a g e | 49 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 5
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 the IPSec interfaces in the VPN zone to add the Local IP and Remote IP address values from the chart below: Interface Names
IP
Remote IP
Remote_1
172.16.1.1
172.16.2.1
Remote_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. Networks Click 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. Interfaces Click Create New to create new OSPF interfaces for the two IPSec interfaces with the values from 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 | 50 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 5
4. To make the VPNs redundant, the cost of the redundant VPN routes must be lowered (the default 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. Networks Click 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. Interfaces Click Create New to create new OSPF interfaces for the two IPSec interfaces with the values from 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 | 51 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 5
6. Next enter the following CLI commands: config router ospf config ospf-interface edit S1_OSPF set mtu 1436 next edit S2_OSPF set mtu 1436 next end end
P a g e | 52 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 6
In this exercise, you will run the commands given from the Student FortiGate device, however note that 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 CLI command: get router info ospf neighbor Sample output: OSPF process 0: Neighbor ID
Pri
State
Address
Interface
0.0.0.2
1
Full/- 00:00:34
Dead Time
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 get router info routing-table 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 the Remote 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 | 53 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 6
8. Check the session failover display for all the routes learned by OSPF by running the following from the CLI: get router info routing-table ospf 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=0 flags=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/1 tuples=2 orgin->sink: org pre->post, reply pre->post dev=4->18/18->4 gwy=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) misc=0 policy_id=5 id_policy_id=0 auth_info=0 chk_client_info=0 vd=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 | 54 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 7
1. For faster failover, BFD can be implemented. Enable BFD by entering the following CLI commands 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 | 55 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 7
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 root 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 ping failures with this protocol enabled.
P a g e | 56 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 2: IPSec VPN with FortiClient Exercise 1
In this lab, an IPSec VPN will be created between the Student FortiGate unit and the FortiClient installation on a Windows XP host in the Remote environment.
− Configure an IPSec VPN between the Student FortiGate unit and FortiClient Connect
Estimated time to complete this lab: 45 minutes
P a g e | 57 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 2: IPSec VPN with FortiClient Exercise 1
1. From the Windows Server, you first will need to connect to each FortiGate device and restore the configuration files that are needed for this lab. Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the following configuration file: Resources\Module15\Student\student-ipsec3.conf. The Student FortiGate device will reboot. Connect to the GUI on the Remote FortiGate (10.200.3.1) and restore the following configuration file: Resources\Module15\Remote\remote-ipsec3.conf. The Remote FortiGate device will reboot.
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 | 58 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 2: IPSec VPN with FortiClient Exercise 1
3. On the Student FortiGate device, go to Policy > Policy > Policy and create a FClientport3 policy to allow inbound connections with the following details: Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
FClient
Source Address:
VPN-CLIENTS
Outgoing Interface:
port3
Destination Address:
STUDENT_INTERNAL
Schedule:
always
Service:
ALL
Action:
ACCEPT
4. Create a port3 FClient policy to allow outbound connections with the following details: Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
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: Destination IP/Mask:
172.20.1.0/24
Device:
FClient
P a g e | 59 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 2: IPSec VPN with FortiClient Exercise 2
1. Connect to the console of the external Windows host. (In the virtual lab applet, go to Operations > Connect to Secondary > WinXP. The virtual Windows XP device desktop will be 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 | 60 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 15 Lab 2: IPSec VPN with FortiClient Exercise 3
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 routing change: In the virtual lab applet in the WinXP image, go to Operations > Disconnect. After a few moments, return to the Operations menu and click Connect to Secondary > WinXP to return to the Windows XP device. 2. Within a few moments, the external Windows host device should receive an IP address within 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 the DOS 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 display the 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 the static 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 VPN connection. 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 ID Destination. On the external Windows host go to the IPSec VPN Connections window of the FortiClient Connect console and click Disconnect.
P a g e | 61 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System
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 resulting log 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
Estimated time to complete this lab: 80 minutes
P a g e | 62 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 1
1. From the Windows Server, you first will need to connect to the Student FortiGate device and restore the configuration file that is needed for this lab. Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the following configuration file: Resources\Module16\Student\student-ips.conf The Student FortiGate device will reboot. 2. On the Student FortiGate device, go to Security Profiles > Intrusion Protection > IPS Signatures to view the installed signatures. Click the signature name link to view more information about the signature from the Fortinet web site. Protocol decoders are used as part of signature matching. HTTP decoder ports are automatically 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 (+) in the upper-right corner of the Edit IPS Sensor window to create a new sensor. Set the Name for 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 the following 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. Under Security 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\nikto2.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 | 63 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 1
8. On the Student FortiGate device, go to Log & Report > Security Log > Intrusion Protection and 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 and add 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 by this sensor, the Status value appears as detected. This indicates that a signature was matched and that the traffic was allowed to pass. In the spaces below, record the names for two of the detected signatures. The signature name 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 the LINUX_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 signature identified 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 | 64 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 2
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 displayed DoS policy. Configure the following settings: Incoming Interface:
port1
Source Address:
all
Destination Address:
all
Service:
ALL
Anomalies:
set the Threshold for icmp_flood to 200.
Status
enable
Logging
enable
Action:
Block
2. Open an SSH connection and login to the Linux host. Enter the username root with a password 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 wait for replies between ICMP echo requests. Some pings will be blocked as the packets per second exceed the configured threshold. The periods 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 the ICMP flood has been blocked; this is indicated by the Status field entry clear_session.
P a g e | 65 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 2
4. From the CLI on the Student FortiGate device, run the following diag command to verify the current 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 the previously blocked traffic. This time, the Service parameter will be set to ICMP to make this policy more specialized than the first one you created. Go to Policy > Policy > DoS Policy and click Create New. Configure the following settings: Incoming Interface:
port1
Source Address:
all
Destination Address:
all
Service:
ALL_ICMP
Anomalies:
set the Threshold for icmp_flood to 200.
Status
enable
Logging
enable
Action:
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 at the 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: diagnose ips anomaly list Sample output: list nids meter: id=icmp_flood ip=10.200.1.254 dos_id=1001 exp=924 pps=21 freq=20 total # of nids meters: 21.
The PPS stops at the same value, since the more specific DoS sensor is applied after the general sensor. 8. Use drag & drop to re-order the DOS policies so that the ALL_ICMP policy with the action Pass is first.
P a g e | 66 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 2
9. Ensure the ping test is still running and examine the anomaly counters again as follows: diagnose ips anomaly list Sample output: list nids meter: id=icmp_flood ip=10.200.1.254 dos_id=1001 exp=921 pps=21 freq=125 total # of nids meters: 1. Note that pings are no longer blocked at the same rate and the anomaly counters for the PPS are much higher than the previous value but less than the configured threshold; the traffic is allowed. You can also observe this from the logs. The entries will appear similar to the following. Modify the Column-Settings to list the Sensor field. This displays the sensor that was applied. You should also observe that the periods have stopped printing on the console as the packets are no longer dropped.
This test uses a simple example of ICMP. When enabling DoS protection in your network, be careful 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 can be optimized for any network.
P a g e | 67 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 3
The custom signature created in this exercise will detect the RETR (GET) command on the FTP control 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 > IPS Signatures and click Create New. Enter the name ftp_get for the new custom signature and type 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 > IPS Sensor and edit the LINUX_SERVER sensor created earlier. Create a new filter and set the Sensor Type to Specify Signatures. Click the ftp_get signature created in the previous step and 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 listed below. 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 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 > Intrusion Protection, and locate the attack log entry to verify that the reset action taken as shown below:
P a g e | 68 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On
In this lab, Fortinet Single Sign On will be configured to allow the FortiGate unit to collect authentication 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 web resources.
− 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
Estimated time to complete this lab: 45 minutes
P a g e | 69 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On Exercise 1
1. From the Windows Server, you first will need to connect to the Student FortiGate device and restore the configuration file that is needed for this lab. Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the following configuration file: Resources\Module17\Student\Student-sso.conf The Student FortiGate device will reboot. 2. On the Windows Server, double-click the Fortinet Single Sign On installation file located in Resources\Module17, and click Run to launch the Fortinet Single Sign On Agent Installation Wizard. 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 the service, 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 Domain Controller Agent Installation Wizard. 7. In the Install DC Agent Wizard, accept the Collector Agent IP Address of 10.0.1.10 and the Collector 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. Click Next. 10. Set the Working Mode to Polling Mode and Check Windows Security Event Logs. Click Next.
P a g e | 70 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On Exercise 1
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.lab domain is selected. Click OK. Click Set Group Filters. Click Add and enable the Default filter. Click Advanced and expand the domain name of TRAININGAD. From the expanded list select the check box for 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 | 71 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On Exercise 2
1. On the Student FortiGate device, go to User & Device > Authentication > Single Sign-On and create a new entry with the following settings: Type:
Fortinet Single-Sign-on Agent
Name:
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 a new 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 | 72 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On Exercise 3
1. On the Windows Server, click Start > Run and enter the program name of mstsc.exe to launch 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 should be 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 using FSSO: 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’ because this host has two NICs.
P a g e | 73 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations
The aim of this lab is for students to lay the ground work for all SSL-based inspection that a FortiGate unit is capable of performing. Students learn the details of how inspection is performed and the encryption functions used. In addition, the certificate is examined to understand its general layout 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 including administrative use (GUI access) SSLVPN and deep inspection − Identify what a certificate can be used for
Estimated time to complete this lab: 30 minutes
P a g e | 74 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 1
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 Firefox only. If you select another browser you will need to accomplish the same things, and instructions are not provided. 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 Fortinet Technologies in any way. This software has been pre-installed and configured to operate 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 where you can save and load files from.
Notice: You can choose to work in any directory, but Firefox defaults to downloading files into the “downloads” directory. You can access this directory by typing: CD “My Documents”\downloads
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. Enter whatever information you desire, so long as it is valid for that field (for example: an email is:
[email protected]). Several files will be created automatically by this utility. A certificate file (.CRT) a key 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 fields should be populated. Note: If Certificates do not appear in the GUI as an option, check the administrator settings 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.
P a g e | 75 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 1
Once created, the certificate will display in the GUI showing a status of PENDING. Select the certificate 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 the certificate 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 file was created automatically during step 2.
5. On the Student FortiGate device, select the pending certificate request and IMPORT the Local 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 not valid 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 the management 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 of available 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 that the only error is with the issuer chain (the CA is not trusted) but the certificate is valid for that location (assuming you used the correct IP when creating the request). Note: The behavior change will be immediate but your browser may use local cached information. If you still see the old certificate, be sure to clear out your browsers cache and then refresh the page. Since the authority that signed the certificate is not public, the browser cannot find any information about it in the certificate repository. Just like the original certificate it is still perfectly “valid” but for security purposes the browser will give you a warning.
P a g e | 76 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 2
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 new
Certificate Authority was, open the .PASS file in a text editor to find out what 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 are named: NewCA.crt and NewCA.key .
Select the imported certificate and view the certificate detail.
P a g e | 77 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 2
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 | 78 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 2
4. Next go to UTM Security Profiles > Antivirus > Profile, and select the default profile. Confirm HTTP virus scanning is enabled as follows:
Modify the outbound firewall policy and enable the default antivirus profile and enable SSL inspection.
. 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 and make sure the profiles are properly enabled on the correct Firewall policy.
P a g e | 79 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 2
6. On the Student FortiGate unit, change the SSL decryption certificate to the one that was loaded 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 the certificate 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 rid of the self signed certificate warning you will need to load the 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 2 of exercise 1) on the Authority tab and allow it to identify websites.
P a g e | 80 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 2
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 browser you can also access the GUI of the FortiGate device without any warning at this point. The certificate is valid for the destination you are visiting (assuming you entered the correct IP information in the request) and the organization that signed it is now in the browsers list of known Certificate Authorities. FortiGate units have multiple interfaces. In NAT mode each one has a different IP address so you need to either setup DNS so you can access the FortiGate device by name (and use a hostname in your certificate), or create a certificate that is valid for multiple IP addresses. Separate browsers use separate certificate repositories. This means that custom CAs must be loaded into them independently.
P a g e | 81 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention
This lab will demonstrate how to use data leak prevention rules and sensors to block the transmission 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
Estimated time to complete this lab: 55 minutes
P a g e | 82 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention Exercise 1
1. Select Security Profiles > Data Leak Prevention > File Filter and review the file filter called all_executables 1.
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 works by examining the layout of the file. Not all file types has a strict design so many cannot be identified in this fashion.
2. From the GUI on the Student FortiGate device, go to Security Profiles > Data Leak Prevention > Sensor. Create a sensor called Training (Click Create New in the upper righthand corner of the Edit DLP Sensor window.)
3. In the Edit DLP Sensor window, create a new rule that uses the default file filter all_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 sensor called Training.
firewall to enable the DLP
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 the desktop of the virtual Windows 2003 Server. Enter the email address of a recipient along with your own email address in the appropriate fields then click Upload. 7. From the GUI on the Student FortiGate device, locate the Forward Traffic log and locate entry with a blocking security action for this attempted data leak. .
P a g e | 83 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention Exercise 1
8. Right-click the putty.exe file and select Add to “putty.7z” to save it as a .7z compressed file type.
9. Return to the sendspace web page and attempt to transfer the zipped file putty.7z. The file will 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 | 84 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention Exercise 1
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 “puttypassword.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 will match all encrypted files and not just encrypted executables. Filter:
Files
Encrypted
Enable
Examine the Following services:
HTTP
Action:
Block
14. Return to the sendspace web page and attempt to transfer the encrypted zipped file “puttypassword.7z”. This time the file will be blocked.
P a g e | 85 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention Exercise 2
1. Create a new DLP filter in the Training DLP sensor with the following details: Filter:
Files
Containing:
Credit Card #
Examine the Following services:
HTTP
Action:
Block
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 faster detection. The patterns detectable are Visa, Mastercard or American Express, Diner’s Club, Discover, JOB
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 in Resources\Module19. Enter the email address of a recipient along with your own email address in the appropriate fields then click Upload. The file will appear to upload, then a DLP warning message will get displayed (or a reset if flow based inspection was used). 4. Edit the Training DLP sensor and change the action for the credit card file filter to Quratine IP,On the sendspace.com web site, attempt to send the creditcard.txt file once again. The file download will be blocked.
Notice: If you try to visit other web sites now you will be blocked and a replacement message appears with a block message.
5. From the GUI on the Student FortiGate device, go to User & Device > Monitor > Banned User and locate the banned entry in the list. 6. Select and delete the banned entry.
P a g e | 86 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention Exercise 3
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 2003 Server desktop. 2. From the GUI on the Student FortiGate device, go to Security Profiles > Data Leak Prevention > Document Fingerprinting. In the Manual Document Fingerprints section, upload a new document to fingerprint. Click Create New and locate the configuration file on the Windows 2003 Server that you created 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 will be 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 file download 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 each part. Changes in one section do not affect all checksums. The default settings allow for a single chunk checksum to trigger a match.
P a g e | 87 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Module 21 Lab 1: Case Study Scenario
The aim of this lab is to introduce students to working with multiple FortiGate device features at once to implement a solution based on customer needs.
− Fulfill the customer’s requirements for the installation, based on the supplied description.
Estimated time to complete this lab: 60 minutes
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/accessing inappropriate material on the Internet Virus scanning is also needed, as is protection from hacking attempts. These functions will need to be integrated with the school’s current Active Directory system and must provide separate access for students and teachers The school also wants to ensure that the students are not permitted to run inappropriate software 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 needs protection. Ideally the solution should be redundant. Key Aspect/Features of Installation: 18 Optional Features: 3
P a g e | 88 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
Appendix A
1. Fortinet Documentation: http://docs.fortinet.com The documentation web site contains all Fortinet manuals, white papers and guides for Fortinet 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 have purchased 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.
P a g e | 89 Course 301 Secured Network Deployment and IPSec VPN 01-50003-0301-20131018-D
