DO NOT REPRINT © FORTINET FortiGate II Student Guide for FortiGate 5.2.1 DO NOT REPRINT © FORTINET FortiGate II Student Guide for FortiGate 5.2.1 Last Updated: 10 June 2015 Fortinet®, FortiGate®, and FortiGuard® are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be trademarks, registered or otherwise, of Fortinet. All other product or company names may be trademarks of their respective owners. Copyright © 2002 - 2015 Fortinet, Inc. All rights reserved. Contents and terms are subject to change by Fortinet without prior notice. No part of this publication may be reproduced in any form or by any means or used to make any derivative such as translation, transformation, or adaptation without permission from Fortinet, Inc., as stipulated by the United States Copyright Act of 1976. DO NOT REPRINT © FORTINET Table of Contents VIRTUAL LAB BASICS ...................................................................................7 Topology..................................................................................................................................8 Logging In ...............................................................................................................................8 Disconnections/Timeouts .............................................................................................................................13 Transferring Files to the VM....................................................................................................13 Using HTML5 Instead of Java ................................................................................................13 Screen Resolution ...................................................................................................................14 International Keyboards ..........................................................................................................14 Troubleshooting Tips ..............................................................................................................15 INITIALIZING THE LAB ...................................................................................17 Basic Network Settings ...........................................................................................................17 ROUTING......................................................................................................18 Lab 1: Router Configuration & Troubleshooting .....................................................................18 Objectives.....................................................................................................................................................18 Time to Complete .........................................................................................................................................18 Exercise 1 Connectivity Troubleshooting ..............................................................................19 Exercise 2 Link Health Monitoring .........................................................................................22 Exercise 3 Failover & Load Balancing Using Static Routing .................................................25 Exercise 4 WAN Link Load Balancing ...................................................................................28 DO NOT REPRINT © FORTINET VIRTUAL DOMAINS .......................................................................................30 Lab 1: Virtual Domains............................................................................................................30 Objectives.....................................................................................................................................................30 Time to Complete .........................................................................................................................................30 Exercise 1 Creating VDOMs & VDOM Objects .....................................................................31 TRANSPARENT MODE ...................................................................................36 Lab 1: Transparent Mode VDOMs ..........................................................................................36 Objectives.....................................................................................................................................................36 Time to Complete .........................................................................................................................................36 Transparent Mode Topology ........................................................................................................................36 Exercise 1 Transparent VDOMs ............................................................................................37 Exercise 2 Inter-VDOM Links.................................................................................................38 HIGH AVAILABILITY ......................................................................................41 Lab 1: High Availability............................................................................................................41 Objectives.....................................................................................................................................................41 Time to Complete .........................................................................................................................................41 HA Topology.................................................................................................................................................41 Exercise 1 Configuring HA & Observing Failover ..................................................................42 Exercise 2 Configuring a Non-Synchronizing HA Management Port ....................................45 ADVANCED IPSEC VPN ................................................................................47 Lab 1: Advanced IPsec VPN ..................................................................................................47 Objectives.....................................................................................................................................................47 Time to Complete .........................................................................................................................................47 Exercise 1 Configuring an IPsec VPN ...................................................................................48 Exercise 2 Configuring a Redundant IPsec VPN ..................................................................51 Lab 2: IPsec VPN with FortiClient...........................................................................................53 Objectives.....................................................................................................................................................53 Time to Complete .........................................................................................................................................53 DO NOT REPRINT © FORTINET Exercise 1 Configuring the FortiGate as a VPN Gateway .....................................................54 Exercise 2 Configuring and Testing FortiClient .....................................................................56 INTRUSION PREVENTION SYSTEM ..................................................................58 Lab 1: Intrusion Prevention System ........................................................................................58 Objectives.....................................................................................................................................................58 Time to Complete .........................................................................................................................................58 Exercise 1 Blocking Known Exploits ......................................................................................59 Exercise 2 Mitigating a DoS Attack........................................................................................62 Exercise 3 Creating Custom Signatures ................................................................................63 FORTINET SSO ............................................................................................64 Lab 1: Fortinet Single Sign On ................................................................................................64 Objectives.....................................................................................................................................................64 Time to Complete .........................................................................................................................................64 Exercise 1 Installing FSSO on a Windows Server ................................................................65 Exercise 2 Configuring FSSO on FortiGate ...........................................................................69 Exercise 3 Testing FSSO On Authentication.........................................................................71 CERTIFICATE OPERATIONS ...........................................................................72 Lab 1: Certificate Operations ..................................................................................................72 Objectives.....................................................................................................................................................72 Time to Complete .........................................................................................................................................72 Exercise 1 Creating a Certificate Request.............................................................................73 Exercise 2 SSL Deep Inspection ...........................................................................................81 DATA LEAK PREVENTION..............................................................................84 Lab 1: Data Leak Prevention ..................................................................................................84 Objectives.....................................................................................................................................................84 Time to Complete .........................................................................................................................................84 DO NOT REPRINT © FORTINET Exercise 1 Blocking Files by Type .........................................................................................85 Exercise 2 Quarantining a User that is Leaking Sensitive Data ............................................87 Exercise 3 DLP Fingerprinting ...............................................................................................88 IPV6 ............................................................................................................90 Lab 1: IPv6 Transition Technologies ......................................................................................90 Objectives.....................................................................................................................................................90 Time to Complete .........................................................................................................................................90 Exercise 1 IPv6 Setup............................................................................................................91 Exercise 2 NAT64 .......................................................................................................................................93 Exercise 3 Using IPsec to Tunnel IPv6 over an IPv4 Network ....................................................................94 APPENDIX A: ADDITIONAL RESOURCES........................................................97 APPENDIX B: PRESENTATION SLIDES............................................................98 Module 11: Routing .................................................................................................................99 Module 12: Virtual Domains ....................................................................................................143 Module 13: Transparent Mode ................................................................................................174 Module 14: High Availability ....................................................................................................190 Module 15: Advanced IPsec VPN...........................................................................................229 Module 16: Intrusion Prevention System ................................................................................260 Module 17: FSSO....................................................................................................................302 Module 18: Certificate-Based Operations ...............................................................................327 Module 19: Data Leak Prevention ..........................................................................................372 Module 20: Diagnostics...........................................................................................................392 Module 21: Hardware Acceleration.........................................................................................433 Module 22: IPv6 ......................................................................................................................476 DO NOT REPRINT © FORTINET Virtual Lab Basics Topology Virtual Lab Basics In this class, you will use a virtual lab for hands-on exercises. This section explains how to connect to the lab and its virtual machines. It also shows the topology of the virtual machines in the lab. Note: If your trainer asks you to use a different lab, such as devices physically located in your classroom, please ignore this section. This applies only to the virtual lab accessed through the Internet. If you do not know which lab to use, please ask your trainer. FortiGate II Student Guide 7 DO NOT REPRINT © FORTINET Virtual Lab Basics Topology Topology port2 10.200.1.241 FortiManager WIN-LOCAL 10.0.1.10 FortiAnalyzer port1 10.0.1.241 port1 10.0.1.210 port3 10.200.1.210 10.0.1.254/24 port3 port2 10.200.2.1/24 LOCAL port1 10.200.1.1/24 10.200.2.254 eth2 LINUX 10.200.1.254 eth1 eth4 10.200.4.254 eth3 10.200.3.254 10.200.4.1/24 port5 REMOTE 10.200.3.1/24 port4 eth0 WIN-REMOTE 10.0.2.10 port6 10.0.2.254/24 Logging In 1. Run the System Checker. This will fully verify both: compatibility with the virtual lab environment's software, and that your computer can connect It can also diagnose problems with your Java Virtual Machine, firewall, or web proxy. Use the URL for your location. North America/South America: https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-West FortiGate II Student Guide 8 DO NOT REPRINT © FORTINET Virtual Lab Basics Logging In Europe/Middle East/Africa: https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe Asia/Pacific: https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC If a security confirmation dialog appears, click Run. If your computer successfully connects to the virtual lab, the result messages for the browser and network checks will each display a check mark icon. Continue to the next step. If a browser test fails, this will affect your ability to access the virtual lab environment. If a network test fails, this will affect the usability of the virtual lab environment. For solutions, either click the Support Knowledge Base link or ask your trainer. 2. With the user name and password from your trainer, log into the URL for the virtual lab. Either: FortiGate II Student Guide 9 DO NOT REPRINT © FORTINET Virtual Lab Basics Logging In https://remotelabs.training.fortinet.com/ https://virtual.mclabs.com/ 3. If prompted, select the time zone for your location, then click Update. This ensures that your class schedule is accurate. 4. Click Enter Lab. A list of virtual machines that exist in your virtual lab should appear. FortiGate II Student Guide 10 DO NOT REPRINT © FORTINET Virtual Lab Basics Logging In From this page, you can access the console of any of your virtual devices by either: clicking on the device’s square, or selecting System > Open. FortiGate II Student Guide 11 DO NOT REPRINT © FORTINET Virtual Lab Basics Logging In 5. Click K2-Win-Student to open a connection to that server. A new window should open within a few seconds. (Depending on your account’s preferences, the window may be a Java applet. If this fails, you may need change browser settings to allow Java to run on this web site. You also may need to review and accept an SSL certificate.) Depending on the virtual machine, the applet provides access to either the GUI or a text-based CLI. Connections to Windows machines will use a Remote Desktop-like GUI. The applet should automatically log in, then display the Windows desktop. For most lab exercises, you will connect to this VM. FortiGate II Student Guide 12 DO NOT REPRINT © FORTINET Virtual Lab Basics Transferring Files to the VM Disconnections/Timeouts If your computer’s connection with the virtual machine times out or if you are accidentally disconnected, to regain access, return to the initial window/tab that contains your session’s list of VMs and open the VM again. If your session frequently times out or does not connect, ask your instructor. Transferring Files to the VM When using the Java applet to connect to a VM, you can drag-and-drop files from your computer to the VM. For example, if you have a FortiGate configuration file that you want to upload to your lab VM, you could create it on your computer, then drag it into the Java application window that is connected to the Windows VM. Usually the destination folder is C:\Uploads. Alternatively, if you store files in a cloud service such as Dropbox or SugarSync, you can use the web browser to download them to your VM instead. Using HTML5 Instead of Java When you open a VM, your browser may download and use a Java application to connect to the virtual lab’s VM. This means that Java must be installed, updated, and enabled in your browser. Alternatively, you can use HTML5 instead. Click the Settings button, then select Use Java Client. Click Save & Disconnect, then log in again. (To use this preference, your browser must allow cookies.) FortiGate II Student Guide 13 DO NOT REPRINT © FORTINET Virtual Lab Basics Screen Resolution When connecting to a VM, your browser should then open a display in a new window or tab. Screen Resolution Some Fortinet devices' user interfaces require a minimum screen size. In the Java client, to configure the screen resolution, click the arrow at the top of the window. In the HTML 5 client, to configure screen resolution, open the System menu. International Keyboards If characters in your language don’t display correctly, keyboard mappings may not be correct. FortiGate II Student Guide 14 DO NOT REPRINT © FORTINET Virtual Lab Basics Troubleshooting Tips To solve this in the HTML 5 client, open the Keyboard menu at the top of the window. Choose to either display an on-screen keyboard, or send text from your computer to the VM's clipboard. To solve this in the Java client, copy and paste between your computer and the Java applet. This sends special characters or combinations using the keyboard icon at the top of the applet window. Troubleshooting Tips If the HTML 5 client does not work, try the Java client instead. Remembering this preference requires that your browser allow cookies. Do not connect to the virtual lab environment through a low-bandwidth or high-latency connection, including VPN tunnels or wireless such as 3G or Wi-Fi. For best performance, use a stable broadband connection such as a LAN. Do not disable or block Java applets. On Mac OS X since early 2014, to improve security, Java has been disabled by default. In your browser, you must allow Java for this web site. On Windows, if the Java applet is allowed and successfully downloads, but does not appear to launch, you can open the Java console while troubleshooting. To do this, open the Control Panel, click Java, and change the Java console setting to be Show console. Network firewalls can also block Java executables. Note: JavaScript is not the same as Java. FortiGate II Student Guide 15 DO NOT REPRINT © FORTINET Virtual Lab Basics Troubleshooting Tips Prepare your computer's settings: o Disable screen savers o Change the power saving scheme so that your computer is always on, and does not go to sleep or hibernate If disconnected unexpectedly from any of the virtual machines (or from the virtual lab portal), please attempt to reconnect. If unable to reconnect, please notify the instructor. If during the labs, particularly when reloading configuration files, you see a message similar to the one shown below, the VM is waiting for a response to the authentication server. To retry immediately, go to the console and enter the CLI command: exec update-now FortiGate II Student Guide 16 DO NOT REPRINT © FORTINET Initializing the Lab Basic Network Settings Initializing the Lab Basic Network Settings Before some exercises, you must upload prerequisite configuration files. They contain objects and settings required by the exercises. To do this, you must be able to connect to that VM through your lab network. This means that the VM must already have basic network settings, such as an IP address that you can connect to. If you have just attended FortiGate I, during that course, you have already done this. Otherwise, configure basic network settings now. (The Student and Remote FortiGate may have been instantiated from an unconfigured VM image.) 1. Connect to the console of the Student FortiGate. (To do this, in the virtual lab applet, go to Operations > Connect to Secondary > Student.) Enter the CLI commands to configure port3. 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. (In the virtual lab applet, go to Operations > Connect to Secondary > Remote.) Enter the CLI commands to configure port4 and a default gateway. 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 FortiGate II Student Guide 17 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Routing Lab 1: Router Configuration & Troubleshooting In this lab, you will configure the router settings and try scenarios to learn how FortiGate decides to route packets. You will also troubleshoot and diagnose routing misconfigurations. Objectives Students will complete the following tasks: Implement routing failover by using link health monitors Balance the traffic among multiple links by WAN link load balancing and equal cost multipath (ECMP) Override static routes with policy routes Diagnose routing issues Time to Complete Estimated: 40 minutes FortiGate II Student Guide 18 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Exercise 1 Connectivity Troubleshooting From the Student Windows server you will connect to an external web site (or http://10.200.3.254/) and observe the output of the diagnostic commands. Note that you must reload the web page for each command tested in the steps below. Initializing the Configuration 1. From the Win-Student computer, go to the Remote FortiGate's GUI: http://10.200.3.1/ Log in as the account named admin. Leave the password blank. 2. Restore the configuration file that is required by this lab: Resources\Routing\Remote\remote-routing.conf FortiGate will reboot and load is new configuration. 3. Log on to the GUI on the Student FortiGate's GUI: http://10.0.1.254/ Log in as the account named admin. Leave the password blank. 4. Restore the configuration file that is required by this lab: Resources\Routing\Student\\student-routing.conf The FortiGate will reboot and load its new configuration. Note: Upon reboot, the console may show a message similar to this: waiting for authentication This can occur if the initial request for license authentication did not succeed. To force an immediate license authentication retry, enter: execute update-now Performing a Filtered Packet Capture 5. Open an SSH client such as PuTTY. Connect to the CLI of the Student FortiGate. 6. Start a packet capture. This will record packets that ingress/egress from FortiGate interfaces, if they match the filter that you set. Capture only packets with a source address of 10.0.1.10 (the Windows server) and the destination port number of 80, the IANA standard port number for HTTP. This focuses output on your interest, ignoring irrelevant traffic. diagnose sniffer packet any 'host 10.0.1.10 and port 80' 4 7. Open a web browser and go to any web site. (Notice that HTTPS-encrypted web sites use port 443 instead of port 80, so your filtered packet capture won't capture traffic to secure sites such as https://www.twitter.com/.) Observe the output. STUDENT # diagnose sniffer packet any 'host 10.0.1.10 and not port 22' 4 FortiGate II Student Guide 19 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting 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 This is the three-way TCP handshake complete and the first exchange of data (psh). Notice that because of the NAT action, we do not see the traffic on the outgoing interface. Tracing the Packet Processing on FortiGate 8. Use a filter to record firewall policy actions for only packets that match the specific IP address and service. diagnose debug flow filter clear diagnose debug flow filter addr 10.0.1.10 diagnose debug flow filter port 80 diagnose debug flow show console enable diagnose debug flow show function enable diagnose debug enable diagnose debug flow trace start 5 Tip: Usually, it is better to filter by address and port, not source/destination address nor source/destination port. Otherwise, you will only capture traffic in one direction – not both forward and reply. 9. Refresh the web page to trigger more traffic. To do this, either click the Refresh button or press the F5 key. You should see packets captured such as these. First, FortiGate receives the client's SYN signal on the ingress interface. id=20085 trace_id=13 func=print_pkt_detail line=4368 msg="vd-root received a packet(proto=6, 10.0.1.10:65229->10.200.3.254:80) from port3. flag [S], seq 4030988021, ack 0, win 8192" FortiGate allocates a new ID in the session table to track this session's states. id=20085 trace_id=13 func=init_ip_session_common line=4517 msg="allocate a new session-000003fe" FortiGate II Student Guide 20 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting FortiGate performs a gateway lookup. If this doesn't change (for example, due to ECMP), then FortiGate will do this only once for each session, at the start. id=20085 trace_id=13 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.200.1.254 via port1" FortiGate performs a firewall policy lookup. id=20085 trace_id=13 func=fw_forward_handler line=671 msg="Allowed by Policy-1: SNAT" Source NAT (SNAT) is applied. (Notice that this is after routing.) id=20085 trace_id=13 func=__ip_session_run_tuple line=2518 msg="SNAT 10.0.1.10->10.200.1.1:65229" The server replies with SYN ACK. id=20085 trace_id=14 func=print_pkt_detail line=4368 msg="vd-root received a packet(proto=6, 10.200.3.254:80->10.200.1.1:65229) from port1. flag [S.], seq 2497669735, ack 4030988022, win 5840" For the reply traffic, FortiGate looks for, and finds, an existing matching session ID. (It does not require a separate policy for reply traffic.) id=20085 trace_id=14 func=resolve_ip_tuple_fast line=4427 msg="Find an existing session, id-000003fe, reply direction" Destination NAT (DNAT) is applied to reply traffic, the inverse of SNAT for initiator traffic. id=20085 trace_id=14 func=__ip_session_run_tuple line=2532 msg="DNAT 10.200.1.1:65229->10.0.1.10:65229" FortiGate performs a gateway lookup for the reply packet. id=20085 trace_id=14 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.0.1.10 via port3" Tip: For most connectivity issues, exec ping, exec traceroute, and the diag debug flow command provide enough information. To help you troubleshoot more complex problems, you can combine information from diagnose debug flow with other commands, such as diag sniffer packet and diag debug application. 10. In a group discussion with your instructor, discuss the output of these commands. When would you use a packet capture instead of a processing flow trace? Even if the LAN has only one client, what irrelevant packets might the packet capture show if you did not filter the output? In a real network, why should you configure your SSH client to save output to a text file, instead of reading it in the window, as each packet is recorded? In a real network, why should you disable packet capture and packet flow as soon as you are done? FortiGate II Student Guide 21 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Exercise 2 Link Health Monitoring When there are multiple paths to the same destination – for example, if you have redundant ISP connections – you can use a link health monitor to provide failover. To monitor viability of each path to an upstream device, FortiGate sends a signal to that destination, and listens for a reply. Often, you'll configure FortiGate to use ICMP type 8 (ping), but it also supports UDP echo, TCP echo and HTTP. If the device fails to respond after the number of retries that you have configured, then FortiGate removes static routes associated with that gateway from its routing table. When you configure FortiGate as part of a site-to-site VPN, the target is often the VPN’s remote gateway. This helps to detect dead tunnels. 1. In this lab, the Student FortiGate has 2 link health monitors. From the GUI on the Student FortiGate device, go to Router > Static > Settings. Verify the link health monitor configuration. Refer to Topology in this document to verify each FortiGate’s IP addresses. First Entry: Interface: port1 Gateway IP: 10.200.1.254 Server: 10.200.3.1 Second Entry: Interface: port2 Gateway IP: 10.200.2.254 Server: 10.200.4.1 2. From the CLI of the Student FortiGate, start a packet capture: diagnose sniffer packet any 'icmp' 4 Now you should observe the request/response traffic on port1, but there is no response on port2. This is because of the Remote FortiGate’s current configuration. To stop the packet capture, press Ctrl + C. 3. From the GUI on the Remote FortiGate, go to Router > Static > Settings. Click Create New and configure these 2 link health monitor objects: First: Name: Port4 Interface: port4 Gateway 10.200.3.254 FortiGate II Student Guide 22 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Health Check Enabled Probe Type: Ping Server: 10.200.1.1 Probe Interval(s) 5 Failure Threshold 5 Recovery Threshold 5 HA Priority 1 Update Routing Table Enabled Bring Down (Up) Interface Disabled Second: Name: Port5 Interface: port5 Gateway 10.200.4.254 Health Check Enabled Probe Type: Ping Server: 10.200.2.1 Probe Interval(s) 5 Failure Threshold 5 Recovery Threshold 5 HA Priority 1 Update Routing Table Enabled Bring Down (Up) Interface Disabled 4. From the CLI of the Student FortiGate, start a packet capture again: diagnose sniffer packet any 'icmp' 4 Output should now show both the local probe, and the echo request/reply on port2. By adding the link health monitor entry, you created a route back to this source in the kernel’s routing table. Therefore FortiGate’s reverse path forwarding (RPF) check now accepts these packets. FortiGate II Student Guide 23 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting 5. View the gateway detection entries in the kernel routing table. Notice the destination and gateway addresses. # 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) FortiGate II Student Guide 24 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Exercise 3 Failover & Load Balancing Using Static Routing 1. Currently routing is set up for failover. The Student FortiGate has these routes: 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 Remote FortiGate uses the same method: it implements a failover route by giving the second one a higher administrative distance. FortiGate uses the route with a smaller distance, unless it is unavailable (and therefore removed from the routing table). Then it loads and uses the second route. On the Student FortiGate, verify the routing table: get router info routing-table all You should observe that there is only one default route. 2. Examine the database or routes: get router info routing-table database You should observe that the second default route exists, but is not currently a selected route. 3. On the Win-Student computer, open a web browser. Execute the same commands used above from the CLI on the Remote FortiGate device. You should observe a similar configuration. Stop and Think When will the second default route, listed in the database, be used? If the primary link fails, FortiGate will use the redundant path (second default route). Link failure could be if you accidentally unplug the network cable, or if the link health monitor associated with that gateway detects that the path is broken. 4. On the Win-Student computer, open a web browser. Try to connect to the GUI of the Remote FortiGate through port5. http://10.200.4.1/ You should observe that this connection fails. This is because the Remote FortiGate has no route back to the source on port4. Only a route back to the link health monitor exists. Therefore 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. 5. On both the Student and Remote FortiGate, go to Router > Static > Static Routes. On the Student FortiGate, edit port2 and set the distance to 10. On the Remote FortiGate, edit port5 and set the distance to 10. 6. Verify the routing table and route database: get router info routing-table all FortiGate II Student Guide 25 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting get router info routing-table database You should observe that the second route is now loaded into the routing table. 7. On the Win-Student computer, open a web browser. Try again to connect to the GUI of the Remote FortiGate through port5: http://10.200.4.1/ The connection should succeed now. 8. We now have a multi-path configuration: there are 2 available default routes, equally prioritized. The priority is not used/visible in the routing table, but it’s in the forwarding information base (FIB). Stop and Think What is the difference between the routing table vs. the FIB? FortiGate’s routing process generates the FIB. It is loaded into RAM, and the table that FortiGate actually uses to look up where to forward the packet. Usually, this lookup occurs when FortiGate receives the first packet in a session. It can be useful to think of the routing table as the management plane and the FIB as the forwarding plane. HA shows this difference. On the primary, both the management plane and forwarding plane exist. On the secondary, only the forwarding plane exists. It is derived from the management plane of the primary. By default, the priority is 0, so for multiple static routes to the same destination, ECMP is enabled. FortiOS supports equal cost multi path (ECMP) routing for static, OSPF, and BGP routes. Observe this in the FIB: get router info kernel There should be two entries with destination 0.0.0.0/0. Both entries should have prio=0. 9. By default, ECMP distributes load by using the source hash technique. This means same source IP and same gateway. In our example, because all traffic is coming from the same source address (the Windows server), FortiGate will egress those packets towards 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 FortiGate distributes packets between valid routes, even if they are from the same source IP. (You may see a similar scenario in real networks.) On the Student FortiGate, go to Router > Static > Settings. Set the ECMP load balancing method to Source-Destination IP based. This changes the priority of the static route. 10. On the Win-Student computer, open a web browser. Go to several web sites. 11. On the CLI of the Student FortiGate, verify that the traffic is distributed between the two Internet connections: diagnose sys session filter clear diagnose sys session filter dport 80 diagnose sys session list | grep dev FortiGate II Student Guide 26 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Since these commands output the interface numbers and not their names, you can use the output of the next CLI command to map the interface number to its name: diagnose netlink interface list Alternatively, use this packet capture command to show only TCP packets on port 80 with the SYN flag: diag sniffer packet any 'tcp[13]&2==2 and port 80' 4 12. Sometimes, you do not want to load balance all traffic. Some hosts and/or protocols may require a specific gateway. To do this, you can use policy-based routing, which takes precedence over the static routing table. Create a policy route to force all outgoing HTTPS traffic on the Student FortiGate to use the gateway 10.200.2.254. Go to Router > Static > Policy Routes. Click Create New and use these settings: Protocol: 6 (TCP) Incoming Interface: port3 Destination Ports: From: 443 To: 443 Action Forward Traffic Outgoing Interface: port2 Gateway Address: 10.200.2.254 Note: Link health monitoring also affects policy routes as well as static routes, so if these do not work, check those settings. 13. Performing a packet capture while connecting to an HTTPS web site: diagnose sniffer packet any 'port 443' 4 For example, from the web browser on the Windows server, connect to: https://mail.google.com/ Alternatively, you can use https://10.200.3.254/ as a target while running the packet capture: diagnose sniffer packet any 'host 10.200.3.254' 4 Verify that your policy-based routes are being used. FortiGate II Student Guide 27 DO NOT REPRINT © FORTINET Routing Lab 1: Router Configuration & Troubleshooting Exercise 4 WAN Link Load Balancing In the previous exercise, you configured load balancing using two static routes with the same distance and priority. In this exercise, you will use WAN link load balancing instead. 1. First, access the GUI of the Student FortiGate and delete the following objects: The policy route created in the previous exercise under Static > Static > Policy Routes The two default routes under Static > Static > Static Routes The two firewall policies under Policy & Objects > Policy > IPv4 The two link health monitor objects under Router > Static > Settings 2. Go to System > Network > WAN Link Load Balancing, change the WAN Load Balancing to Source-Destination IP and add two Interface Members. First member: Interfaces: port1 Gateway IP: 10.200.1.254 Second member: Interfaces: port2 Gateway IP: 10.200.2.254 Click on Apply. 3. Go to Router > Static > Static Routes and add this default route: Destination: 0.0.0.0/0.0.0.0 Device: wan-load-balance Distance: 10 Priority: 0 4. Go to Policy & Objects > Policy > IPv4. Create a new firewall policy: Incoming Interface: port3 Source Address STUDENT_INTERNAL Outgoing Interface wan-load-balance Destination Address all Schedule always FortiGate II Student Guide 28 DO NOT REPRINT © FORTINET Services ALL NAT Enabled Routing Lab 1: Router Configuration & Troubleshooting 5. Open a web browser. Go to several web sites. 6. Verify that FortiGate is load balancing traffic between its 2 Internet connections: diagnose sys session filter clear diagnose sys session filter dport 80 diagnose sys session list | grep dev Or: diag sniffer packet any 'tcp[13]&2==2 and port 80' 4 After you run the diag sniffer command, you may need to refresh the web page in order to be able to view the packet capture. Stop and Think How does WAN link load balancing simplify the configuration? If you compare the FortiGate configuration in the previous exercise to the one in this exercise, you will notice that in this case you had to create only one static route and only one firewall policy for both ISPs. In the previous example, you have to create one route and one firewall policy per ISP: 2 routes, and 2 ISPs. If your configuration had more than 2 ISPs, this could mean many routes and firewall policies. So WAN link load balancing could greatly reduce the number of routes and policies that you must manage. FortiGate II Student Guide 29 DO NOT REPRINT © FORTINET Virtual Domains Lab 1: Virtual Domains Virtual Domains Lab 1: Virtual Domains In this lab, you will enable with VDOMs and configure inter-VDOM links. Objectives Use VDOMs to split a FortiGate into multiple virtual units Create an administrative account with the access limited to one VDOM Route traffic between VDOMs by using inter-VDOM links Time to Complete Estimated: 45 minutes FortiGate II Student Guide 30 DO NOT REPRINT © FORTINET Virtual Domains Lab 1: Virtual Domains Exercise 1 Creating VDOMs & VDOM Objects 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 2. Restore the configuration file that is required by this lab: Resources\Virtual-Domains\Student\Student-vdom.conf FortiGate will reboot. 3. Before enabling VDOMs, use the CLI to view the current list of VDOMs. diagnose sys vd list This command shows the configured VDOMs. Notice that there are already VDOMs: the root VDOM, which is the default VDOM for all interfaces vsys_ha which is used for HA vsys_fgfm which is used for FortiManager We will not be discussing them further. However, notice that when we say “enable VDOMs,” technically we really mean that we are enabling you to create more VDOMs. Some VDOMs are actually inherent in FortiOS, and therefore it is not a separate feature that can be completely disabled. 4. On the Student FortiGate, go to System > Dashboard > Status. In the System Information widget, in the Virtual Domain row, click the Enable link. FortiGate will automatically log you out. 5. Log in again. Notice that now, the GUI initially displays the Global Configuration tab. To access the root VDOM, click Virtual Domains which is at the bottom of the GUI’s navigation menu on the left side. 6. Go to Global > VDOM > VDOM. Create and enable a new VDOM in NAT mode called customer. Notice that, after that, the customer VDOM is listed and you can select it from the VDOM list by clicking Virtual Domains in the lower left-hand corner of the GUI. 7. Create an administrator for the customer VDOM. To do this, in Global Configuration, go to Global > Admin > Administrators and create a new administrator: Administrator: customer-admin Type: Regular Password Fortinet Administrator Profile prof-admin Virtual Domain Customer FortiGate II Student Guide 31 DO NOT REPRINT © FORTINET Virtual Domains Lab 1: Virtual Domains Note: After adding the customer VDOM to the list of Virtual Domain, remove the root VDOM from that list so that the new administrator will be able to access only customer, not root. This account will only be able to log in through an interface in the customer VDOM. 8. Put the port3 interface, which connects to the internal network, in the customer VDOM. To do this, go to Global > Network > Interfaces and edit port3. Change the Virtual Domain to customer. Leave the port1 and port2 interfaces in the root vdom. This will provide a separation between the customer VDOM and the VDOM (root) that is providing Internet or external access. This is a common usage scenario. 9. Go to the CLI and look at the routing table for each VDOM: get router info routing-table all Did the CLI reject the command? When VDOMs are enabled, in order to run this command, you must be in the context of your VDOM in order for FortiGate to know which VDOM’s routing table to display. To enter the customer VDOM context, enter: config vdom edit customer Note: Be careful when typing VDOM names with the edit command. VDOM names are case-sensitive, and the edit command can both modify and create. For example, if you enter edit Root, you will not enter the pre-existing VDOM named root. Instead, this will create and enter a new VDOM named Root. 10. Try again to look at the routing table. get router info routing-table all 11. Go to the root vdom to view its routing table: next edit root get router info routing-table all 12. Create an inter-VDOM link to connect the 2 VDOMs. FortiGate II Student Guide 32 DO NOT REPRINT © FORTINET Virtual Domains Lab 1: Virtual Domains On the Student FortiGate, go to Global > Network > Interfaces. Click ▼ next to Create New in the top left corner of the page, then select VDOM link. Create this new VDOM Link: 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 link, notice the 2 inter-VDOM sub-interfaces created and placed within the root and customer VDOMs. These interfaces are named vlink0 and vlink1. They allow communication between both VDOMs. IP addresses are not required on these interfaces, but can help with troubleshooting routing issues (for example, when running an exec traceroute command). 13. In the customer VDOM, the newly created inter-VDOM link’s interface requires a default route. Click Virtual Domains > customer > Router > Static > Static Routes. Create this new route: Destination IP/Mask: FortiGate II Student Guide 0.0.0.0/0 33 DO NOT REPRINT © FORTINET Device: vlink1 Gateway: 10.10.100.1 Virtual Domains Lab 1: Virtual Domains 14. FortiGate also requires a route for the root VDOM to the internal network. Go to Virtual Domains > root > Router > Static > Static Routes. Create this new route: Destination IP/Mask: 10.0.1.0/24 Device: vlink0 Gateway: 10.10.100.2 15. In the root VDOM, create a zone that contains port1 and port2. Go to Virtual Domains > root > System > Network > Interfaces. Click ▼next to Create New and create the new Zone. Assign a name of External and specify port1 and port2 as members. 16. Create a firewall policy to allow traffic from the customer VDOM out to the Internet through the interfaces. While in the root VDOM, go to Policy & Objects > Policy > IPv4 and create a new policy for traffic to External: Incoming Interface: vlink0 Source Address: STUDENT_INTERNAL Outgoing Interface: External Destination Address: All Schedule: Always Service: ALL Action: ACCEPT NAT: Enabled 17. Switch to the customer VDOM. Create another firewall policy that allows traffic from port3 to vlink1: Incoming Interface: port3 Source Address: All Outgoing Interface: vlink1 Destination Address: All Schedule: Always FortiGate II Student Guide 34 DO NOT REPRINT © FORTINET Service: ALL Action: ACCEPT NAT: Disabled Virtual Domains Lab 1: Virtual Domains 18. While in the customer VDOM, go to System > Network > DNS Servers and click Create New to add DNS service on the port3 interface. Interface: port3 Mode: Forward to System DNS 19. Connect to an external web site. Traffic should be flowing through both VDOMs now. From a command prompt on the Win-Student computer, verify the path over the inter-VDOM link: tracert –d 4.2.2.2 20. On the Win-Student computer, log in to the customer VDOM (10.0.1.254) with the user name and password customer-admin. You can access the customer VDOM on port3 because it is a member interface of that VDOM. Navigate through the GUI and examine what the VDOM administrator is allowed to control. Since the customer-admin administrator can access to the customer VDOM only, they will not automatically enter the Global Configuration, nor will they have access to it. The display of the GUI will change as the customer-admin user has access to only the VDOM-specific objects. FortiGate II Student Guide 35 DO NOT REPRINT © FORTINET Transparent Mode Lab 1: Transparent Mode VDOMs Transparent Mode Lab 1: Transparent Mode VDOMs In this lab, you will configure one transparent mode VDOM. To interconnect 2 VDOMs without requiring packets to egress from FortiGate, you will use an inter-VDOM link. Objectives Configure one transparent mode VDOM Time to Complete Estimated: 45 minutes Transparent Mode Topology After you upload the required configurations to each FortiGate, the logical topology will change to this. REMOTE FortiGate inspect VDOM link1 link0 10.200.1.1/24 port3 10.0.1.254/24 port1 Management IP 10.200.1.200/24 STUDENT FortiGate LINUX 10.200.1.254 eth1 eth2 10.200.2.254 root VDOM port2 10.200.2.1/24 WIN-STUDENT 10.0.1.10 eth0 FortiGate II Student Guide 36 DO NOT REPRINT © FORTINET Transparent Mode Lab 1: Transparent Mode VDOMs Exercise 1 Transparent VDOMs 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 2. Restore the configuration file that is required by this lab: Resources\Transparent-Mode\Student\Student-tp.conf FortiGate will reboot. 3. Log in again and go to System > Dashboard > Status. In the System Information widget, in the Virtual Domain row, click the Enable link. FortiGate will automatically log you out. 4. Log in again. Initially, the GUI will display the configuration for Global. 5. 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 FortiGate II Student Guide 37 DO NOT REPRINT © FORTINET Transparent Mode Lab 1: Transparent Mode VDOMs Exercise 2 Inter-VDOM Links 1. In the CLI, create an inter-VDOM link: config global config system vdom-link edit link set type ethernet end end 2. Next, you will move the port1 interface to the inspect VDOM. In the GUI go to Global > Network > Interface and edit the port1 interface. From the Virtual Domain drop-down list select the inspect VDOM. This is only possible because the port1 interface is not referenced by any firewall policies or routing. Also ensure that Ping access is enabled on port1 3. Configure the inter-vdom link interfaces: 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 4. In the GUI go to Global > Network > Interface and review the inter-VDOM link interfaces created above. Note that link0 and link1 are logical interfaces that allow communication between the root and inspect VDOMs. An IP address is only configurable on the NAT/Route mode VDOM interface. 5. Review the new VDOM tree display by selecting Virtual Domains and reviewing the root and inspect VDOMs. FortiGate II Student Guide 38 DO NOT REPRINT © FORTINET Transparent Mode Lab 1: Transparent Mode VDOMs 6. In the inspect VDOM, go to Policy & Objects > Policy > IPv4. Create the following policy to allow traffic between the port1 and link1 interfaces initiated in either direction: Incoming Interface: any Source Address: all Outgoing Interface: any Destination Address: all Schedule: always Service: ALL Action: ACCEPT Enable AntiVirus under Security Profile and select default as the antivirus profile. Click OK to save the change. 7. In the root VDOM, go to Policy & Objects > Policy > IPv4. Create a new policy for port3 to link0: 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 8. To direct traffic from your Windows host to the inspect VDOM, in the root VDOM, go to Router > Static > Static Routes. 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. FortiGate II Student Guide 39 DO NOT REPRINT © FORTINET Transparent Mode Lab 1: Transparent Mode VDOMs 9. Increase the cost of the priority of the port2 default route to 50, so that this is not the preferred route. 10. On the Win-Student computer, verify that your hops are 10.0.1.254 and 10.200.1.254: tracert –d 10.200.3.1 11. Run a continuous ping to 10.200.1.254. 12. Download the EICAR antivirus test file from EICAR’s web site: http://eicar.org 13. Go to Log & Report > Traffic Log > Forward Traffic and find related messages in the root VDOM and a UTM message in the inspect VDOM. 14. From the GUI on the Student FortiGate, go to Global > Dashboard > Status. 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. 15. Click Widget and add the All Sessions widget. Click on Column Settings and add the Virtual Domain field. Try to download the virus again and check that there are sessions reported in each VDOM. FortiGate II Student Guide 40 DO NOT REPRINT © FORTINET High Availability Lab 1: High Availability High Availability Lab 1: High Availability In this lab, you will set up a high availability (HA) cluster of FortiGate devices. You will explore each HA mode and use diagnostic commands to observe FortiGate HA behavior. Objectives Set up an HA cluster using FortiGate devices Interpret diagnostic output Observe HA synchronization and failover Time to Complete Estimated: 45 minutes HA Topology After you upload the required configurations to each FortiGate, the logical topology will change to this. FortiGate REMOTE port3 port1 LINUX 10.200.1.254 eth1 port2 port2 port3 10.0.1.254/24 WIN-STUDENT 10.0.1.10 LAN3 0.0.0.0 FortiGate II Student Guide port1 10.200.1.1/24 STUDENT FortiGate eth0 LAN0 0.0.0.0 41 DO NOT REPRINT © FORTINET High Availability Lab 1: High Availability Exercise 1 Configuring HA & Observing Failover 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Remote, and log in as admin. http://10.200.3.1/ 2. Restore the configuration file that is required by this lab: Resources\High-Availability\Remote\remote-ha.conf. FortiGate will reboot. 3. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 4. Restore the configuration file that is required by this lab: Resources\High-Availability\Student\student-ha.conf. FortiGate will reboot. 5. Open the console for both the Student and Remote FortiGate. This allows you to observe the error messages that FortiGate sends to the console. This sometimes shows useful status change information, such as: slave succeeded to sync external files with master Wait 4 to 5 minutes for each FortiGate to synchronize. To check the status, use this command: diag sys ha showcsum on both Student and Remote. If both FortiGates are synchronized, then the checksum will match. The Student FortiGate’s configuration has these 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’s configuration has these HA settings: config system ha set mode a-a FortiGate II Student Guide 42 DO NOT REPRINT © FORTINET High Availability Lab 1: High Availability set priority 100 set group-name training set password Fortinet set session-pickup enable set hbdev port2 50 end 6. Verify that the HA cluster has been established: get system status View the Current HA mode line. Notice that the Student FortiGate is a-a master, and the Remote FortiGate device is a-a backup. 7. Connect to the GUI of the cluster’s primary FortiGate (http://10.0.1.254/). Go to System > Config > HA to v status information of the cluster members. 8. Go to a few pages from several web sites, then use the CLI to see the session table entries of both the Student and Remote FortiGate, and examine to see which sessions are synchronized: 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 or Telnet instead of the console, use this command instead to access the secondary CLI via the primary’s HA link: execute ha manage <id> (use ? to list the id values) exit (to return to the primary) The primary’s session table should be larger than the secondary’s. This is because all management traffic is with the primary; all non-TCP traffic is handled by the primary, too. By default, only TCP sessions destined for proxy inspection are load balanced between the primary and secondary FortiGate. 9. To test fail-over, view a long YouTube video. During this, run a continuous ping to a public IP address. To trigger a failover, reboot the Student FortiGate device by entering the command: execute reboot 10. Because of the failover, the Remote FortiGate device is now the primary processor of traffic. Use the CLI to verify this: get sys stat 11. When the Student FortiGate finishes rebooting and rejoins the cluster, does it rejoin as the secondary, or resume its initial role of primary? To see the status of all member FortiGates, use the command: FortiGate II Student Guide 43 DO NOT REPRINT © FORTINET High Availability Lab 1: High Availability diag sys ha status You should observe the Student FortiGate rejoins the cluster as a secondary. It has lost its role of primary. 12. From the Remote FortiGate, execute this command to make the Student FortiGate become the primary again: diagnose sys ha reset-uptime By resetting the HA uptime, you are forcing the cluster to use the next value to determine which FortiGate has priority for becoming the primary. You should observe that the Student FortiGate is now primary. 13. Check the system uptime to see that this remains unchanged: get sys perf status Notice that each FortiGate’s FortiOS uptime is not reset, only its HA uptime. 14. The HA synchronization process is responsible for FGCP packets that communicate cluster status and build the cluster. You can observe this process. On the Student FortiGate, enter: diagnose debug enable diag debug application hasync 0 diagnose debug application hasync 255 On the Remote FortiGate, enter: execute reboot On the Student FortiGate, observe the output while the secondary reboots and starts communicating with the cluster. To stop the debug output on the Student FortiGate, press the up-arrow key twice, selecting the command before last (in this case diag debug app hasync 0), then press the Return key. FortiGate II Student Guide 44 DO NOT REPRINT © FORTINET High Availability Lab 1: High Availability Exercise 2 Configuring a Non-Synchronizing HA Management Port In this exercise, you will configure a spare interface of the cluster to be a non-synchronizing management interface. This will allow both FortiGate to be reachable for SNMP and management purposes only. 1. On the Student FortiGate (normally the primary), go to System > Config > HA. Edit the Student FortiGate. Select Reserve Management Port for Cluster Member and choose port7. Click Apply. Port7 connects to the same LAN segment as port3. 2. Go to System > Network > Interface. Configure port7 with the address 10.0.1.253/24. Note: Even though this address overlaps with port3, and would not be normally allowed (FortiGate does not allow overlapping subnets), it is allowed here because the interface now has a special purpose, and is excluded from the routing table. Enable HTTPS, SNMP and PING access. 3. Verify connectivity to port7 by browsing to: https://10.0.1.253 4. Configure the secondary. Go to the CLI of the Remote FortiGate device. Verify that the nonsynchronizing interface settings have been synced to the secondary. show system ha Look for ha-mgmt-status and ha-mgmt-interface. These should be set. Notice that you have the option for ha-mgmt-gateway too. 5. From the CLI of the Remote FortiGate device, to verify that port7 has no configuration, enter: show sys int 6. Configure port7 via the CLI: conf sys int edit port7 set ip 10.0.1.252/24 set allowaccess https ping snmp end 7. Verify connectivityto port7 by browsing to: https://10.0.1.252/ Each device in the cluster now has its own management IP address for monitoring purposes. 8. Before proceeding to the next lab, connect to https://10.0.1.254/. Go to System > Config > HA. FortiGate II Student Guide 45 DO NOT REPRINT © FORTINET High Availability Lab 1: High Availability For the Remote, click the Disconnect from cluster icon. This will remove it as an HA cluster member. 9. When prompted, configure port3 with the IP address 10.0.1.251/24. Log in to the disconnected FortiGate’s new IP address, then enable HTTP administrative access. STUDENT # execute ha disconnect FGVM010000006759 port3 10.0.1.251 255.255.255.0 Sending cmd to HA member 0 If after disconnecting the HA you are no longer able to access the Remote FortiGate, you can go to its console and manually configure the port using the following commands: 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 Note: Failure to do the last step will prevent you from doing the next exercise. FortiGate II Student Guide 46 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 1: Advanced IPsec VPN Advanced IPsec VPN Lab 1: Advanced IPsec VPN In this lab, you will configure a more advanced IPsec VPN topology. Objectives Configure redundant VPNs between two FortiGates Time to Complete Estimated: 45 minutes FortiGate II Student Guide 47 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 1: Advanced IPsec VPN Exercise 1 Configuring an IPsec VPN During this lab, you will configure two redundant VPNs between the Student and Remote FortiGates. In this first exercise, you configure the first of those two VPNs. 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Remote, and log in as admin. http://10.200.3.1/ 2. Restore the configuration file that is required by this lab: Resources\Advanced-IPsec-VPN\Remote\remote-ipsec2.conf The Remote FortiGate will reboot. 3. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 4. Restore the configuration file that is required by this lab: Resources\Advanced-IPsec-VPN\Student\student-ipsec2.conf The Student FortiGate will reboot. 5. On the Student FortiGate’s GUI, go to VPN > IPsec > Tunnels. Click Create New. Use the name Remote_1 and select Custom VPN Tunnel. Click Next and configure these settings: Remote Gateway: Static IP Address IP Address: 10.200.3.1 Interface: port1 Method: Preshared Key Pre-shared Key: Fortinet Leave the other settings with their default values and click OK. 6. Go to Router > Static > Static Routes and create this new static route: Destination IP/Mask: 10.0.2.0/24 Device: Remote_1 7. Go to System > Network > Interfaces, and create this new zone: Zone Name: VPN Interface Members: Remote_1 8. Create two firewall policies between port3 and Remote_1, for both directions: FortiGate II Student Guide 48 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 1: Advanced IPsec VPN Incoming Interface: port3 Source Address: STUDENT_INTERNAL Outgoing Interface: VPN Destination Address: REMOTE_INTERNAL Schedule: Always Service: ALL Action: ACCEPT NAT: Disable Incoming Interface: VPN Source Address: REMOTE_INTERNAL Outgoing Interface: port3 Destination Address: STUDENT_INTERNAL Schedule: Always Service: ALL Action: ACCEPT NAT: Disable 9. Given the settings that you have just configured on the Student FortiGate, and the network diagram (located in Topology), complete the other half of the VPN by configuring the Remote FortiGate. On the Remote FortiGate, for the VPN object on port4, use the name Student_1. Remember to also create the static route, the VPN zone, and incoming and outgoing firewall policies. 10. To test the VPN, from a command prompt on the Win-Student computer, ping these IP addresses in the remote network: ping 10.0.2.10 ping 10.0.2.254 Note: FortiGate may not have previously established the VPN. If so, the first two pings will fail while it negotiates and establishes the VPN. 11. From the Student FortiGate, set the source IP address of the ping packets to port3’s IP address (10.0.1.254): FortiGate II Student Guide 49 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 1: Advanced IPsec VPN execute ping-options source 10.0.1.254 Then ping the remote network from the Student FortiGate: execute ping 10.0.2.254 After the test succeeds, change the ping source address back to its default value (automatic): execute ping-options source auto 12. On the Student FortiGate, go to VPN > Monitor > IPsec Monitor. Confirm that the Remote_1 VPN is up. A green arrow should be displayed in the Status column. FortiGate II Student Guide 50 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 1: Advanced IPsec VPN Exercise 2 Configuring a Redundant IPsec VPN In this exercise, you will create the second route-based VPN for redundancy. 1. Repeat the configuration steps of exercise 1, but this time, make the VPN from the Student FortiGate port2 to Remote FortiGate port 5. On the Student FortiGate, for the VPN, use the name Remote_2. On the Remote FortiGate, for the VPN, use the name Student_2. 2. On the Student FortiGate, add this static route: Destination IP/Mask: 10.0.2.0/24 Device: Remote_2 Distance: 20 3. Go to System > Network > Interfaces, and edit the zone VPN. Add the interface Remote_2 to it. 4. On the Remote FortiGate, add this static route: Destination IP/Mask: 10.0.1.0/24 Device: Student_2 Distance: 20 5. Go to System > Network > Interfaces, and edit the VPN zone. Add the interface Student_2 to it. 6. To start testing the VPN fail-over, from the command prompt on the Win-Student computer, run a continuous ping to an IP address in the remote network: ping –t 10.0.2.10 7. On the Student FortiGate, go to System > Network > Interfaces and edit port1. Set the Administrative Status to bring down the interface. Note: Alternatively, you can simulate an upstream device failure by disabling a network interface on the Linux server. To access the Linux server, use PuTTY to connect to 10.200.1.254 via SSH. Log in with the username root and password password. From a command prompt, enter: ifconfig eth3 down The IPsec DPD mechanism should detect that the tunnel is down. To bring up the primary path again, enter: ifconfig eth3 up 8. On the Student FortiGate, observe the session failover: FortiGate II Student Guide 51 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 1: Advanced IPsec VPN diagnose sys session filter dst 10.0.2.10 diagnose sys session list Sample output: session info: proto=1 proto_state=00 duration=676 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 none app_ntf statistic(bytes/packets/allow_err): org=33240/554/1 reply=31500/525/1 tuples=2 orgin->sink: org pre->post, reply pre->post dev=4->16/16->4 gwy=10.0.2.10/10.0.1.10 hook=pre dir=org act=noop 10.0.1.10:1->10.0.2.10:8(0.0.0.0:0) hook=post dir=reply act=noop 10.0.2.10:1->10.0.1.10:0(0.0.0.0:0) misc=0 policy_id=3 auth_info=0 chk_client_info=0 vd=0 serial=00000c20 tos=ff/ff ips_view=0 app_list=0 app=0 dd_type=0 dd_mode=0 total session 1 Observe in the output the name of the VPN used for the session. In the example above, the ICMP traffic is going through the VPN Remote_2, which is the secondary one. 9. On the Student FortiGate, return the Administrative Status of the port1 interface to up. If you brought down the Linux eth3 interface, also bring it back up. Note: Failure to do the last step will prevent you from doing the next exercise. FortiGate II Student Guide 52 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 2: IPsec VPN with FortiClient Lab 2: IPsec VPN with FortiClient In this lab, you will create a dial-up VPN. Objectives Configure an IPsec VPN between the Student FortiGate and a computer with FortiClient installed Time to Complete Estimated: 45 minutes FortiGate II Student Guide 53 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 2: IPsec VPN with FortiClient Exercise 1 Configuring the FortiGate as a VPN Gateway 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Remote, and log in as admin. http://10.200.3.1/ 2. Restore the configuration file that is required by this lab: Resources\Advanced-IPsec-VPN\Remote\remote-ipsec3.conf. The Remote FortiGate device will reboot. 3. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 4. Restore the configuration file that is required by this lab: Resources\Advanced-IPsec-VPN\Student\student-ipsec3.conf. The Student FortiGate device will reboot. 5. On the Student FortiGate, go to VPN > IPsec > Tunnels. Click Create New. Type the name FClient and select the Dialup – FortiClient template. Click Next and configure these settings: Incoming Interface: port1 Authenticated Method: Pre-shared Key Pre-Shared Key: Fortinet User Group: training Click Next. Configure these other settings in the next wizard step: Local Interface: port3 Local Address: STUDENT_INTERNAL Client Address Range: 172.20.1.1-172.20.1.5 Subnet: 255.255.255.0 DNS Server: Use System DNS Enable IPv4 Split Tunnel: Enabled Accessible Networks: STUDENT_INTERNAL Allow Endpoint Registration: Disabled Click Next. Verify that Save Password is enabled, then click Create. The VPN wizard creates not only IPsec Phase 1 and 2, but also a firewall address, named FortiGate II Student Guide 54 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 2: IPsec VPN with FortiClient FClient_range, and two firewall policies to allow VPN traffic both ways. Note: Although you have created a route-based IPsec tunnel, you do not need to add a static route because it is a dial-up VPN. FortiGate will automatically add or remove appropriate static routes to each dial-up peer when their VPNs are established or disconnected. FortiGate II Student Guide 55 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 2: IPsec VPN with FortiClient Exercise 2 Configuring and Testing FortiClient 1. On the Win-Remote computer, double-click the FortiClient icon to start that application. 2. Click the Configure VPN link. Click IPsec and configure these settings: Connection Name: FC_VPN Remote Gateway: 10.200.1.1 Authentication Method: Preshared Key with the password ‘fortinet’ Authentication (XAuth): Save Login Username: student Click Apply, then click Close. 3. To establish the dial-up VPN, enter the password F0rtinet, then click Connect. 4. Wait a few seconds. Open the FortiClient application again. A green checkmark confirms that the tunnel is up: 5. The Win-Remote computer receives a VPN IP address within the 172.20.1.1 - 172.20.1.5 range. Open a command prompt to confirm it: ipconfig /all 6. Display the routing table information: route print Locate the 10.0.1.0/24 network entry in the output. 7. Try to ping both the Win-Student computer (10.0.1.10) and the port3 interface of the Student FortiGate (10.0.1.254). FortiGate II Student Guide 56 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lab 2: IPsec VPN with FortiClient 8. On the Student FortiGate, go to Router > Monitor > Routing Monitor. Find the static route that was automatically added by the FortiGate. 9. Go to VPN > Monitor > IPsec Monitor to view the details of the FClient-0 VPN connection. Notice the Remote Gateway IP address. 10. On the Win-Remote compute, open FortiClient and click Disconnect to bring down the tunnel. FortiGate II Student Guide 57 DO NOT REPRINT © FORTINET Intrusion Prevention System Lab 1: Intrusion Prevention System Intrusion Prevention System Lab 1: Intrusion Prevention System In this lab, you will set up DoS policies and IPS profiles on your FortiGate. You will use a vulnerability scanner. You will also use packet crafting software to attempt to flood one of the FortiGates, then examine the resulting log entries on both FortiGates. Objectives Block attempts to exploit known vulnerabilities Mitigate a DoS attack Interpret attack log entries Diagnose an attack attempt Time to Complete Estimated: 80 minutes FortiGate II Student Guide 58 DO NOT REPRINT © FORTINET Intrusion Prevention System Lab 1: Intrusion Prevention System Exercise 1 Blocking Known Exploits In this exercise, you will block and log some known exploits that the nikto vulnerability scanner will simulate. 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 2. Restore the configuration file that is required by this lab: Resources\Introduction\Student\student-initial.conf The FortiGate will reboot, which automatically will log you out. 3. Log in again. Go to System > Config > Features. In the Security Features dropdown, select Full UTM. (This is required for the GUI to show some things, such as security logs.) 4. Go to Security Profiles > Intrusion Protection. To create a new sensor, click the plus sign (+) in the upper-right corner of the Edit IPS Sensor window. In Name, type LINUX_SERVER, then click OK. In the Edit IPS Sensor window, click Create New. Configure a new IPS filter with these settings: Sensor Type: Filter Based Filter Options Basic Severity: All Target: server OS: Linux Action: Signature Defaults Packet Logging: Enabled 5. Go to Policy & Objects > Policy > IPv4. Edit the port3 → port1 firewall policy. In the Security Profiles section, set IPS to ON, then from the drop-down list, select LINUX_SERVER. 6. On the Win-Student desktop, open a command prompt. Go to the folder for Resources\Intrusion-Prevention-System\nikto-2.1.5: C:> cd \ C:> cd Documents and Setting C:> cd Administrator C:> cd Desktop FortiGate II Student Guide 59 DO NOT REPRINT © FORTINET Intrusion Prevention System Lab 1: Intrusion Prevention System C:> cd Resources C:> cd Intrusion-Protection-System C:> cd nikto-2.1.5 7. Scan the Linux server for vulnerabilities: nikto.pl -host 10.200.1.254 The test will stop automatically once finished. Otherwise, you can use CTRL+C to stop the utility. 8. On the Student FortiGate, go to Log & Report > Security Log > Intrusion Protection. Locate the multiple entries for the attacks generated by nikto. Note: The Security Log menu item will not display if there are no UTM logs. FortiGate will show it after creating logs. After starting the Nikto utility, if this menu item does not display, click the browser’s Refresh button to reload the GUI. If the exploits are not logged, verify: Is the LINUX_SERVER IPS sensor selected in the policy? Is the traffic matching the correct policy? If both are true, but the exploits are still not being logged, ask your instructor for help. 9. Right-click any of the column titles to display the Column Settings dialog. Add the Action field to the display. To move the column to a location that is easier to view, click and drag the column. Note that for some of the attacks discovered by this sensor, in the Action column, the value is detected. This indicates that a signature was matched, but that FortiGate was configured to allow traffic to pass. In the spaces below, write the names for two of the detected signatures. The signature name appears in the Message column of the log. Signature 1: ____________________________________ Signature 2: ____________________________________ 10. Go to UTM Security Profiles > Intrusion Protection > IPS Sensor. Edit the sensor named LINUX_SERVER. Click Create New to add a filter. Set the Type to Specify Signatures. Click in the search field located on the left side of the window (close to the top), then enter the name that you wrote in “Signature 1” from the previous step. Select the signature. Set its Action to Block All, and enable Packet Logging. Repeat this step for the signature that you noted in “Signature 2”. 11. By dragging and dropping in the IPS filter list, move the newly-created signatures above the Default filter. 12. From a command prompt on the Windows server, run the vulnerability scan again: nikto.pl -host 10.200.1.254 13. Go to Log & Report > Security Log > Intrusion Protection. FortiGate II Student Guide 60 DO NOT REPRINT © FORTINET Intrusion Prevention System Lab 1: Intrusion Prevention System Examine the log entries again. Locate log messages which indicate that attacks were blocked. The Status field should contain dropped. This indicates either: a dropped packet, dropped session, or cleared session. FortiGate II Student Guide 61 DO NOT REPRINT © FORTINET Intrusion Prevention System Lab 1: Intrusion Prevention System Exercise 2 Mitigating a DoS Attack In this exercise, add basic flood protection. 1. On the Student FortiGate’s GUI, go to Policy & Objects> Policy > DoS Policy. Create a DoS policy: Incoming Interface: port1 Source Address: all Destination Address: all Service: ALL Anomalies: Threshold for icmp_flood: 200. Status enable Logging enable Action: Block 2. Open an SSH connection and login to the Linux host (10.200.1.254). Enter the username root with a password of password. 3. Use the ping flood option against the external server: ping -f 10.200.1.1 The command options used here will cause the ping utility to run continuously and not wait for replies between ICMP echo requests. FortiGate should block pings when 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. 4. Go to Log & Report > Security Log > Anomaly and examine the logs. Note that the ICMP flood has been blocked; this is indicated by the Status field entry clear_session. Note: You may need to refresh the GUI for the Anomaly menu item to display. 5. From the CLI on the Student FortiGate, 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. When done, in PuTTY, press Ctrl + C to stop the flood, then close the terminal. FortiGate II Student Guide 62 DO NOT REPRINT © FORTINET Intrusion Prevention System Lab 1: Intrusion Prevention System Exercise 3 Creating Custom Signatures 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, create a custom signature to detect the FTP GET command: config ips custom edit "FTP_GET" set severity medium set protocol FTP set log-packet enable set action pass set signature "F-SBID(--name 'FTP Download'; --flow from_client; -pattern RETR;)" end 2. Go to Security Profiles > Intrusion Protection. Edit the LINUX_SERVER sensor created earlier. Create a new filter and set the Sensor Type to Specify Signatures. Select the Custom [FTP_GET] signature located at the top of the list. Set the Action to Reset and enable Packet Logging. 3. Once this has been created, move this filter to the top of the list and click Apply to save the change. 4. On the Student FortiGate device, trace the session: diag sniffer packet any 'port 21' 4 5. From the Win-Student computer, open the FileZilla Client from the desktop. Open the Site manager and connect to the Linux Server entry. Change to the /pub folder on the server and download the file called test.text The connection to the remote host should be closed. Note: When FortiGate resets the TCP connection, FileZilla may show a notification popup a few times. 6. 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: FortiGate II Student Guide 63 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On Fortinet SSO Lab 1: Fortinet Single Sign On In this lab, you will configure Fortinet Single Sign On to enable the FortiGate to collect authentication information from Windows Active Directory. Once users log into the Windows domain, they will not be required to authenticate again to access other web sites. Objectives Configure a collector agent Configure FortiGate to transparently authenticate users using FSSO Monitor the status and operation of FSSO Time to Complete Estimated: 45 minutes FortiGate II Student Guide 64 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On Exercise 1 Installing FSSO on a Windows Server 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 2. Restore the configuration file that is required by this lab: Resources\FSSO\Student\Student-sso.conf FortiGate will reboot. 3. On the Win-Student server, right-click the Fortinet Single Sign On (FSSO) installation file located in Resources\FSSO, then select Run as administrator. This should launch the Fortinet Single Sign On Agent Installation Wizard. Follow the wizard to install the agent on the Win-Student server. 4. When prompted for the Windows server administrator password, enter password: Click Next. 5. In the Install Options window, accept the default settings: Click Next. FortiGate II Student Guide 65 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On 6. Click Install to complete the installation. 7. 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 collector agent Installation. This launches the Domain Controller Agent Installation Wizard. 8. 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. 9. Select the TRAININGAD:trainingAD.training.lab domain to monitor. Click Next. 10. 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. 11. Set the Working Mode to Polling Mode and Check Windows Security Event Logs. FortiGate II Student Guide 66 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On Click Next. 12. In the Win-Student computer, click the windows icon > down arrow. Under the Fortinet section run Configure Fortinet Single Sign-on. 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 the communication between the collector agent and the 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 Users. Click Add, then OK. FortiGate II Student Guide 67 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On Click OK. Click Save & Close to close the Fortinet single sign on agent configuration window. FortiGate II Student Guide 68 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On Exercise 2 Configuring FSSO on FortiGate 1. On the Student FortiGate, go to User & Device > Authentication > Single Sign-On. Create a new entry with these 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. If the trainingad/users group does not appear, it could be an issue with the Windows Firewall on the Win-Student server. Turn off the firewall and then click Apply and Refresh . 2. Begin to monitor the communication between the FSSO collector agent and the FortiGate. Use these CLI commands: diagnose debug en diagnose debug application auth 8256 You will return to this output after you have tested the configuration. 3. Go to User & Device > User > User Groups. Create a new user group: Name: Training Type: Fortinet Single Sign On (FSSO) Add TRAININGAD/USERS as members to the group. 4. Edit the port3 → port1 firewall policy, and configure it with the following settings: Incoming Interface: port3 Source Address STUDENT_INTERNAL Source User(s) Training Outgoing Interface port1 Destination Address all Schedule Always Service ALL Action ACCEPT FortiGate II Student Guide 69 DO NOT REPRINT © FORTINET NAT FortiGate II Student Guide Fortinet SSO Lab 1: Fortinet Single Sign On Enabled 70 DO NOT REPRINT © FORTINET Fortinet SSO Lab 1: Fortinet Single Sign On Exercise 3 Testing FSSO On Authentication 1. On the Win-Student computer, click the Windows button. Click the search icon (magnifying glass) on the top. Search for the name mstsc. Launch Windows Remote Desktop. 2. Enter the remote computer IP address 10.0.1.10: Log in with these credentials: Username: student Password: Fort1net Ignore the error message indicating that the user is not authorized for remote login. The objective of this step is to generate a logon event that the DC agent can capture, without needing to reboot the Win-Student server. 3. Open a web browser on the Win-Student computer. Try to connect to a web site. You should be able to access the Internet without receiving a prompt for user authentication. 4. Observe the output from the diagnose command that is still running in the CLI. 5. Display which users are currently logged on using FSSO: diagnose debug application auth 0 diagnose debug authd fsso list Review the output. You may see two IP addresses for the user named "student" because the Win-Student computer has two NICs. FortiGate II Student Guide 71 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Certificate Operations Lab 1: Certificate Operations In this lab, you will learn the basics of all SSL-based inspection that a FortiGate is capable of performing. You will learn how FortiGate inspects secure traffic, and what encryption it uses. You will also examine the server's certificate to understand its general layout and contents. Objectives Create different certificate signing requests (CSRs) Use OpenSSL to sign a CSR Load signed certificates into the FortiGate Use certificates for various purposes including administrative use (GUI access), SSL VPN, and deep inspection Time to Complete Estimated: 30 minutes FortiGate II Student Guide 72 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Exercise 1 Creating a Certificate Request This lab was designed and tested using Firefox and XCA. Steps may vary if you use another browser and/or CA. 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 2. Restore the configuration file that is required by this lab: Resources\Certificate-Operations\student\student-certificate.conf. FortiGate will reboot. 3. Log in again 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 can enter whatever information you like into the rest of the fields. Once created, the certificate will display in the GUI showing a status of PENDING. 4. Select the newly created certificate and download it. 5. Open a new browser tab. Using HTTPS, connect to the Student FortiGate’s GUI: https://10.0.1.254 FortiGate II Student Guide 73 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations You should receive an error message. Don’t add an exception, nor log in yet. Expand the technical details. You should see there are actually 2 errors. The certificate is self-signed (not issued by a known certificate authority). The certificate is only valid for a specific location (The VM serial number that was included with the VM license file). Note: If your browser does not display a warning, then you have previously added an exception. To restore the error, remove the exception from your browser. To delete the certificate exception in Firefox, click the button with three lines on the top right, then select Options. Select the Advanced tab, then the Certificates tab. Click the View Certificates button and select the Servers tab. Scroll down to Fortinet and highlight the certificate for the Student FortiGate (10.0.1.254) and click the delete button. Click OK twice and refresh your browser. Note: Different browsers sometimes have separate certificate repositories, but accessing the FortiGate with HTTPS through Internet Explorer or Chrome should still result in their equivalent warnings. 6. On the Win-Student computer, open XCA. You can find the software on the task bar. The icon looks like a key. Enter the password Fortinet at the prompt. 7. Select the Certificate Signing Requests tab and click Import FortiGate II Student Guide 74 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Import the certificate request file that you downloaded from FortiGate in the previous step. Note: Firefox saves files into the Downloads folder. If the file name was not changed, it will be MyCert.csr XCA should show an unhandled request for 10.0.1.254. 8. Select the Certificates tab, then click New certificate 9. In the Create x509 Certificate window popup, click the Source tab. FortiGate II Student Guide 75 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Go to the Template for the new certificate area. Make sure it is set to [default] CA, then click Apply all. 10. Click the Subject tab, enter these settings: Internal Name Training Authority countryName (use the 2 letter abbreviation for your country) stateOrProvineName (use the full name of the state or province) localityName (use the full name of the city) organizationName Fortinet Training organizationalUnitName Global Training services commonName Training emailAddress Training@fortinet.com 11. In the Private key section at the bottom, click Generate a new key. 12. In the X Certificate and Key management popup, do not change the settings. Click Create. FortiGate II Student Guide 76 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations The Private key area should now be populated. 13. Click OK. XCA should display a message that it successfully created the certificate, and show the certificate in the list as a CA certificate. 14. Go to the Certificate signing requests tab, right-click on the request from 10.0.1.254, then select Sign. 15. On the Source tab in the Signing section, select Use this Certificate for signing. 16. At the bottom of the Source tab in the Template for the new certificate section, select [default] HTTPS_Server, then click Apply all FortiGate II Student Guide 77 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Click OK to finish signing the certificate. The request should now be signed. 17. Go the Certificates tab, select the 10.0.1.254 certificate, then click Export. 18. On the Certificate export window, click OK to save the certificate to a file. Note: Make note of the filename and folder the certificate is going to be saved too. Change them as needed. 19. Export the Training Authority certificate as well. 20. From the HTTP connection to the ForitGate GUI go to System > Certificate > Local Certificate Click Import and browser to the certificate file that was exported in step 15.. If you can’t load the certificate, then go to XCA, delete both certificates, and try the process again. 21. Connect to the CLI on the Student FortiGate. Change the certificate that the FortiGate uses for HTTPS connections to its GUI. config system global set admin-server-cert MyCert end 22. Using HTTPS, connect to the Student FortiGate’s GUI: https://10.0.1.254 There will still be 1 warning message. Do not add an exception. Review the technical details and observe that the only error is with the issuer chain. The CA is not trusted. Since the authority that signed the certificate is not a public root CA, your browser will not be able to find any information about it in its repository of default CA certificates. FortiGate II Student Guide 78 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations But the certificate is now valid for that URL (assuming you used the correct IP address when creating the request). Note: The behavior change will be immediate, but your browser may use locally cached information. If you still see the old certificate, clear your browser’s cache, then refresh the page. 23. Click the Open Menu icon in Firefox and select Options. 24. Under Advanced, on the Certificates tab, select View Certificates. 25. Select the Authorities tab and click Import. FortiGate II Student Guide 79 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Select the Training_authority certificate that you exported previously. 26. When prompted, enable all trust options for the certificate, then click OK. 27. Go to the certificate warning that your browser displayed when trying to access FortiGate’s GUI via HTTPS. Click refresh. The login prompt should now display. No warning should appear. FortiGate II Student Guide 80 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations Exercise 2 SSL Deep Inspection 1. In the Student FortiGate’s GUI, go to Policy & Objects > Policy > IPv4. Edit the port3 → port1 firewall policy. Select the default antivirus profile and the deep-inspection SSL/SSH inspection profile. Save the change by clicking OK. 2. In a new browser window, go to: https://www.google.com You should receive a certificate warning. DO NOT ADD AN EXCEPTION. Note: If you review the technical details the certificate issuer is not trusted. The default SSL inspection certificate is signed by Fortinet. Fortinet is not a public root CA. Note: If you use Chrome, you won’t be able to access Google unless HSTS is disabled in the browser, or Full-SSL Inspection is disabled on FortiGate. 3. On the Student FortiGate, go to System > Certificates > Local Certificates. Click Generate to create a certificate request and enter the Certificate Name: “SSLCert”. For Subject Information choose Domain name and enter SSL.Proxy. You can enter whatever information you like into the rest of the fields. Click OK to generate the new request. FortiGate II Student Guide 81 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations 4. Select the certificate and download it. 5. Import the certificate request into XCA. Refer to exercise 1 step 6 for the process. 6. On the Certificate signing requests tab, right click on the request from SSL.Proxy and select Sign. 7. On the Source tab in the Signing section, select Use this Certificate for signing 8. Go to the Template for the new certificate section. Make sure it is set to [default] CA and click Apply all. 9. On the Extensions tab set the Time range to 1 years and click Apply. 10. Go the Key Usage tab enable Digital Signature, Non Repudiation, Key Encipherment and Data Encipherment. Click OK to finish signing the certificate. 11. Go the Certificates tab, select the SSL.Proxy certificate and click Export. Refer to exercise 1 steps 15 and 16 for the steps to properly export the certificate. 12. From the GUI of the student FortiGate go to System > Certificates > Local Certificates and click Import. Select the SSL.Proxy certificate. FortiGate II Student Guide 82 DO NOT REPRINT © FORTINET Certificate Operations Lab 1: Certificate Operations 13. From the GUI of the student FortiGate go to Policy & Objects > Policy > SSL/SSH Inspection. Edit the deep-inspection profile. Set the CA Certificate to SSLCert, then click Apply to save the change. Note: Certificates unsuitable for SSL content inspection will be automatically filtered out and are not selectable. MyCert cannot be used sign other certificates. 14. Return to the certificate warning for Google, then refresh the page. The page should display normally. Note: The CA that signed this certificate is not public, but the browser is aware of it because you added it as a trusted authority in the previous exercise. FortiGate II Student Guide 83 DO NOT REPRINT © FORTINET Data Leak Prevention Lab 1: Data Leak Prevention Data Leak Prevention Lab 1: Data Leak Prevention In this lab, you will use data leak prevention rules and sensors to block sensitive data from leaving the private network. Objectives Configure DLP to block executable files Read and interpret DLP log entries Set up DLP banning and quarantining Configure DLP fingerprinting Time to Complete Estimated: 55 minutes FortiGate II Student Guide 84 DO NOT REPRINT © FORTINET Data Leak Prevention Lab 1: Data Leak Prevention Exercise 1 Blocking Files by Type 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 2. Restore the configuration file that is required by this lab: Resources\Data-Leak-Prevention\Student\student-dlp.conf FortiGate will reboot. 3. Go to Security Profiles > Data Leak Prevention > Sensor. Create a sensor called No_executable_files. (Click Create New in the upper right-hand corner of the Edit DLP Sensor window.). Note: DLP is not enabled in the GUI by default. If you do not see it listed in the menu, enable it on the status page using the Features widget and click Apply. System >Config >Features Note: Blocking based upon a file name of *.exe is also possible, but not recommended. The obvious weakness however, is that a person could circumvent that type of DLP by changing the filename to, for example, *.ex1, or *.txt. In comparison, file type identification works by analyzing the binary layout of the file. Not all file types have a strict design, however, and these cannot be identified by this method. 4. In the Edit DLP Sensor window, create a new rule. Filter: Files Specify File Types: Click on radio button to select File Types: Select the following from drop down: Batch file (bat), Executables (exe), Executables (elf), HTML Application (hta) Examine the Following services: HTTP-POST Action: Block Click OK to save the changes. FortiGate II Student Guide 85 DO NOT REPRINT © FORTINET Data Leak Prevention Lab 1: Data Leak Prevention 5. Go to Policy & Objects> IPv4 > Policy and edit the port3 enable the DLP sensor called No_executable_files. port1(external1) firewall policy to 6. To test the DLP sensor, transmit an executable file through FortiGate via HTTP. To do this, open a web browser and go to: http://www.sendbigfiles.com On the web page, click the Choose File button and locate the putty.exe executable file on the desktop of the virtual Windows 2003 Server. Then enter your email address and the recipient email address, and click SEND! The DLP block message should display once the file is fully transmitted. 7. From the GUI on the student FortiGate, go to the forward traffic log. Find the entry that has a blocking security action for this attempted data leak. Click Log details to show forward traffic log information. Click DLP to view security log information.. You can view DLP logs under Log & Report > Security Log > Data Leak Prevention. Compare the details of the DLP log to the forward traffic log. FortiGate II Student Guide 86 DO NOT REPRINT © FORTINET Data Leak Prevention Lab 1: Data Leak Prevention Exercise 2 Quarantining a User that is Leaking Sensitive Data 1. Edit the No_executable_files DLP sensor. Change the action for the filter entry that detects executable files to Quarantine IP Address to have an interval of 5 minutes. 2. Return to the sendbigfiles.com web site. 3. On the sendbigfiles.com web page, click Choose File and locate putty.exe file again. Enter the email address of a recipient along with your own email address in the appropriate fields then click SEND! The file upload should be blocked. 4. Quickly go to another web site, such as google.ca. A replacement message should appear instead of the web site. This occurs because the IP address that is sending the request has been quarantined and is not allowed through any Firewall policy on the FortiGate. Note: If you try to visit other web sites now you will be blocked and a replacement message appears instead of the website. Not all protocols support replacement messages. 5. From the GUI on the Student FortiGate, go to User & Device > Monitor > Banned User and locate your entry in the list of temporarily banned IP addresses. 6. Select and remove the banned entry. You should now be able to access the Internet again, even if 5 minutes has not yet elapsed. FortiGate II Student Guide 87 DO NOT REPRINT © FORTINET Data Leak Prevention Lab 1: Data Leak Prevention Exercise 3 DLP Fingerprinting 1. Back up the configuration of the Student FortiGate. (Check your browser's downloads folder.) 2. From the GUI on the Student FortiGate device, go to Security Profiles > Advanced > DLP Fingerprint. In the Manual Document Fingerprints section, upload a new document to take a fingerprint of. Click Create New and locate the configuration file on the desktop that you created in step 1. Set the Sensitivity Level to Critical. Note: The GUI may not auto-refresh when the file has finished being processed. If this happens, wait a few seconds then click on the DLP Fingerprint menu item. 3. Create a new DLP filter in the No_executable_files DLP sensor with the following details: Filter: Files File Finger Print: Critical Examine the Following Services: HTTP-POST Action: Block Click OK to save the change to the filter and click Apply to save the change to the sensor. 4. On the sendbigfiles.com web page, click Choose File and locate the configuration file that you downloaded from the FortiGate. (Check the download folder of the browser you’ve chosen to use) Enter the email address of a recipient along with your own email address in the appropriate fields then click SEND! The file will be blocked. 5. Open the configuration file in a text editor such as Notepad++ (anything that can handle word wrapping is fine). Make a few small changes to different areas of the configuration, then save the file. Note: If you use Notepad++ there is a FortiGate language file that has been written to parse configurations for FortiGate devices. Enable it by clicking selecting FortiGate from the Language menu. 6. On the sendbigfiles.com web site, attempt to send the configuration file again. The file download will be blocked (assuming that changes were not too large, and not in too many areas). FortiGate II Student Guide 88 DO NOT REPRINT © FORTINET Data Leak Prevention Lab 1: Data Leak Prevention Note: Fingerprinting breaks the file into chunks and makes checksums of each part. By default, DLP will detect a match if any chunk’s checksum from the fingerprint matches. FortiGate II Student Guide 89 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies IPv6 Lab 1: IPv6 Transition Technologies In this lab, you will perform the initial IPv6 interface configuration, adding an IPv6 network prefix to your Student FortiGate to automatically configure your internal Windows Server host. You will configure a range of IPv6 transition technologies: the internal network will be configured for dual-stack; NAT64 will be used on the FortiGate, allowing your IPv6 internal address range to communicate with IPv4 hosts on the external network; using IPsec, you will tunnel IPv6 over an IPV4 network. You will configure a tunnel connecting the two internal networks of your FortiGate devices, Student and Remote. The remote FortiGate device is already configured, therefore you only configure the local side of the tunnel and test that your configuration works correctly. Objectives Configure the FortiGate to announce an IPv6 prefix to local hosts supporting autoconfiguration Configure transition technologies including NAT64, dual-stack, and IPv6 over IPv4 IPsec. Time to Complete Estimated: 40 minutes FortiGate II Student Guide 90 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies Exercise 1 IPv6 Setup 1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Remote, and log in as admin. http://10.200.3.1/ 2. Restore the configuration file that is required by this lab: Resources\IPv6\Remote\remote-ipv6.conf FortiGate will reboot. 3. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student, and log in as admin. http://10.0.1.254/ 4. Restore the configuration file that is required by this lab: Resources\IPv6\Student\student-initial.conf FortiGate will reboot. 5. Configure the port3 interface of the Student FortiGate device for IPv6 by adding an IPv6 network prefix for the interface and configuring Stateless Address Auto-Configuration (SLAAC) for hosts on that link. The CLI for setting an IPv6 interface with a routing prefix: config system interface edit port3 config ipv6 set autoconf enable set ip6-send-adv enable set ip6-address 2001:db8:1::254/64 set ip6-allowaccess ping http https ssh config ip6-prefix-list edit 2001:db8:1::/64 set autonomous-flag enable set onlink-flag enable next next end FortiGate II Student Guide 91 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies 6. Verify that the Window server’s IPv6 settings are auto-configured by FortiGate. To do this, from Windows PowerShell, run the command: ipconfig FortiGate II Student Guide 92 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies Exercise 2 NAT64 In order to deal with the CLI only settings, the configuration in this exercise will be done from the CLI. 1. Enable the NAT64 service using the default prefix and enable DNS64 by enabling alwayssynthesize-aaaa-record. config system nat64 set status enable set always-synthesize-aaaa-record enable end 2. Review the configuration changes just made and check any default settings by showing default settings using the full modifier. show full system nat64 3. Create IPv6 firewall address objects for use in this lab. config firewall address6 edit "STUDENT_INTERNAL6" set ip6 2001:db8:1::/64 next edit "REMOTE_INTERNAL6" set ip6 2001:db8:2::/64 next end 4. Create a NAT64 policy from the CLI. Remember the source address is an IPv6 address and the destination address is an IPv4 address. config firewall policy64 edit 1 set srcintf "port3" set dstintf "port1" set srcaddr "STUDENT_INTERNAL6" set dstaddr "all" set action accept set schedule "always" FortiGate II Student Guide 93 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies set service "HTTP" "ALL_ICMP6" next end 5. From the Win-Student computer, test IPv6 by running the ping command: ping 64:ff9b::ac8:1fe What is this address? This is the IPv4 address 10.200.1.254 in NAT64 format. 6. Connect to the GUI of the Student FortiGate using the IPv6 interface address: http://[2001:db8:1::254]/ 7. Go to System > Config > Features and enable IPv6 in the GUI. 8. Connect via SSH using the IPv6 interface address. Once connected, enter the following command: diag sys session clear Your SSH session is still active, why? diag netlink interface list Exercise 3 Using IPsec to Tunnel IPv6 over an IPv4 Network In order to deal with the CLI only settings, you will perform this exercise using the CLI. 1. In the CLI of the Student FortiGate (10.0.1.254), create an IPsec phase1 interface object with the IP of the Remote FortiGate as the remote gateway. config vpn ipsec phase1-interface edit "ipv4_to_ipv6" set interface "port1" set remote-gw 10.200.3.1 set psksecret fortinet next end 2. Create an IPsec Phase2 interface object and configure IPv6 source and destination address selectors. config vpn ipsec phase2-interface edit "ipv4_to_ipv6-P2" set phase1name "ipv4_to_ipv6" set src-addr-type subnet6 FortiGate II Student Guide 94 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies set dst-addr-type subnet6 set src-subnet6 2001:db8:1::/64 set dst-subnet6 2001:db8:2::/64 next end 3. Create a static route for the 2001:db8:2::/64 prefix, select the local IPsec interface as the device. config router static6 edit 0 set dst 2001:db8:2::/64 set device "ipv4_to_ipv6" next end 4. Create IPv6 firewall accept policies between the internal network and IPsec interface. config firewall policy6 edit 0 set srcintf "port3" set dstintf "ipv4_to_ipv6" set srcaddr "STUDENT_INTERNAL6" set dstaddr "REMOTE_INTERNAL6" set action accept set schedule "always" set service "ALL" next edit 0 set srcintf "ipv4_to_ipv6" set dstintf "port3" set srcaddr "REMOTE_INTERNAL6" set dstaddr "STUDENT_INTERNAL6" FortiGate II Student Guide 95 DO NOT REPRINT © FORTINET IPv6 Lab 1: IPv6 Transition Technologies set action accept set schedule "always" set service "ALL" next end 5. From the Windows server, test the tunnel by running the ping command for the remote internal gateway address: ping 2001:db8:2::254 6. From the CLI check the IPv6 routes, interface addresses and the tunnel state, noting the selectors (proxy IDs) for the IPv6 subnets. # get router info6 routing-table # get router info6 interface # diag vpn tunnel list FortiGate II Student Guide 96 DO NOT REPRINT © FORTINET Appendix A: Additional Resources Appendix A: Additional Resources Training Services http://training.fortinet.com Technical Documentation http://help.fortinet.com Knowledge Base http://kb.fortinet.com Forums https://support.fortinet.com/forum Customer Service & Support https://support.fortinet.com FortiGuard Threat Research & Response http://www.fortiguard.com FortiGate II Student Guide 97 DO NOT REPRINT © FORTINET Appendix B: Presentation Slides Appendix B: Presentation Slides FortiGate II Student Guide 98 DO NOT REPRINT © FORTINET Routing In this lesson, we are going to talk about how to route traffic with FortiGate devices. FortiGate II Student Guide 99 DO NOT REPRINT © FORTINET Routing After completing this lesson, you should have these practical skills that you can use to implement routing failover and load balancing using static routes. You will also learn how to configure link aggregation, policy routes, and black hole routes. Finally, you will learn some debug commands for troubleshooting routing problems. Although this lesson briefly introduces the concept of dynamic routing, it is mostly about implementing routing with static and policy-based routes. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 100 DO NOT REPRINT © FORTINET Routing What is routing? Routing decides where FortiGate in NAT mode will send the packets that it receives, and that it generates. A routing table contains routing rules. For example, FortiGate can check the destination field of the packet’s IP header. If routing rules match that destination, FortiGate can transmit the packet from port1 to port2, towards Router 1. If an allowed packet is not destined for the FortiGate itself — not administrative access, for example — FortiGate must relay the packet. FortiGate searches for matching routes in the routing table that it can use to deliver the packet. FortiGate either delivers the packet directly to its final destination, or relays it to the next router along the path towards the destination. Usually, IP routing is done by taking into account only the destination IP address. However, as we’ll see later, you can decide to route packets using more than just that. Proper routing configuration is important. If the routing directions are misconfigured, packets will not reach their destination and will be lost. FortiGate II Student Guide 101 DO NOT REPRINT © FORTINET Routing One type of manually configured route is called a static route. In the route table, its “Type” column is “Static”. We are manually telling the FortiGate device, “When you see a packet whose destination is within this specific range of destination addresses, send it through this network interface, towards this router.” We also configure the distance and priority so that FortiGate knows which routes to load into memory, and in what order. We will talk about distance and priority in later slides. For example, in simple home networks, DHCP automatically retrieves and configures one static route. Your modem then sends all outgoing traffic through your ISP’s Internet router, which can relay packets to their destination. When do you not require a static route? When a destination is cabled directly to one of FortiGate’s network interfaces, with no router in between, FortiGate will be aware of the destination. In the route table, its “Type” is “Connected”. FortiGate II Student Guide 102 DO NOT REPRINT © FORTINET Routing For large networks, manually configuring hundreds static routes may not be practical. Your FortiGate can help, by configuring routes automatically. FortiGate supports several dynamic routing protocols: RIP, OSPF, BGP, and IS-IS. In dynamic routing, FortiGate communicates with nearby routers to discover their paths, and to advertise its own directly connected subnets. Discovered paths are automatically added to FortiGate’s routing table. (So verify that your neighbor routers are trusted and secured!) Larger networks also may need to balance routing load among multiple valid paths, and detect and avoid routers that are down. We’ll discuss that soon also. FortiGate II Student Guide 103 DO NOT REPRINT © FORTINET Routing Which rows are “extra” – automatic entries that aren’t from your static routes configuration? • Directly connected subnets – When a subnet is assigned to a FortiGate’s interface, a route to the subnet is automatically added to the routing table. The FortiGate knows how to route those packets. • Dynamic routes – On larger networks, your FortiGate may receive routes from other routers, via protocols such as BGP. This is faster and more scalable than manually configuring many routers. Which configured routes aren’t loaded into this table? • Worse routes to the same IP – Only the best paths should be used. We will see in a later slide how the best path is elected when there are multiple routes to the same destination. • Policy routes – These are omitted, too. Why? By design, policy routes override the routing table – we don’t want them to be ignored, losing precedence to OSPF or static routes. So they have to be in a separate table, which is searched before this one. We’ll discuss policy routes later. So remember, expect differences from your configured list of static routes. And when troubleshooting, don’t only check this table. Also check the table for policybased routes, and (if you’re using dynamic routing) your other routers. FortiGate II Student Guide 104 DO NOT REPRINT © FORTINET Routing In the routing table, each of the entries has a few pieces of data, such as distance and gateway IP. They are used to relay or deliver each matching packet. Destination IP addresses and gateway routers are self-explanatory. The device is the name of the outgoing interface where the packet will be routed to. But what about the distance, metric, and priority? How do they effect which routing path packets will use? Let’s explain each briefly. FortiGate II Student Guide 105 DO NOT REPRINT © FORTINET Routing Distance, or administrative distance, is a number that estimates the reliability or quality of each routing protocol and static route. If there are two routes to the same destination, the one with the lower distance is added or loaded to the routing table, as it is considered to be more reliable. By default, for example, routes learned via the RIP protocol have a higher distance that routes learned via the OSPF protocol, as OSPF is considered to be more accurate than RIP. FortiGate II Student Guide 106 DO NOT REPRINT © FORTINET Routing In the case of routes learned via a dynamic routing protocols, metric is another element that is used to determine the best route to a destination. If two routes have the same distance, the metric is then used for tie breaking. The route with the lowest metric is loaded to the routing table. How the metric is measured depends on the routing protocol. RIP uses hop counts: how many routers must be used to reach the destination. OSPF uses cost, which is determined by how much bandwidth a link has. FortiGate II Student Guide 107 DO NOT REPRINT © FORTINET Routing In the case of static routes, the priority is used for tie breaking when the distances are the same. FortiGate will use the route with the smallest number configured in the route’s priority setting. In other words, if we have two routes with the same distance to the same destination, only the one with the smallest priority will be used. Note that unlike with distances/metrics, both routes with the same distance are loaded into the routing table. However, only the route with the smallest priority will be routing traffic. This, as we will see later, is an important concept when dealing with reverse forwarding path check issues. FortiGate II Student Guide 108 DO NOT REPRINT © FORTINET Routing This is summary of the logic behind which routes are loaded into the routing table. Routes are only active if the interface is currently both physically linked and administratively “up.” If the cable isn’t plugged in, or if a Wi-Fi network has no signal, for example, packets can’t be transmitted along that path. All routes through that link will be temporarily unloaded from the table until the link is available again. When 2 or more actives routes have the same destination subnet, only the one with the smallest distance is loaded to the routing table. If the distances are equal, only the routes with the smallest metric are included. If the metric also is identical, then, depending on the dynamic routing protocol’s rules, FortiGate will select which one to include in the routing table. FortiGate II Student Guide 109 DO NOT REPRINT © FORTINET Routing Static routes are simple, and are often enough for small networks. Policy routes, however, are more powerful. They can match more than just the destination IP address. An example? If you have two links – a slow one and a fast one – you can route packets from low-priority source IPs to the slow link. Policy routes with the action forward traffic have precedence over static and dynamic routes. So, if a packet matches the policy route, the FortiGate bypasses the routing table lookup. Like static routes, policy routes must be valid: a destination and gateway are required, and disconnected or “down” links can’t be used. For policy routes, though, packets also must match all subnets, ToS bits, and port numbers that you specify. So if a setting shouldn’t be a criteria for matching, leave it blank. FortiGate II Student Guide 110 DO NOT REPRINT © FORTINET Routing When a packet matches a policy route, the FortiGate takes either one of two actions. Either it routes the packet to the configured interface and gateway, bypassing the routing table; or it stops checking the policy routes, so the packet will be routed depending on the routing table. FortiGate II Student Guide 111 DO NOT REPRINT © FORTINET Routing Many aspects of FortiGate are (at least by default) stateful, so it decides many things at the beginning of a session, when it receives the first packets. For each session, FortiGate makes only 2 routing lookups: 1. Upon the first packet sent by the originator, and 2. Upon the first reply packet coming from the responder. After that, FortiGate writes the routing information to its session table. Subsequent packets are routed according to the session table, not the routing table. So all packets that belong to the same session follow the same path, even after a change in the static routes. There is an exception to this rule, though: if there is a change in the routing table, FortiGate removes the route information for the session table, and then it makes additional routing table lookups to rebuild this information. FortiGate II Student Guide 112 DO NOT REPRINT © FORTINET Routing How does FortiGate decide routes? FortiGate has multiple routing modules. This diagram shows the logic among them. First FortiGate searches its policy routes. You can view them with the command “diagnose firewall proute list”. If there is a match in the policy routes and the action is Forward Traffic, FortiGate will use the policy route. If the action is Stop Policy Routing, the FortiGate will use the next table. After that, FortiGate searches its route cache. You can view that with the CLI command “diagnose ip rtcache list”. If a match exists, the packet is sent to that next-hop gateway. Finally, FortiGate searches the forwarding information base (FIB). The FIB is generated by the routing process, and is the table used for packet forwarding. Think of the routing table’s purpose as for management, while the FIB is for forwarding. This separation becomes more clear in FortiGate active-active HA. In an HA cluster, both route management and forwarding tables exist on the master FortiGate. But on the slave FortiGate, only the forwarding table exists. If there’s no match in any of those tables, FortiGate will drop the packet because it is unroutable. FortiGate II Student Guide 113 DO NOT REPRINT © FORTINET Routing We saw how the distance, metric and priority are used to determine the best route to a destination. So, what happens when two or more routes to the same destination share the same values for those routing elements? If the routes are static, OSPF or BGP, FortiGate balances the traffic among all the routes. This is what is called Equal Cost Multi-path (ECMP). FortiGate II Student Guide 114 DO NOT REPRINT © FORTINET Routing When the FortiGate is doing ECMP, one of the these four methods is used. Sessions can be balanced among equal routes depending on the source IP address, source and destination IP addresses, or interface weight. There is an additional method called spillover, where the FortiGate will use a primary route until a traffic volume threshold is reached; after that, another route will be used. FortiGate II Student Guide 115 DO NOT REPRINT © FORTINET Routing (slide contains animation) This is an example of ECMP. In the FortiGate routing table, there are two default routes with the same distance and priority. One using the wan1 interface, another one using the wan2 interface. So, outgoing traffic is load balanced among the two ISPs. If an interface becomes unavailable because of, for example, a physical disconnection, all routes associated with that link/gateway are temporarily removed from the routing table. (click) So if WAN1 went down, its routes would be dropped from the routing table. The only remaining available default route for traffic would be through WAN2. When WAN1 comes up again, then its routes will be loaded back into the routing table. FortiGate II Student Guide 116 DO NOT REPRINT © FORTINET Routing (slide contains animation) If you do not want to load balance, you can change which route will be primarily used for the outgoing traffic by changing the priority number. (click) In this way, FortiGate will simply switch to use the route with the smallest priority. Remember that both routes are still in the routing table, as long as they both keep the same distance number. FortiGate II Student Guide 117 DO NOT REPRINT © FORTINET Routing Link health monitor is a mechanism for detecting when a router along the path is down. It is often used where there are redundant routers onsite, such as in HA deployments, or for dual ISP links. When configured, FortiGate periodically sends signals through one of the gateways to a server that acts as a beacon. The server can be any host that should normally be reachable via that path. Usually, it’s best to choose a stable server with robust infrastructure, and to choose the protocol that the server would normally respond to. If the FortiGate stops receiving a replay from the server, all the routes using that gateway will be removed from the routing table. Alternatively, you can configure the unit to administratively bring down an interface, so all routes using that interface will be removed. While a server is unresponsive, FortiGate will continue to send link health monitor signals. As soon as FortiGate receives a reply, it will reinstate the routes. It may be useful to choose a server that is indirectly attached, located 1 or 2 hops beyond the FortiGate’s gateway. This does not exactly test availability of this one gateway, but rather the combination of gateways. That way, the FortiGate will accurately indicate availability of services and subsequent hops. FortiGate II Student Guide 118 DO NOT REPRINT © FORTINET Routing Here is where you configure the link health monitor. You must enter the egress interface, the IP address of the gateway router, and the IP address and the protocol (HTTP, ICMP, UDP or TCP) of a beacon that is beyond that gateway. FortiGate II Student Guide 119 DO NOT REPRINT © FORTINET Routing Packets are sometimes dropped for reasons where routing and security are related. Reverse path forwarding (RFP) is a mechanism that protects the FortiGate and the network from IP spoofing attacks. It checks if there is a valid route back to the packet’s source, through the interface where the packet is coming from. If there is not a valid route, the packet is dropped. This checking is executed over the first packet of any new session. It is also executed after a route change, over the next packet in the original direction. When packets are dropped because of the RFP mechanism, the debug flow will output an error like the one shown in this slide. FortiGate II Student Guide 120 DO NOT REPRINT © FORTINET Routing (slide contains animation) Here’s a sample network setup and routing table. There are two routing errors here, two interfaces that won’t route traffic properly. They are port1 and wan2. port1 will not route traffic properly. The reason is because of the subnet for the computers. They’re in 10.0.0.0/24, and there’s no route for that subnet in the routing table to egress through port1. (click) So anything coming from 10.0.0.0/24 to that interface will be dropped because that subnet cannot be routed back. FortiGate II Student Guide 121 DO NOT REPRINT © FORTINET Routing The problem is fixed by adding a route to 10.0.0.0/24. Now, when FortiGate does the RPF check for the incoming packet, it finds a valid route to that subnet through out port1. The packet is now accepted. FortiGate II Student Guide 122 DO NOT REPRINT © FORTINET Routing The other interface that will not be able to route traffic properly either is WAN2. While it is physically connected to the Internet, the only IP addresses that would be valid as sources or destinations would be those in the 2.2.2.0/30 subnet. So, incoming Internet traffic will not pass the RPF check and will be dropped. FortiGate II Student Guide 123 DO NOT REPRINT © FORTINET Routing (slide contains animation) Once again, this is fixed by adding a route for wan2. In this case, the route needs to act as a default gateway in order to provide Internet access. To become part of the routing table, it needs to have the same distance as the default route for wan1. They both can have different priorities, but as we saw in previous slides, they must have the same distance to be included in the routing table. (click) If the priorities are also the same, this creates a situation like the one we saw for ECMP. So, if the destination is the Internet, there are 2 possible paths to take: through either wan1 or wan2. Some sessions will exit from wan1, and others will exit from wan2. FortiGate II Student Guide 124 DO NOT REPRINT © FORTINET Routing Reverse path forwarding can be either strictly or loosely enforced. Loose RPF checks that the sender can be routed out from the interface where the packet was received. This simply confirms that a response is possible. Strict RPF requires that the receiving interface is not only valid, but that it is also the best interface for the reply. If you have multiple routes, it must be the preferred one. FortiGate II Student Guide 125 DO NOT REPRINT © FORTINET Routing (slide contains animation) Let’s look at an example of loose RFP. (click) In this case, 20.20.20.20 pings 10.10.10.5, but fakes a source IP of 10.10.10.6, making the packet appear to be initiated from the internal network. Loose RPF would allow this traffic because the route on wan1 is a default route (0.0.0.0/0), which is valid (although not the best one). (click) What would happen next is that 10.10.10.6 would send the SYN/ACK packet to the “real” device with the IP address 10.10.10.5. (click) But since 10.10.10.5 is not expecting SYN/ACK packets (because it has not previously sent any SYN packet to 10.10.10.6), it will reply with a TCP Reset (RST) packet. FortiGate II Student Guide 126 DO NOT REPRINT © FORTINET Routing (slide contains animation) Let’s see what happens in the same topology with strict reverse path forwarding. (click) Strict RPF drops the packet. The default route in wan1 is a valid route to the subnet 10.10.10.0/24, but it not the best route. The best route is through the internal interface. So the packet should have been coming from the internal interface. Although strict RPF is more secure, it can backfire if you use dynamic routing. Dynamic routes can change quickly, and this fact combined with strict reverse path forwarding could cause FortiGate to drop packets each time the preferred route changes. FortiGate II Student Guide 127 DO NOT REPRINT © FORTINET Routing Some dynamic routing protocols require access to an interface that is always up. A loopback interface isn’t correlated to any of FortiGate’s physical links. It exists in the FortiGate software only. So all traffic with that destination stops at your FortiGate. A loopback interface is always up and available, regardless of physical cabling. To create a loopback interface, go to System > Network > Interface and click on Create New. The type must be loopback Interface. FortiGate II Student Guide 128 DO NOT REPRINT © FORTINET Routing Link aggregation is when multiple physical interfaces are logically bound into a single channel. This increase bandwidth and provides redundancy between two network devices. FortiGate II Student Guide 129 DO NOT REPRINT © FORTINET Routing WAN link load balancing, on the hand, consists of a group of interfaces connected to multiple ISPs. Once created, the FortiGate sees all those Internet interfaces as one single logical interface, the virtual WAN link. This helps to simplify the configuration as now the administrator only needs to configure a single set of routes and firewall policies that will be applied to all the ISPs. There can be only one virtual WAN link per VDOM. FortiGate II Student Guide 130 DO NOT REPRINT © FORTINET Routing How FortiGate distributes traffic across its WAN links is very similar to how ECMP does it. It can be based on: • source IP address, • source and destination IP addresses, • interface’s weight, or • spillover (like ECMP) However, in WAN link load balancing, there is one more method, called “measured volume.” With this method, sessions are distributed among all the links based on each link current bandwidth utilization. FortiGate II Student Guide 131 DO NOT REPRINT © FORTINET Routing To configure WAN link load balancing, you need to specify which interfaces are going to be members. In other words, which interfaces are connected to the Internet. For each member, you can configure health check. If the health check fails, the member is removed from the WAN link load balancing. FortiGate II Student Guide 132 DO NOT REPRINT © FORTINET Routing Optionally, you can be more selective and specify that specific traffic services are routed through specific interfaces that are members of the virtual WAN. Additionally, you can configure the FortiGate to measure the quality of each link (by measuring either the latency or the jitter). So, selected traffic services can then be routed to the interface with the highest or lowest measured quality. FortiGate II Student Guide 133 DO NOT REPRINT © FORTINET Routing After WAN link load balancing have been configured, a logical interface with the name wan-load-balance is automatically added to the FortiGate. What you need to do next is to create the routes and firewall policies that are going to be applied to all the members of the virtual WAN. FortiGate II Student Guide 134 DO NOT REPRINT © FORTINET Routing Common routes are used to build a path so that the source can reach the destination. Black hole routes do the opposite, making the destination unreachable. Sometimes administrators require the use of wide summarized subnets. To avoid unnecessary traffic, packets to unused subnets must be dropped. To do this, you can create a black hole route to silently drop unwanted traffic. In the above example, all spoke sites (R3, R4 etc.) use addresses in the 172.16.0.0/16 range. They have a routing protocol within their domain to reach the specific 172.16.x.0/24 subnets. They also have a default route to access the internet. The link between R1 and R2 is static only. A packet sent from R3 whose destination is in the 172.16.0.0/16 range (but to a /24 network that does not exist) will take the default route path. R2 will then forward to R1 and R1 will bounce this back to R2 because of the summarized static route. This will continue until the packet TTL drops to 0. To prevent it, R2 should have a black hole route for the network 172.16.0.0/16. In this way, if a packet is destined to a subnet 172.16.x.0/24 that does not exist, it will be dropped and not forwarded to the default route path (R1). FortiGate II Student Guide 135 DO NOT REPRINT © FORTINET Routing Multicast is traffic sent from one source to multiple destinations. A multicast routing protocol populates the routing tables with information about how to route multicast traffic. Multicast is commonly used for video conferencing because it lowers the origin’s resource usage and hardware requirements of transmitting to multiple destinations. One stream of data goes to the router, which then multiplies that into data streams for each destination. A FortiGate device can be configure to route and apply NAT over multicast traffic. FortiGate II Student Guide 136 DO NOT REPRINT © FORTINET Routing We’ve seen the routing table in the GUI. Now, let’s see some diagnostics you can use in the CLI. This is the equivalent CLI command, which shows the routing table. At the top, each code is defined. Each route begins with a flag that shows what kind of route it is, or how it was learned. After the flag there is the route itself, then the distance and metric. Next you have the gateway (if there is one), and the egress network interface. Finally, for dynamic routes, you have a timer that indicates when the route will expire (if not renewed). FortiGate II Student Guide 137 DO NOT REPRINT © FORTINET Routing This command is very low-level. It shows the actual Forward Information Database (FIB), which is the routing information that the kernel uses to route traffic. FortiGate II Student Guide 138 DO NOT REPRINT © FORTINET Routing This command gives a quick list of IP addresses associated with each interface. They can be physical, VLAN, or virtual interfaces. FortiGate II Student Guide 139 DO NOT REPRINT © FORTINET Routing If you suspect that there is an IP address conflict, or that an IP has been assigned to the wrong interface, you may need to look at the ARP table. This command is used for that purpose. It shows the interface, IP address, and associated MAC address. FortiGate II Student Guide 140 DO NOT REPRINT © FORTINET Routing The GUI offers a monitor to check the status of all the members of the virtual WAN interface. It also shows the status of all the link health monitors configured in the FortiGate. FortiGate II Student Guide 141 DO NOT REPRINT © FORTINET Routing To review, here is what we discussed. We talked about not only routing concepts and configuration, but also diagnostics. FortiGate II Student Guide 142 DO NOT REPRINT © FORTINET Virtual Domains In this lesson, we will show how to configure virtual domains (VDOMs) and common usage examples. FortiGate II Student Guide 143 DO NOT REPRINT © FORTINET Virtual Domains After completing this lesson, you should have these practical skills that you can use to create VDOMS and VLANs, which are commonly used logical interfaces when working with virtual domains in a FortiGate. You will also learn to limit the resources allocated to each VDOM and create perVDOM administrative accounts. The lesson also covers inter-VDOM connectivity. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 144 DO NOT REPRINT © FORTINET Virtual Domains VDOMs are a virtualization within FortiOS, providing virtual firewalls. Interfaces have VDOM membership, the interface a packet arrives on determines which VDOM will process the traffic. Interfaces can be physical or logical; IEEE 802.1Q VLANs are a logical interface commonly used with VDOMS. VLANs splits your physical LAN into multiple logical LANs. Each VLAN forms a separated broadcast domain. In a same interface (or collision domain) multiple VLANs can coexist. In this way, a physical interface is split into two or more logical interfaces. A tag is added to each Ethernet frame to identify the VLAN that it belongs to. FortiGate II Student Guide 145 DO NOT REPRINT © FORTINET Virtual Domains This slide shows a Ethernet frame. The frame contains the MAC addresses, the type, the data payload, and a CRC code to confirm that is not corrupted. In the case of Ethernet frames with VLAN tagging, according with the 802.11q standard, 4 more bytes are inserted after the MAC addresses. They contain an ID number that identifies the VLAN. An OSI Layer 2 device, such as a switch, can add or remove these tags from Ethernet frames. But it cannot change them. A Layer 3 device, such as router or a FortiGate, can change the VLAN tag before proceeding to route the traffic. In this way, they can route traffic between VLANs. FortiGate II Student Guide 146 DO NOT REPRINT © FORTINET Virtual Domains When operating in NAT/route mode, the FortiGate device operates as a Layer 3 router in its most basic configuration. In this mode, a VLAN is an interface on the device. VLAN tags may be added on egress, removed on ingress, or rewritten based on a routing decision. When operating in Transparent mode, the FortiGate device operates as a Layer 2 bridge in its most basic configuration. In this mode, a VLAN is an identifier for identifying traffic flows. The VLAN does not exist on the FortiGate, in FortiOS the broadcast domain which is an accepted as a property of a VLAN, is defined by the virtual domain, and the broadcast domain can only be modified using forwarding domains as a sub-division. So to create a VLAN like behavior on FortiOS in transparent mode, you would need ingress and egress VLAN interfaces using the same VID, and a forwarding domain within the virtual domain containing those two interface, plus firewall policies to allow traffic. FortiGate II Student Guide 147 DO NOT REPRINT © FORTINET Virtual Domains (slide contains animation) In this example of NAT/route mode, a host on VLAN 100 sends a frame to a host on VLAN 300. Switch A receives the frame on the untagged VLAN 100 interface and adds the VLAN 100 tag on the tagged trunk link between switch A and the FortiGate, where the VLAN 100 gateway is configured. (click) FortiGate receives the frame on the VLAN 100 interface. Then, it routes the traffic from VLAN 100 to VLAN 300, rewriting the VLAN ID to VLAN 300 in the process. (click) Switch B receives the frame on the VLAN trunk interface and removes the VLAN tag when it forwards the frame to its destination on the untagged VLAN 300 interface. FortiGate II Student Guide 148 DO NOT REPRINT © FORTINET Virtual Domains In this example, some computers located in separate buildings are part of the same department: Accounting. They often share files, which results in much traffic. But notice the other computers in each location. They are not part of Accounting. They are connected to the same switch only because they are located in the same room, not because they are logically related. So, they shouldn’t be bombarded with frames from Accounting computers. To isolate each department, we could use different physically switches in each location to create a distinct physical LANs. Instead, the network administrator here has decided to use only one switch in each site and configure network devices to VLAN tag the frames. This causes traffic to be forwarded only to devices in the same VLAN. To route information between different VLANs, the frame must reach a Layer 3 router such as FortiGate, which can rewrite the VLAN tag. FortiGate II Student Guide 149 DO NOT REPRINT © FORTINET Virtual Domains To create a VLAN from the GUI, click on Create New and select VLAN as the Type. You must specify the VLAN ID and the physical interface where the VLAN will be bound to. Frames that belong to interfaces of that type are always tagged. On the other hand, frames sent or received by the physical interface segment are never tagged. They belong to what is called the “native” VLAN. FortiGate II Student Guide 150 DO NOT REPRINT © FORTINET Virtual Domains So far, we’ve seen network segments subdivided and unified. It was one organization, with a single set of policies and a few administrators – in effect, a single security domain. What if you are an MSSP? What if you are a very large company? What if you want to subdivide policies and administrators into multiple security domains? In that case, you can enable FortiGate VDOMs, which split your physical FortiGate into multiple logical devices. Each VDOM has independent security policies and routing tables. Also and by default, traffic from one VDOM cannot go to a different VDOM. FortiGate II Student Guide 151 DO NOT REPRINT © FORTINET Virtual Domains Remember, VDOMs are a logical separation only – each VDOM shares physical resources with the others. Unlike with FortiGate-VM, VDOMs are not allocated and balanced with weighted vCPU cores, vRAM, and other virtualized hardware. To fine-tune performance, you configure resource limits for each feature – IPSec tunnels, address objects, etc. – at both the global level and at each VDOM level. This controls the ratio of each VDOM’s system resource usage to the total available resources. FortiGate II Student Guide 152 DO NOT REPRINT © FORTINET Virtual Domains For example, on this FortiGate, the hardware is powerful enough to handle up to 2000 IPSec VPN tunnels. The FortiGate is configured with 3 VDOMs. VDOM 1 and VDOM 2 don’t use IPSec VPN tunnels often, so, they are allowed to have up to 50 tunnels each. VDOM 3, however, uses VPN extensively. Therefore this FortiGate will be configured to allow VDOM 3 to have up to 1900 tunnels. Additionally, 1000 of those tunnels will be guaranteed. Configure your FortiGate with global limits for critical features such as sessions, policies, and others. Then configure each VDOM with its own quotas and minimums, within the global limits. FortiGate II Student Guide 153 DO NOT REPRINT © FORTINET Virtual Domains Global resource limits are an example of global settings. The firmware on your FortiGate and some settings, such as system time, apply to the entire appliance – they are not specific to each VDOM. FortiGate II Student Guide 154 DO NOT REPRINT © FORTINET Virtual Domains Most settings, however, can be configured to be different for each VDOM. Some example are: firewall policies, firewall objects, static routes, security profiles, etc. FortiGate II Student Guide 155 DO NOT REPRINT © FORTINET Virtual Domains To enable VDOMs from the GUI, in the System Information widget on the dashboard, in the Virtual Domain row, click the Enable link. Alternatively, to enable VDOMs when you are logged into the CLI, enter this command. This won’t reboot your FortiGate, but it will log you out; enabling VDOMs restructures both the GUI and CLI, which you will see when you log in again. FortiGate II Student Guide 156 DO NOT REPRINT © FORTINET Virtual Domains (slide contains animations) After enabling VDOMs, by default, only one VDOM exists: the “root” VDOM. It’s the default management VDOM, which we will discuss further soon. You need to add a VDOM for each of your security domains. If you’re an MSSP, for example, you might add one VDOM per client company. If you are an enterprise business, you might add one VDOM for each division of your company. (click) After adding the additional VDOMs, you can proceed to specify which interfaces belong to each VDOM. FortiGate II Student Guide 157 DO NOT REPRINT © FORTINET Virtual Domains If you log in as most administrator accounts, you will enter your VDOM automatically. But if you are logged in as the account named “admin,” you aren’t assigned to any VDOM. To enter a VDOM on the GUI, click the “Virtual Domains” part of the menu. Inside, you will see the default VDOM, named “root.” Other VDOMs that you configure will also appear under the “Virtual Domains” menu. To access a VDOM, click it and expand its contents. Inside each VDOM, the submenu should be familiar: it is essentially the same navigation menu that you had before you enabled VDOMs, except that the global settings moved out, to the “Global” part of the menu. FortiGate II Student Guide 158 DO NOT REPRINT © FORTINET Virtual Domains If you want to grant access to all VDOMs and global settings, select “super_admin” as the access profile when configuring the administrator account. Similar to the account named “admin,” this account will be able to configure all VDOMs. Best practice dictates that you usually should avoid unnecessary security holes, however. Do not provide “super_admin” access if possible. Instead, restrict each administrator to their relevant domain. That way, they cannot accidentally or maliciously impact other VDOMs, and any damage or mistakes will be limited in scope. FortiGate II Student Guide 159 DO NOT REPRINT © FORTINET Virtual Domains In most cases, you’ll start by creating one administrator account per VDOM. He or she will be chiefly responsible for that domain, including that VDOM’s configuration backups. In larger organizations, you may need to make more VDOM administrators. Multiple administrators can be assigned to each VDOM. You can subdivide their permissions using access profiles in order to follow best practices for segregation of duties. The converse is also possible. If required, you can assign an administrator to multiple VDOMs. FortiGate II Student Guide 160 DO NOT REPRINT © FORTINET Virtual Domains To create new administrator accounts and assign them to a VDOM, go to the “Global” part of the navigation menu. FortiGate II Student Guide 161 DO NOT REPRINT © FORTINET Virtual Domains To review, each VDOM behaves as it is on a separate FortiGate appliance. With separate FortiGates, you would normally connect a network cable and configure routing and policies between them. But VDOMs are on the same FortiGate. So how should you route traffic between them? The solution is inter-VDOM links. With inter-VDOM links, you won’t send traffic out through a physical cable or VLAN, then back into the same FortiGate to reach another VDOM. Inter-VDOM links are a type of virtual interface. Note that like with inter-VLAN routing, Layer 3 must be involved – you cannot create an inter-VDOM link between layer-2 transparent mode VDOMs! At least 1 of the VDOMs must be operating in NAT mode. This, among other benefits, prevents potential layer-2 loops. FortiGate II Student Guide 162 DO NOT REPRINT © FORTINET Virtual Domains When creating inter-VDOM links, you’ll need to create the virtual interface. You must also create a matching firewall policy, just as you would if the traffic were arriving on a network cable. Otherwise, FortiGate will block it. Additionally, routes are required to properly route packets between two VDOMs. FortiGate II Student Guide 163 DO NOT REPRINT © FORTINET Virtual Domains In the menu, creating a network interface is located in the “Global” settings. To create the virtual interface, click the drop-down menu arrow, then choose “VDOM Link”. FortiGate II Student Guide 164 DO NOT REPRINT © FORTINET Virtual Domains In the global section of the GUI, there is a VDOM monitor. It displays the CPU and memory usage per VDOM. It also shows the amount of sessions and sessions created per second. FortiGate II Student Guide 165 DO NOT REPRINT © FORTINET Virtual Domains Up until now, we’ve discussed traffic passing through FortiGate, from one VLAN or VDOM to another. What about traffic originating from your FortiGate itself, or destined to it? Administrator sessions and system daemons, such as NTP and FortiGuard updates, generate this kind of traffic. When VDOMs are enabled, this means that a special VDOM, known as management VDOM, must be automatically created so that FortiGate has network interfaces that can continue to send and receive system-related packets. By default, the VDOM root acts as the management VDOM, but you can manually re-assign this task to a different VDOM. Similar to a FortiGate without VDOMs, the administrative VDOM usually should have outgoing Internet access. Otherwise features such as scheduled FortiGuard updates will fail. FortiGate II Student Guide 166 DO NOT REPRINT © FORTINET Virtual Domains There are a few ways you can arrange your VDOMs. In this topology, each network accesses the Internet through its own VDOM. FortiGate II Student Guide 167 DO NOT REPRINT © FORTINET Virtual Domains Notice that there were no inter-VDOM links in the previous example. So, inter-VDOM traffic is not possible unless it physically leaves the FortiGate, towards the Internet, and is rerouted back. This is most suitable for multiple customers sharing a single FortiGate, each in their own VDOM, with physically separate ISPs or large pipes, for example. FortiGate II Student Guide 168 DO NOT REPRINT © FORTINET Virtual Domains This is another example. Like the previous topology, each network sends traffic through its VDOM. But after that, traffic is routed through the management VDOM – by default, named “root”. So, Internet-bound traffic flows through a single pipe in the “root” VDOM. This could be suitable for multiple customers sharing a single FortiGate, each in their own VDOM. But in this case, the management VDOM could log and monitor traffic and/or provide standard services like antivirus scanning. FortiGate II Student Guide 169 DO NOT REPRINT © FORTINET Virtual Domains Note that this topology has inter-VDOM links, but peer VDOMs are only linked with the management VDOM, not with each other. Inspection could be done by either the “root” or original VDOM, depending on your requirements. Alternatively, you could split inspection so that some scans occur while traffic is in the “root” VDOM, ensuring a common security baseline, while more intensive VDOM-specific scans can optionally occur in the originating or destination VDOM. FortiGate II Student Guide 170 DO NOT REPRINT © FORTINET Virtual Domains Here, traffic again flows through a single pipe in the “root” VDOM towards the Internet. Traffic between VDOMs doesn’t need to leave the FortiGate either. However, traffic doesn’t need to flow through the management VDOM either. Inter-VDOM links between VDOMs allow more direct communication. Like the previous example, inspection could be done by either the “root” or original VDOM, depending on your requirements. FortiGate II Student Guide 171 DO NOT REPRINT © FORTINET Virtual Domains Due to the number of inter-VDOM links, this example is the most complex, requiring the most routes and firewall policies. Troubleshooting meshed VDOMs can also be more time-consuming. However, meshed VDOMs also provide the most flexibility. For large businesses, inter-VDOM communication may also be required, and inter-VDOM traffic performance may be better due to a shorter processing path which bypasses the management VDOM. FortiGate II Student Guide 172 DO NOT REPRINT © FORTINET Virtual Domains This a review of what we covered: VLANs, VDOMs, Inter-VDOM links and VDOM topologies. FortiGate II Student Guide 173 DO NOT REPRINT © FORTINET Transparent Mode In this lesson, we will show you how to configure FortiGate to operate in transparent mode, and discuss differences with NAT mode. FortiGate II Student Guide 174 DO NOT REPRINT © FORTINET Transparent Mode After completing this lesson, you should have these practical skills that you can use to configure FortiGate features that are specific to transparent mode, such as STP and port pairing. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 175 DO NOT REPRINT © FORTINET Transparent Mode Traditional IPv4 firewalls and NAT mode FortiGates are routers, not just switches. So, each interface has to be in different subnets and each forms different broadcast domains. The FortiGate routes IP packets based on the IP header information, overriding the source MAC address. So, if a client sends a packet to a server connected to a different FortiGate interface, the packet will arrive to the server with a FortiGate’s MAC address, instead of the client’s. In the case of transparent mode, FortiGate forwards frames without changing the MAC addresses. When the client receives a packet from a server connected to a different FortiGate interface, the frame contains the server’s real MAC address – FortiGate doesn’t rewrite the MAC header. The FortiGate is a Layer 2 bridge or switch. So, the interfaces do not have IP addresses and all belong (by default) to the same broadcast domain. This means that a transparent mode FortiGate can be installed in a customer network without changing the customer’s IP address plan. Some customers, specially large organizations, don’t want to reconfigure thousands of devices to define a new “internal” vs. “external” network. FortiGate II Student Guide 176 DO NOT REPRINT © FORTINET Transparent Mode Here is an example showing NAT mode. FortiGate has 3 connected ports, each with separate IP subnets. All interfaces on the FortiGate have IP addresses, and, in this case, NAT translates between networks. Firewall policies allow traffic to flow between networks. FortiGate handles packets according to their routes, which are in most of the cases based on the destination IP address (at Layer 3 of the OSI model). Clients on each subnet send frames that are destined for a FortiGate MAC address – not the real MAC address of the server. FortiGate II Student Guide 177 DO NOT REPRINT © FORTINET Transparent Mode Here is an example showing transparent mode. Firewall policies still scan, then allow or block traffic. But there are differences. Notice that the physical interfaces on FortiGate have no IPs. So FortiGate won’t respond to ARP requests. There are only 2 exceptions. When changing to transparent mode, you must specify a management IP address to receive connections from your network administrators; and send log messages, SNMP traps, alert email, and so forth. This IP address is not assigned to any particular interface, but to the VDOM settings. You can configure individual interfaces with an IP to also apply NAT or PAT. (Note that this is rarely required. NAT with transparent mode is usually a misconfiguration: either FortiGate isn’t positioned correctly in your topology, or the appropriate operation mode wasn’t chosen.) By default, a transparent FortiGate won’t do NAT. Also, clients will send frames destined directly to the real router or server MAC address. FortiGate II Student Guide 178 DO NOT REPRINT © FORTINET Transparent Mode We have mentioned that a transparent-mode FortiGate acts as a transparent bridge. What does that mean? It means that FortiGate has a MAC address table that contains, among other things, the interface that must be used to reach each MAC address. FortiGate populates this table with information taken from the source MAC address of each frame. FortiGate, as a transparent switch, splits the network into multiple collision domains, reducing the traffic in the network and improving the response time. FortiGate II Student Guide 179 DO NOT REPRINT © FORTINET Transparent Mode In transparent mode, by default, each VDOM has a separate forwarding domain. Interfaces, though, don’t. How does this affect the network? Until you change the initial VDOM configuration, all interfaces, regardless of their VLAN ID, are part of the same broadcast domain. FortiGate will broadcast from every interface in the VDOM in order to find the destination MAC address. On large networks, this could generate massive broadcast traffic and overwhelming replies – a broadcast storm. FortiGate II Student Guide 180 DO NOT REPRINT © FORTINET Transparent Mode (slide contains animation) Here’s an illustration of the problem – a broadcast with all the interfaces on the forwarding domain 0 (default). An ARP “whois” is sent by a single device. It reaches FortiGate through one of the interfaces in the VDOM. (click) Because they all belong to the same forwarding domain, FortiGate then re-broadcasts to all interfaces, even to interfaces that belong to a different VLAN. This generates a lot of traffic. But in theory, the ARP reply still will arrive on only 1 interface, and FortiGate will learn that the MAC is on that interface. However, what if there is more than one path? FortiGate would rapidly switch between links because the last interface that receives an ARP reply with the MAC address will vary slightly. This will cause transmission problems: the 3-way TCP handshake involves 3 packets, and if the IP session is transferred from 1 interface to another in the middle of transmission, the handshake will fail. FortiGate II Student Guide 181 DO NOT REPRINT © FORTINET Transparent Mode (slide contains animation) As we explained, forwarding domains are like broadcast domains. Here’s the same network that we showed before for VDOMs, but here, VLAN 101 is only on 2 interfaces. Placing them in a separate forward domain ID (101) segregates them. (click) Traffic arriving on 1 interface is only broadcast to interfaces that are in the same forwarding domain. FortiGate II Student Guide 182 DO NOT REPRINT © FORTINET Transparent Mode You can use port pairing when only two interfaces need to be connected to the same broadcast domain. This is usually the case, for example, of a FortiGate connected between the internal network and the ISP’s router. When you configure port pairing, two ports are logically bound or linked, acting like a filtered cable or pipe. All the traffic that arrived to one port, is forwarded to the other port. This avoids issues related with broadcast storms or MAC address flapping. You could make more than one port pair in a FortiGate. FortiGate II Student Guide 183 DO NOT REPRINT © FORTINET Transparent Mode Here’s an example where 2 port pairs are used. This FortiGate has 4 ports, each connected to different physical locations. But traffic is not allowed to flow between all 4 locations. Port pairing only allow traffic between ports in the same pair: between port1 and port2, and between port3 and wan1. So in this example, the network on port3 can reach the Internet through wan1, but the networks on port2 and port1 can’t reach the Internet They can only reach each other. FortiGate II Student Guide 184 DO NOT REPRINT © FORTINET Transparent Mode Spanning tree protocol automatically ensures that there are no Layer 2 loops. By default, FortiGate does not participate in STP learning, nor forward BPDUs. But you can enable it. (You must still restrict broadcast domains so that they are not overwhelmingly large, though) FortiGate II Student Guide 185 DO NOT REPRINT © FORTINET Transparent Mode To enable the FortiGate to participate in the STP tree, use the “config system stp” command in the CLI. Note that this is only supported on models with switch interfaces, such as FortiGate 30D, 60C, 60D, 80C, and 90D . FortiGate II Student Guide 186 DO NOT REPRINT © FORTINET Transparent Mode Alternatively, and for interfaces that are not switch interfaces, you can either forward or block STP BPDUs. FortiGate II Student Guide 187 DO NOT REPRINT © FORTINET Transparent Mode This debug command is used to list the MAC address table in a VDOM that is operating in transparent mode. The table, as we explained before, contains the interfaces that must be used to reach each learned MAC address. FortiGate II Student Guide 188 DO NOT REPRINT © FORTINET Transparent Mode This is a review of the topics we covered. FortiGate II Student Guide 189 DO NOT REPRINT © FORTINET High Availability In this lesson, you will learn about FortiGate high availability (HA). FortiGate II Student Guide 190 DO NOT REPRINT © FORTINET High Availability When you’ve completed this lesson, you should be able to configure, operate, and monitor a FortiGate HA cluster. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 191 DO NOT REPRINT © FORTINET High Availability The idea of HA is simple. HA links and synchronizes 2 or more devices. Like HA you may have seen on other vendors’ products, one FortiGate device acts as the primary appliance (also called the active FortiGate): it synchronizes its configuration to the other devices. The other FortiGates are called secondary or standby devices. A heartbeat link among all the appliances is used to detect when any unit becomes unresponsive. What is synchronized among the units? Are all FortiGate devices processing traffic? Does HA literally improve availability, or does it improve throughput? The answers vary depending on the HA mode. There are currently two HA modes available: activeactive, and active-passive. Let’s examine the differences. FortiGate II Student Guide 192 DO NOT REPRINT © FORTINET High Availability (slide contains animation) Let’s examine first the active-passive mode. In any of the two HA operation modes, the configuration of the secondary FortiGates are synchronized with the configuration in the primary device. (click) In the case of the active-passive mode, the primary FortiGate is the only FortiGate device that actively processes traffic. secondary FortiGates remains in passive mode monitoring the status of the primary device. (click) If a problem is detected in the primary FortiGate, one of the secondary devices will take over the primary role. This event is what we call HA failover. FortiGate II Student Guide 193 DO NOT REPRINT © FORTINET High Availability The other HA mode is called “active-active.” Like with active-passive HA, in active-active, all FortiGates’ configurations are synchronized. Also, if a problem is detected with the primary device, one of the secondaries will take over the role of primary traffic processing. However, one of the main differences with active-passive mode is that in active-active mode all of the FortiGates are processing traffic. As we will see later, one of the tasks of a primary FortiGate in activeactive mode is to balance some of the traffic among all the secondary devices. FortiGate II Student Guide 194 DO NOT REPRINT © FORTINET High Availability (slide contains animation) FortiGate HA requires… First, at least 2, but up to 4, FortiGate devices with the same: • Firmware • Hardware model and VM license • Hard drive capacity and partitions • Operating mode (transparent or NAT) (click) Second, at least 1 link between the FortiGate units for the HA communication, which is called heartbeat traffic. For redundancy, up to 8 heartbeat interfaces can be used. If one link fails, HA will use the next one by priority and position in the heartbeat interface list. (click) Third, the same interfaces on each FortiGate unit have to be connected to the same switch or LAN segment. Notice that in this illustration, the FortiGate units are redundant to mitigate failure. But the switches and their links still are a single point of failure. As we will see later, you can also have redundancy in the network switches and links. (click) One important change in FortiOS 5.2, related with HA, is that now the cluster can include interfaces whose IP addresses are assigned dynamically, via either DHCP or PPPoE. Prior to FortiOS 5.2, a HA cluster could only contain interfaces with static IP addresses. FortiGate II Student Guide 195 DO NOT REPRINT © FORTINET High Availability The process for electing the primary FortiGate depends on a HA setting called HA override. This slide shows how a cluster elects the primary when that setting is disabled, which is the default behavior: The cluster compares first the number of monitored interfaces whose status are up. We will talk the HA monitored interfaces in a later slide. The FortiGate device with the most available monitored interfaces becomes the primary. The cluster compares the system uptimes. If the system uptime of a unit is 5 minutes more than the system uptimes of the other FortiGates, it becomes the primary. The FortiGate with the configured highest priority becomes the primary. Then the cluster chooses the primary by comparing the serial numbers. So with HA override disabled, the uptime has precedence over the priority setting. If for any reason you need to change which unit is the current primary, you can manually force a failover event. When the override setting is disabled, the easiest way of doing this is by executing the command ‘diagnose sys ha reset-uptime’ in the primary FortiGate. FortiGate II Student Guide 196 DO NOT REPRINT © FORTINET High Availability You can alter the order of what clusters consider when electing the primary FortiGate. If the HA override setting is enabled, priority precedes system uptime. This means you can specify which unit is preferably the primary by configuring it with the highest HA priority value. The disadvantage is that a failover event is triggered not only when the primary fails, but also, when the primary is available again, as it will take back its primary role from the secondary FortiGate that temporally replaced it. When override is enabled, the easiest way of triggering a failover is to change the HA priorities. For example, you can either increase the priority in one of the secondaries, or decrease the priority in the primary. FortiGate II Student Guide 197 DO NOT REPRINT © FORTINET High Availability So, what are the tasks of a primary? It monitors the cluster by sending “HELLO” signals, and listening for replies, to know if each other FortiGate is alive and available. It also synchronizes its routing table and part of its configuration to the other devices. You can optionally configure the primary FortiGate to synchronize some traffic session information to all the secondary devices. This allows a faster and seamless failover for some sessions. Some customers will not need to reestablish their sessions after a failure in the primary FortiGate. We will see later which session information can be synchronized. In active-active mode only, a primary FortiGate also distributes traffic among all the available devices in the cluster. FortiGate II Student Guide 198 DO NOT REPRINT © FORTINET High Availability Let’s see now the secondary FortiGate’s tasks. If the mode is active-passive, the secondaries simply wait, receiving synchronization data but not actually processing any traffic. If the primary FortiGate fails, the secondaries will elect a new primary. In active-active mode, though, secondary don’t wait passively. They process all traffic assigned to them by the primary device. FortiGate II Student Guide 199 DO NOT REPRINT © FORTINET High Availability (slide contains animation) To forward traffic correctly, a FortiGate HA solution uses virtual MAC addresses. When a primary joins an HA cluster, each interface is given a virtual MAC. Through the heartbeats, the primary informs all secondaries about the assigned virtual MAC. Upon failover, a secondary adopts the same virtual MAC addresses for equivalent interfaces. (click) The new primary broadcasts gratuitous ARP packets, notifying the network that each virtual MAC address is now reachable through a different switch port. FortiGate II Student Guide 200 DO NOT REPRINT © FORTINET High Availability As already explained, if a primary fails, a new primary is elected. But, what happens if a secondary FortiGate unit fails? It depends again on the HA mode. In an active-passive cluster, the primary only updates its list of available secondary FortiGates. It also starts monitoring for the failed secondary, waiting for it to come online again. In an active-active cluster, though, all secondaries are handling traffic. So the primary (which tracks and assigns sessions to each secondary) must not only update its list of available secondary FortiGates, but it must also reassign sessions from the failed FortiGate device to a different secondary FortiGate. FortiGate II Student Guide 201 DO NOT REPRINT © FORTINET High Availability This visualizes how the workload is distributed between roles, depending on the HA mode. Notice that traffic workload is not distributed in active-passive mode, but it is in active-active cluster. FortiGate II Student Guide 202 DO NOT REPRINT © FORTINET High Availability (slide contains animation) Let’s show how a HA cluster in active-active mode distributes traffic. (click) First, the client side sends a SYN packet. It’s forwarded always to the primary FortiGate using the internal interface’s virtual MAC address as the destination. (click) If the primary decides that the session is going to be inspected by an secondary, the primary forwards the SYN packet to the secondary that will do the inspections. In this case, the destination MAC address is the physical MAC address of the secondary FortiGate. (click) The secondary responds with SYN/ACK to the client and starts the connection with the server by directly sending a SYN packet. FortiGate II Student Guide 203 DO NOT REPRINT © FORTINET High Availability (slide contains animation) Next the client acknowledges the ACK. It’s forwarded again to the primary using the virtual MAC address as the destination. (click) The primary device forwards the packet to the secondary inspecting that session, using the secondary’s physical MAC address. FortiGate II Student Guide 204 DO NOT REPRINT © FORTINET High Availability (slide contains animation) When the server responds to the TCP SYN, again, the packet is sent to the primary using the external interface’s virtual MAC. (click) So the primary signals the secondary. (click) And it is the secondary the one who replies to the server. The idea is not to load balance bandwidth. The traffic is always sent first to the primary. The main objective is to share CPU and memory among multiple FortiGates for traffic inspection. FortiGate II Student Guide 205 DO NOT REPRINT © FORTINET High Availability There are multiple events that might trigger a HA failover, such as hardware or software failure in the primary FortiGate or an issue in one of the primary’s interfaces. When a failover is triggers an event log is generated. Optionally, the unit can also generate a SNMP trap and a alert email. FortiGate II Student Guide 206 DO NOT REPRINT © FORTINET High Availability There are two types of failovers: device failover and link failover. Let’s see the device failover first. It is basically triggered when the primary FortiGate stops sending heartbeat traffic. In that case, the secondaries renegotiate a new primary. The other type is link failover. You can configure a HA cluster to monitor the link status of some interfaces. If a monitored interface on the primary FortiGate is unplugged, or its link status goes down, a new primary FortiGate is elected. FortiGate II Student Guide 207 DO NOT REPRINT © FORTINET High Availability So how do the FortiGate units in a HA cluster communicate? FortiGate HA uses FGCP, the FortiGate clustering protocol, for HA-related communications. FGCP travels among the clustered FortiGate units over the links that you have designated as the heartbeats. A heartbeat link between two devices should be just a cable. If you have another device in between, such as a switch, ensure that it is dedicated and isolated from the rest of your network. In this way, critical FGCP traffic does not need to compete with other traffic for bandwidth. FortiGate II Student Guide 208 DO NOT REPRINT © FORTINET High Availability Now, we’ve seen how HA effectively transfers virtual IP addresses from a failed FortiGate unit to a different one. What about the heartbeat interfaces? You don’t need to configure them. FGCP will automatically negotiate the heartbeat IP addresses based on each unit serial number. 169.254.0.1 is assigned to the unit with the highest serial number, .2 to the device with the second highest serial number, and so on. This IP address assignation does not change when a failover happens. Regardless of the unit role at any time (primary or secondary), its heartbeat virtual IP address remains the same. A change in the heartbeat IP addresses might happen, although, when a FortiGate device joins or leave the cluster. In those cases, the cluster renegotiates the heartbeat IP address assignment, this time taking into account the serial number of any new unit, or removing the serial number of any device that left. FortiGate II Student Guide 209 DO NOT REPRINT © FORTINET High Availability (slide contains animation) To prepare for failover, a HA cluster keeps configurations in sync. Let’s study that now. FortiGate HA uses a combination of both incremental and complete synchronizations. When a new FortiGate is added to the cluster, (click) the primary compares the new secondary configuration. (click) If it does not match, the primary uploads its complete configuration to that secondary. FortiGate II Student Guide 210 DO NOT REPRINT © FORTINET High Availability After the initial synchronization is achieved, the primary will send any further configuration change done by an administrator to all the secondaries. For example, if you create an firewall address object, the primary doesn’t resend its complete configuration – just the new object. FortiGate II Student Guide 211 DO NOT REPRINT © FORTINET High Availability HA propagates more than just the configuration. Some runtime data, such as DHCP leases and routing tables, are also maintained in sync. Also, the cluster periodically checks that all units are synchronized. If any secondary is suddenly out of sync during 5 consecutives checks, a complete re-synchronization is done. FortiGate II Student Guide 212 DO NOT REPRINT © FORTINET High Availability Not all the configuration settings are synchronized. There are a few that do not, such as the HA override, virtual cluster and device HA priorities, hostname, ping server HA priorities and all the settings related with the HA reserved management interface (if any). So, this mean that if you want to be able to connect to each unit directly, you can reserve an interface for HA management, so its configuration will not be synchronized and each unit can have different management IP addresses. The HA reserved management interface can also be used by each unit to send SNMP traffic and logs independently. FortiGate II Student Guide 213 DO NOT REPRINT © FORTINET High Availability Session synchronization enables seamless failover for some traffic. The information of some sessions is synchronized, so when the primary fails, the new primary can take over those sessions where they were left and keep them open. Traffic might be interrupted for a few seconds, but the network applications don’t need to reconnect the sessions again. Once session synchronization is enabled, by default the unit synchronizes TCP and IPSec VPN sessions that comply with one requirement, which is basically not being handled by a UTM proxy, such as the antivirus, or web filtering. You can optionally enable the synchronization of UDP and ICMP sessions. Although both protocols are session-less, entries are created in the FortiGate session table for each UDP and ICMP traffic flow. Usually, this synchronization is not required, as most of the network applications based on UDP or ICMP are able to keep the communication even when their session information is lost. Synchronization of multicast and SSL VPN sessions is not supported. FortiGate II Student Guide 214 DO NOT REPRINT © FORTINET High Availability So far, we’ve discussed HA clustering where each FortiGate unit acts as a whole security domain. But if you have a HA cluster with multiple VDOMs, you can configure virtual clusters. Virtual clusters allow you, for example, to have one unit acting as the primary for one VDOM and as the secondary for a different VDOM. Each VDOM has a primary and an secondary FortiGate, and any unit can act as the primary for some VDOMs, and as the secondary for the other VDOMs at the same time. FortiGate II Student Guide 215 DO NOT REPRINT © FORTINET High Availability So, virtual clustering offers a failover mechanism per VDOM between two FortiGates. Virtual clustering can only be configured in a cluster operating in active-passive mode. As traffic from different VDOMs can go to different primary FortiGates, you can use virtual clustering to manually distribute your traffic between the two cluster units. FortiGate II Student Guide 216 DO NOT REPRINT © FORTINET High Availability The same as with a standalone device, when upgrading a HA cluster, each updating FortiGate unit must reboot. The cluster upgrades the secondary FortiGates first. Once all the secondary FortiGates are running the new firmware, a new primary is elected and the firmware in the former primary device is upgraded. If the cluster is operating in active-active mode, traffic load balancing is temporally disabled while all units are upgrading their firmware. FortiGate II Student Guide 217 DO NOT REPRINT © FORTINET High Availability At the beginning, we showed a simple HA topology. Now, let’s look at a more robust one. It is called flush mesh HA. The idea is to prevent any single point of failure, no only in the FortiGate units, but also in the network switches and interfaces. As you can notice in the slide, not only you have two FortiGates for redundancy, but also each FortiGate is connected to two redundant switches using two different interfaces. FortiGate II Student Guide 218 DO NOT REPRINT © FORTINET High Availability A flush mesh HA is more complicated to assemble and administer, but can provide the availability required by critical installations. This solution is only available with higher-end FortiGate models because not all FortiGate models are capable of creating aggregated or redundant interfaces, which are required for building this type of topology. FortiGate II Student Guide 219 DO NOT REPRINT © FORTINET High Availability FortiGate session life support protocol (FGSP) is an alternative to active-passive HA. It allows perVDOM session synchronization between two FortiGate devices in standalone mode. As we will see in the next slide, it requires external devices to balance sessions between each FortiGate. FGSP was formerly known in previous FortiOS releases as session synchronization. However, the FGSP feature has been expanded to support now not only TCP session synchronization, but also UDP, ICMP, and NAT session synchronization, as well as configuration synchronization. With FGSP, TCP sessions can only be synchronized if they do not require security profile or UTM inspection. FortiGate II Student Guide 220 DO NOT REPRINT © FORTINET High Availability So, FGSP is a simpler solution than HA because traffic redirection is done by external devices. In most FGSP implementations, two standalone FortiGate devices are installed between two load balancers. FortiGate II Student Guide 221 DO NOT REPRINT © FORTINET High Availability (slide contains animation) This is how you configure FGSP on each FortiGate. In this case, the port2 in VDOM root is used for session synchronization (similar to the heartbeat interface for HA). (click) In the CLI, under “config system session-sync,” you specify the IP address of the other FortiGate, (click) the name of the VDOM where the interface port2 is located, (click) and the name of the VDOMs whose sessions are going to be synchronized. FortiGate II Student Guide 222 DO NOT REPRINT © FORTINET High Availability By default, only TCP sessions with no NAT are synchronized. Usually, due to their non-stateful nature, UDP and ICMP sessions are not required to be synchronized. However, if such synchronization is wanted, you can enable it with the settings ‘session-pickup’ and ‘session-pickup-connectionless’. NAT sessions can also be synchronized with the setting ‘session-pickup-nat’. Finally, we can enable configuration synchronization with the command ‘standalone-configsync’. FortiGate II Student Guide 223 DO NOT REPRINT © FORTINET High Availability If the HA cluster has formed successfully, the GUI displays all the FortiGates, together with their hostnames and serial numbers. FortiGate II Student Guide 224 DO NOT REPRINT © FORTINET High Availability From the CLI, although, we can get more information about the status of the HA. For example, the command ‘diagnose sys ha status’ displays heartbeat traffic statistics, as well as the serial number and HA priority of each FortiGate. The command also shows the heartbeat interface IP address automatically assigned to the primary FortiGate. FortiGate II Student Guide 225 DO NOT REPRINT © FORTINET High Availability When troubleshooting any problem in a HA cluster, it is useful to know that you can connect to the CLI of any secondary from the primary CLI. You have to use the command ‘execute ha manage’ with the secondary HA index for that purpose. To get the list of secondary FortiGates with their HA indexes, you can use the question mark at the end of that same command. FortiGate II Student Guide 226 DO NOT REPRINT © FORTINET High Availability Another indication of the health of a HA cluster is the status of the configuration synchronization. To check that all the secondary configurations are synchronized with the primary configuration, you have to execute the command ‘diagnose sys ha showcsum’ in all the HA units. If a secondary FortiGate displays exactly the same sequence of numbers than the primary, its configuration its well synchronized. FortiGate II Student Guide 227 DO NOT REPRINT © FORTINET High Availability Here is a review of what we discussed. We showed: • The two HA modes: active-passive and active-active • How the primary FortiGate is elected • How the primary FortiGate in an active-active cluster distributes the traffic to the secondaries units • Which events can trigger a HA failover • Configuration and session synchronization • Virtual clustering • FGSP • How to check the health of a HA cluster FortiGate II Student Guide 228 DO NOT REPRINT © FORTINET Advanced IPsec VPN In this lesson, we will show you how to set up IPsec VPN topologies such as partial mesh or full mesh – in other words, complex point-to-multipoint VPNs. Although we’ll quickly review, you should already be familiar with site-to-site VPNs that are taught in the basic IPsec VPN lesson. This lesson assumes you are familiar with: • IPsec terminology, such as what is an SA and a peer • Diffie-Hellman exchanges • Quick Mode selectors • Policy-based vs. route-based VPNs • How to configure a point-to-point VPN • How to use the VPN monitor FortiGate II Student Guide 229 DO NOT REPRINT © FORTINET Advanced IPsec VPN After completing this lesson, you should have these practical skills that you can use to choose the right VPN topology for your needs, increase security and availability, optimize VPN performance, and troubleshoot tunnels. Unlike a simple static VPN – such as between two offices – VPNs between multiple dynamic and static peers require additional considerations. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 230 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) As we saw in the class for basic IPsec VPNs, on FortiGate, IPsec both authenticates and encrypts network traffic passing through FortiGate. Although the standard acknowledges the possibility of expansion, in practice, the 3 most used protocols are: • Internet Key Exchange (IKE), which does the handshake, tunnel maintenance, and disconnection • Encapsulation Security Payload (ESP), which ensures data integrity and encryption • Authentication Header (AH), which offers only data integrity – not encryption (click) Each FortiGate uses ESP to transport the packet payload, not AH, although the IPsec standard did define it. FortiGate II Student Guide 231 DO NOT REPRINT © FORTINET Advanced IPsec VPN Since we’ll expand first on IKE, let’s review a little about the key exchange, which uses port UDP 500 (and, if NAT-T is enabled, UDP port 4500). IKE establishes an IPsec VPN tunnel. FortiGate uses it to negotiate with the client and determine the security association (SA) – the authentication, keys, and settings that will be used to encrypt/decrypt that client’s packets. It is based on the Internet Security Association and Key Management Protocol (ISAKMP). Each SA is direction-specific. So in two-way traffic, there are 2 SAs per tunnel. As explained during the basic IPsec VPN class, IKE defines 2 phases. In phase 1, there are two possible negotiation methods: Main mode and Aggressive mode. Phase 2, where the tunnel keys are refreshed, only has quick mode. Main mode and aggressive mode have different considerations with dialup VPNs, so let’s study some details of the differences between main mode and aggressive mode. FortiGate II Student Guide 232 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) This shows main mode. 6 packets are exchanged. (click) First, the client initiates by proposing that the tunnel will use one or more security policies. (click) The responder selects which security policy it will agree to use, and replies. (click) Then, the initiator sends its key. (click) The responder replies with its own key. (click) Finally, the initiator sends its peer ID and hash payload, (click) and the responder replies in the same way. (click) Initially, the responder can only identify the initiator by the source IP address. Nothing else. This is because the initiator’s peer ID hasn’t been established yet. That works for point-to-point VPNs because both ends have static IPs, so the responder can predict the client’s ID, and knows which security policies to propose, even if you have configured multiple possible VPN settings. It’s also OK for a dialup VPN where you’ve configured only one Phase 1: the responder can’t predict the IP address of its peer, but only one proposal is possible. (click) However, it is a problem for a responder to have multiple possible proposals, and multiple possible peers. Then, it can’t predict which client is connecting at that IP. So it also doesn’t know which is the appropriate tunnel configuration to propose for each incoming connection attempt. So Main mode isn’t appropriate there. FortiGate II Student Guide 233 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) In comparison, let’s show aggressive mode negotiation. Only 3 packets are exchanged: (click) First, the client initiates by suggesting a security policy, and providing its key and peer ID. (click) The responder replies with the same information, plus a hash. (click) Finally, the initiator sends its hash payload. (click) Unlike main mode, the first packet contains the initiator’s peer ID. Therefore, the responder can use this ID (and not only the source IP address) to know who the peer is, and which security policy to use. It doesn’t require a static source address, nor only a single VPN configuration. But because the peer ID is exposed in the initial, unsecured exchange, attackers could see it and use it to try to make a fraudulent connection, so it’s safer to pair this mode with XAuth. FortiGate II Student Guide 234 DO NOT REPRINT © FORTINET Advanced IPsec VPN Another advanced Phase 1 option is XAuth. Phase 1 supports two types of authentication: pre-shared keys and digital certificates. The XAuth extension to IPsec requires that, between Phase 1 and Phase 2, clients also must supply a user name and password. So additional packets are exchanged if you enable it, making tunnel startup slightly slower, and you must configure FortiGate for user authentication. What is the benefit? Stronger authentication. FortiGate II Student Guide 235 DO NOT REPRINT © FORTINET Advanced IPsec VPN Like any half-open stateful connection, IKEv2 can be abused for denial of service (DoS). FortiGate has built-in protection for this VPN-specific type of DoS attack. FortiGate II Student Guide 236 DO NOT REPRINT © FORTINET Advanced IPsec VPN While showing how to choose between main mode and aggressive mode, we briefly mentioned effects of static vs. dynamic IP addresses. Let’s explain further. When configuring Phase 1, we must specify the type of remote peer. There are 3 types: • ‘Static IP Address’ • ‘Dynamic DNS’. This is where the peer’s IP is dynamic, but FortiGate can resolve it through a DNS query. This makes it – in effect – a static peer. For example, branch offices often use DHCP from an ISP. The IP address changes, but not often. So you could use Dynamic DNS to get a static DNS name that resolves to the dynamic IP. Then you would configure your FortiGate with the peer’s DNS domain name, which your FortiGate will query to resolve whenever it needs to connect. • ‘Dialup’ is (unlike its name implies) not necessarily through a dialup modem. It’s where the peer’s IP is dynamic, and there is no dynamic DNS. This is often true for branch offices, satellite campuses, and FortiClient VPN clients. Can these peers ever receive a VPN connection request? No, because they are a moving target. Your FortiGate can’t predict what their next IP address will be. Unlike Dynamic DNS peers, there is no way to find their current location on the IP network. FortiGate II Student Guide 237 DO NOT REPRINT © FORTINET Advanced IPsec VPN Now that we’ve seen some effects of dynamic vs. static IP addresses on configuration, let’s expand and see possible topologies with those. There are 5 types: • Point-to-point • Dialup • Hub-and-spoke • Full mesh • Partial mesh Point-to-point VPNs are simplest. 2 peers basically communicate directly. This topology, and how to configure it, was covered in the basic IPsec VPN lesson. Now, let’s see the other 4 topologies. FortiGate II Student Guide 238 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animations) First, here is a dialup VPN. Its geometry is simple. Dialup VPN is used when you don’t know where the remote peer will be connecting from, such as with travelling employees with FortiClient on their laptops. Unlike site-to-site VPNs, one dialup VPN configuration on your FortiGate can be used for multiple IPsec tunnels with many remote offices or users. Hence it’s other name, “point-to-multipoint.” (click) Remember that, in dialup, the client’s IP is dynamic, so FortiGate can’t predict where it will be. That means that FortiGate cannot initiate the VPN. Only the remote peer can. FortiGate II Student Guide 239 DO NOT REPRINT © FORTINET Advanced IPsec VPN One point-to-multipoint topology variation is called “hub-and-spoke”. Its name describes how all clients connect through a central “hub,” similar to how spokes connect to hubs on wheels. In this example, the clients – “spokes” – are each branch office’s FortiGate. For any branch office to reach another, its traffic must pass through headquarters. An advantage of this topology is that the VPN configuration and firewall policies are easily managed: they exist mostly on the central FortiGate. System requirements are also minimal for the branch office FortiGates, since each only needs to maintain 1 tunnel – 2 SAs. In total, only 4 tunnels – 8 SAs – are required. A disadvantage is that – especially if headquarters is physically distant like it can be for global companies – communications between branch offices through headquarters will be much slower than with a direct connection. If your headquarters is in Brazil and you have offices in Japan and Germany, latency can be very significant. If the FortiGate at HQ fails, VPN failure will be company-wide. Also, the FortiGate at headquarters must be much more powerful. It must be able to handle 4 tunnels simultaneously – 8 SAs. So what would a topology look like if some, or all, branch offices could bypass headquarters, and connect directly to each other? FortiGate II Student Guide 240 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) These are VPNs with a mesh topology. Two variations exist. (click) Full mesh connects every location to every other. Like the previous hub-and-spoke example, there are only 5 locations here. But to fully interconnect, every FortiGate requires 4 VPN tunnels – 8 SAs – to the others. This is 3 more tunnels per FortiGate than most in hub-and-spoke. In total, 20 tunnels are required, not 40. If you expand to 6 locations, it would require 30 VPNs, 7 locations would need 42, etc.. This topology causes less latency and requires much less headquarters bandwidth than hub-andspoke. Its disadvantage? Every FortiGate must be more powerful than the average hub-and-spoke FortiGate. (click) Partial mesh attempts to compromise, minimizing required resources but also latency. Partial mesh can be appropriate if communication is not required between every location. However, each FortiGate’s configuration is still much more complex than hub-and-spoke. Routing especially may require extensive planning. So generally, the more locations you have, hub-and-spoke will be cheaper (but slower) than a meshed topology. Mesh will place less strain on the central location, and be more faulttolerant (but more expensive). FortiGate II Student Guide 241 DO NOT REPRINT © FORTINET Advanced IPsec VPN To review, here is a quick comparison. Each topology has its benefits and tradeoffs, so you should choose the one that is most appropriate to your situation. FortiGate II Student Guide 242 DO NOT REPRINT © FORTINET Advanced IPsec VPN Now that we’ve shown the topological differences, let’s look at how to configure them. Before, we said that hub-and-spoke, full mesh, and partial mesh can be built using a combination of point-to-point (site-to-site) and point-to-multipoint VPNs. Point-to-point configuration was shown in the basic IPsec VPN lesson. And dynamic DNS is a slight modification of that. So let’s configure point-tomultipoint, called “Dialup VPN” on the GUI. Notice that the steps are the same. What is different? The settings. For each peer, we must: 1. Configure Phase 1. 2. Configure at least one phase 2. In this topology, you can have multiple, corresponding to the multiple peers. 3. Configure firewall policies. You may need static routes or a dynamic routing protocol. That way, once a peer joins the VPN and receives their virtual IP, its traffic can be routed through the VPNs. Remember there are two different ways to bring up the VPN on FortiGate: policy-based, or interface(route-) based. • For policy-based VPNs, additional routing entries are usually not required. Only one bidirectional firewall policy is required. • For interface-based VPNs, at least two firewall policies are usually required, one policy for each direction. FortiGate II Student Guide 243 DO NOT REPRINT © FORTINET Advanced IPsec VPN If your spokes are FortiClient installations and it’s a route mode VPN, then often you will want to enable and configure “Mode Config” on the hub’s Phase 1. This is for an IPsec extension called “IKE mode configuration.” It’s usually not practical to allocate static IPs to each of many laptops and mobile phones, for example. IKE mode configuration is an alternative. Like DHCP for VPNs, “Mode Config” automatically configures the client’s network settings. Like with DHCP, you define a range for the pool of VPN virtual IPs, the DNS settings, and the clients’ gateway router. Remember, these settings are all for the virtual network – not their local LAN. So they’ll usually be different. FortiGate II Student Guide 244 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) Let’s start by configuring a Phase 1 for the “hub” in a hub-and-spoke. (click) Since hub-and-spoke topology is a variation of point-to-multipoint, “Remote Gateway” must be set to “Dialup User”. (click) If each “spoke” requires a different policy, then usually we must configure multiple dialup VPNs. Remember, this requires IKE “Aggressive Mode,” which in turn requires both the key and the peer ID. (“Main Mode” key exchanges don’t support one-to-many topologies.) (Next, when we configure the spokes, the “spoke” FortiGate or FortiClient on the other end of the VPN tunnel must use that exact same ID: the hub identifies each spoke by its peer ID, and applies corresponding VPN settings.) (click) To strengthen authentication, you can enable XAuth. The hub FortiGate will use the “Enable as Server” setting. (Each FortiClient or spoke FortiGate will use “Enable as Client.”) Then, we select the user group than contains all the users (and credentials) that will be accepted by this VPN. (click) “NAT Traversal” should be enabled if your “spokes” are mobile dialup users, because they are usually behind NAT at airport terminals, home routers, and hotel firewalls. In this case, you’ll often want to enable “Mode Config” too. FortiGate II Student Guide 245 DO NOT REPRINT © FORTINET Advanced IPsec VPN Lastly on the hub, configure Phase 2. Usually the quick mode selector is 0.0.0.0/0 for both source and destination. This matches any connecting IP. (By the way, it also now supports IPv6.) Beginning with FortiOS 5.2, dialup clients can advertise a default route (0.0.0.0/0) as source subnet selector. Basically, this asks the hub to create a default route pointing inside the newly created tunnel. There was an accidental src-subnet 0.0.0.0/0 in the spoke’s phase 2. This could cause an Internet outage – traffic inside the tunnel could not leave the private network to reach the Internet! To avoid this, FortiOS 5.2 changed Phase 1’s default administrative distance (“set distance”). It was increased from 1 to 15. FortiGate II Student Guide 246 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) Next, let’s configure a spoke. This is Phase 1. (click) First, specify whether the hub for this spoke is using a “Static IP” or “Dynamic DNS.” (click) If the “Mode” is set to “Aggressive,” then, in the “Local ID,” enter the name that this spoke will use to identify itself to the hub. This ID must match the one we configured on the hub. (click) If you enable XAuth on the hub, you must enable XAuth on the spoke, too, and configure the user name and password. FortiGate II Student Guide 247 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) Finally, this is the spoke’s Phase 2. (click) For the quick mode selectors, the source address (that is, the Local Address) must be the spoke’s internal network. For interface-based VPNs, the hub will automatically add a static route to this subnet from the spoke’s IP, immediately after the VPN is established. (That way, you don’t need to manually configure the hub FortiGate with all static routes for each spoke.) (click) The destination (that is, the Remote Address) usually should be the hub’s network. Unlike with the source network, on the spoke FortiGate, you must manually add a static route to this destination network – it’s not added automatically. Note that unlike with point-to-point VPNs, quick mode selectors for point-to-multipoint do not need to mirror each other. FortiGate II Student Guide 248 DO NOT REPRINT © FORTINET Advanced IPsec VPN If your clients are FortiClient, there’s a simpler alternative to configure your spokes. Use the wizard. It will enable IKE Mode Config, XAuth, and other appropriate settings. FortiGate II Student Guide 249 DO NOT REPRINT © FORTINET Advanced IPsec VPN We mentioned briefly that hub-and-spoke is inherently not fault-tolerant: if the hub fails, then all VPN tunnels are down. How can you make your hub-and-spoke IPsec VPN more resilient? Provide a second ISP connection to your hub, and configure two interface-based VPNs. If the primary VPN fails, another tunnel can be used instead. Two types of redundant VPNs exist: • Partially redundant – On one peer (usually the hub, where a backup ISP is available if the main ISP is down), each VPN terminates on different physical ports. That way FortiGate it can use an alternative VPN if, for example, ISP1 or WAN1 fails. But on the other peer (usually the spokes), both VPNs terminate on the same physical port – so the spoke is not fault-tolerant. • Fully-redundant – Both peers terminate their VPNs on different physical ports. So both hub and spoke are fault-tolerant. FortiGate II Student Guide 250 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) So how can we configure a partially or fully redundant VPN? (click) First, create one interface-based Phase 1 for each path – one Phase 1 for the primary VPN, and one for the backup. Enable Dead Peer Detection (DPD) so that FortiGate will detect when the VPN tunnel to its peer is down, and switch to route traffic through the backup VPN. (click) Create a Phase 2, too. (click) Because these are interface-based VPNs, we must add at least 1 static route per VPN. Routes for the primary VPN must have a smaller distance than the backup. This causes FortiGate to use the primary VPN while it’s available. If the primary VPN fails, then FortiGate automatically adds the backup routes – which have a slightly larger distance, and wouldn’t otherwise be used – to the routing table. Alternatively, by the way, we could use a dynamic routing protocol, such as OSPF or BGP. (click) Finally, configure firewall policies to allow traffic through both the primary and the backup VPNs. Since these are interface-based VPNs, at least 2 firewall policies are required per VPN: one for each direction. FortiGate II Student Guide 251 DO NOT REPRINT © FORTINET Advanced IPsec VPN When you configure a VPN via the wizard, it won’t allow you to select multiple interfaces – so you can’t make a redundant VPN in the wizard. But after, you can do it. Simply edit the firewall policies. FortiGate II Student Guide 252 DO NOT REPRINT © FORTINET Advanced IPsec VPN With multiple redundant VPN tunnels for failover, proper dynamic routing would require that a route is only added when its associated virtual interface – and its tunnel – are up. This also allows VPNs to be configured on virtual WAN interfaces. In this way redundancy is built-in: the VPN will automatically apply to all interfaces current belonging to the virtual WAN. In the future, if you add to the virtual WAN, you won’t need to adjust VPN settings and firewall policies. FortiGate II Student Guide 253 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) As you can see, IPsec VPN configuration can be very complex. What is the best way to solve problems? When troubleshooting, look for setting mismatches first. Most connection failures are due to misconfiguration. Is a route missing? Is a firewall policy missing, or blocking the traffic? Are VPN settings mismatched? (click) If settings are correct, then you’ll enter most diagnostic commands on the responder FortiGate’s CLI, not the initiator’s. This is because from the initiator’s side, you can see only what the initiator sends – you cannot read the responder’s console, which would have messages that indicate why it has refused the connection. In comparison, the responder can see both: both the initiating packet, and the responder’s own decisions and response (if any). (click) If both sides of the VPN can reach each other to bring the tunnel up, then look for routing problems within the virtual network. Remember that once a peer joins the VPN, it has another IP address within the virtual network. If routes don’t exist to allow traffic to be routed between those IPs, then communication inside the VPN will fail, even though its containing tunnel is up. FortiGate II Student Guide 254 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) If settings are correct, you can use the command line to display details of the VPN tunnel as it occurs. (click) Run “diagnose debug reset” before and after each diagnostic session to reset and enable other IPsec diagnostic commands. They don’t usually significantly impact the CPU. However, you should always disable them after finishing the troubleshooting, because logging out will NOT stop a diagnostic command. (click) The filter command restricts debug logging to IPsec traffic from a specific remote peer. There are many different filter options. If the problem is a tunnel that is not coming up, you should filter based on the initiator’s IP address. After the filter is set up, you enable the IKE application debug with the value 255 to see all the output. (click) The output from the debug command is extensive. It details Phase 1 and 2 negotiations. We will not show the whole output here, but the next 2 slides will show the most important messages you should see if everything is OK. FortiGate II Student Guide 255 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) This shows some output for a successful Phase 1 negotiation using Main mode. (click) The first line shows the arrival of a VPN connection attempt from the IP address 172.20.187.114. The third line shows that the packet received was the first Main mode packet. (click) A bit later, the debug shows that FortiGate accepted the SA proposal from the remote peer. It shows the name of the Phase 1 that matches the proposal. In this case, it’s the name ‘Remote’. (click) FortiGate replies to the first Main mode packet. Then, the second Main mode packet arrives. (click) FortiGate replies again, and the third Main mode packet is received. (click) After finishing negotiation, the output will display two messages. They indicate that the key exchange was successful, and SA was established. FortiGate II Student Guide 256 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) Let’s see what is displayed during the phase 2 negotiation. Again the output is much longer than this. The slide only shows a sample of some parts of that output. (click) The first line announces the arrival of the first Quick mode packet. (click) The second line shows the Quick mode selector proposed by the remote peer. In this case, it is 0.0.0.0/0 for both the source and destination. (click) Some lines below, the debug displays the Quick mode selector that was successful negotiated between both peers. (click) The last two lines finally show that the tunnel is up and the phase 2 SA is established. If there is any problem in the establishment of either the phase 1 or 2, the output to the console shows the problem. FortiGate II Student Guide 257 DO NOT REPRINT © FORTINET Advanced IPsec VPN (slide contains animation) If the tunnel is up, but the traffic is not passing through the VPN, we can use the “diagnose debug flow” CLI command to troubleshoot. This will display, step by step, what each FortiGate module does with each packet. (click) With the first command, ‘diagnose debug flow filter’, set the filter that identifies which traffic to monitor. For IPsec, we usually filter with a valid IP address in the remote site. Then we enter the other 4 commands, and send traffic to that remote IP address. For example, we can try to ping the remote IP address from our local site. (click) If successful, we should see an output similar to this. (click) This line indicates that the packet was encrypted. (click) This other line indicates that the encrypted packet was sent to the tunnel with the name ‘HQ’. If there is a problem either encrypting or routing the packet, the output of this command will show the problem. FortiGate II Student Guide 258 DO NOT REPRINT © FORTINET Advanced IPsec VPN To review, this is what we talked about in this lesson. We showed how to choose between Main Mode and Aggressive Mode, how NAT Traversal works, extended authentication, VPN topologies, dialup VPNs, IKE mode configuration, and redundant VPNs. We also showed how to troubleshoot IPsec VPN tunnels. FortiGate II Student Guide 259 DO NOT REPRINT © FORTINET Intrusion Prevention System In this lesson, we will show you how to use FortiGate IPS. IPS is part of what makes FortiGate a UTM that can keep pace with the latest attacks. The lesson also covers DoS protection. FortiGate II Student Guide 260 DO NOT REPRINT © FORTINET Intrusion Prevention System After completing this lesson, you should have these practical skills. Essentially, you will learn how to use your FortiGate to study what is normal for your network, then detect and block rate anomalies and mechanism attacks. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 261 DO NOT REPRINT © FORTINET Intrusion Prevention System Before we begin, it’s important to understand: Not all attacks can be 100% positively identified. Sometimes, there is uncertainty. What is the difference between an attack and an anomaly? To compare, FortiGate IPS uses attack signatures where it can detect an attack with relative certainty and performance. But the IPS engine also can use heuristic methods to find statistical anomalies – unusual order in the packet flow. An example: the client uses the HTTP “MKCOL” method, but your web site has only static web pages, so it’s suspicious to use a method for dynamic sites. Many anomalies indicate a DoS attempt. So, FortiGate also provides DoS protection, which is executed either by specialized hardware or the kernel. FortiGate II Student Guide 262 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) Let’s define what IPS currently means on FortiGate. You may be surprised. On older systems, IPS might have meant purely a Snort-style signature matching. It was similar to anti-virus signatures, but for protocols instead of files. But on FortiGate UTM, IPS has evolved to also detect anomalous traffic patterns and to apply heuristics that prevent an unexpected behavior of the protocol. (click) Why? Aren’t IPS signatures enough? Some attacks can’t be successfully or efficiently defined in a signature. If the attack is qualitatively or quantitatively too similar to legitimate traffic, IPS false positives will block your network service – not the result you want. FortiGate II Student Guide 263 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) How does the IPS engine determine if a packet contains an attack or anomaly? Protocol decoders parse each packet according to the protocol specifications. Some protocol decoders do require a port number specification (configured in the CLI), but usually, the protocol is automatically detected. If the traffic doesn’t conform to specification – if, for example, it sends malformed or invalid commands to your servers – then the protocol decoder detects the error. For example, a stream of packets might match the HTTP decoder’s pattern named “Cisco.CatOS.CiscoView.HTTP.Server.Buffer.Overflow”. (click) A default, initial set is included in each FortiGate firmware. FortiGuard IPS service updates them, sometimes daily, with new signatures. That way, IPS remain effective against new exploits. Unless a protocol specification or RFC changes (which is not very often), protocol decoders are rarely updated. The IPS engine itself changes more frequently, but still not often. What part of IPS is updated most? The IPS signatures. New signatures are identified and built during the day by FortiGuard research teams, just like with antivirus. So if your FortiGuard Services contract expires, you can still use IPS. However, just like with anti-virus scans, IPS scans will over time become increasingly ineffective – old signatures won’t defend against new attacks. FortiGate II Student Guide 264 DO NOT REPRINT © FORTINET Intrusion Prevention System Regular updates are vital. If your FortiGate doesn’t have the latest signatures, your network is vulnerable. Always make sure that your FortiGate has a reliable Internet connection, and that it is scheduled to often request updates from FortiGuard. What is included in a FortiGuard IPS update? Protocol decoders, the engine, and signatures. The signature database is subdivided into Regular and Extended. FortiGate II Student Guide 265 DO NOT REPRINT © FORTINET Intrusion Prevention System Regular signatures are common attacks whose signatures, during testing prior to release on the FortiGuard Distribution Network, caused rare or no false positives. So it’s a smaller database, and its default action is to block the detected attack. Extended signatures contain everything else. In FortiOS 5.2, the IPS extended database is enabled by default for all FortiGate models that have multiple CP8. Otherwise, they are disabled, because either: • Performance impact is significant, or • Nature of the attack doesn’t support blocking By default, the Regular database is selected, not the Extended. In fact, due to its size, the extended database is not available for FortiGate models with a smaller disk and/or RAM. But for high security networks, you may be required to enable extended signatures. In that case, you should mark the “Enable Extended IPS Signature Package” option on System > Config > FortiGuard. FortiGate II Student Guide 266 DO NOT REPRINT © FORTINET Intrusion Prevention System When your FortiGate downloads new IPS signatures, or a new engine, syntax may change. So if you write your own custom signatures, especially after upgrading your FortiGate’s firmware, you may need to check if it’s still compatible. IPS involves anomaly inspection, deep packet inspection, full content inspection, activity inspection, and heuristic detection. Some software does not maintain a constant pattern. Skype and other peer-to-peer software, for example, periodically change in order to avoid detection. So in order to correctly identify it, IPS requires heuristics and adaptive detection. As a result, FortiGuard IPS also provides updates for application control, for example. FortiGate II Student Guide 267 DO NOT REPRINT © FORTINET Intrusion Prevention System When your FortiGate downloads a FortiGuard IPS package, new signatures will appear in the signature list. For each sensor that uses a signature, when configuring, you can change its “Action” setting. The default often is correct, except if: • Your software vendor releases a security patch. Continuing to scan for exploits will waste FortiGate resources. • Your network has a custom application with traffic that inadvertently triggers an IPS signature. You can disable it until you notify Fortinet so that FortiGuard can modify the signature to avoid false positives. The list of IPS signatures also indicates the severity level. What do the indicators mean? FortiGate II Student Guide 268 DO NOT REPRINT © FORTINET Intrusion Prevention System The FortiGuard severity level is based on the CVSS 2 rating system. There are many contributing factors. For details, go to the first.org web site. Do all severity levels match CVSS exactly? No. Fortinet always marks remote code execution as high or critical severity, regardless of the CVSS rating. Details are explained on the FortiGuard web site. FortiGate II Student Guide 269 DO NOT REPRINT © FORTINET Intrusion Prevention System Do you have the CVE ID or Microsoft ID for a specific vulnerability, but don’t know if there is a corresponding IPS signature yet? On the FortiGuard web site, you can search for the latest IPS signatures. But you can also read details about recently discovered zero-day attacks, white papers, blogs and security advisories. FortiGate II Student Guide 270 DO NOT REPRINT © FORTINET Intrusion Prevention System If you’re not sure if you should enable an IPS signature on your FortiGate, you can search the FortiGuard web site’s encyclopedia. The encyclopedia has useful information such as affected systems and recommended corrective actions. So if you don’t use that protocol or don’t have a vulnerable system, you can safely disable the corresponding signature. But if you are vulnerable, the encyclopedia can provide information about how to protect yourself. The FortiGuard encyclopedia only contains publicly disclosed vulnerabilities, though. Obviously it can’t contain vulnerabilities that, for whatever reason, can’t yet be responsibly disclosed. FortiGate II Student Guide 271 DO NOT REPRINT © FORTINET Intrusion Prevention System Exploits for unknown vulnerabilities – called zero-day attacks – are sold for large amounts of money on the black market. Since these exploits aren’t known to their vendors, nor to security experts, there’s no available patch or signature for detection. That’s what makes them so dangerous. Some companies and organizations like Facebook and Google have offered bounties for the responsible disclosure of these exploits, but there’s a very profitable market for black hat hackers to sell these discoveries to everyone from covert government surveillance to organized crime syndicates. Zero-day attacks are the keys to your network’s kingdom. FortiGate II Student Guide 272 DO NOT REPRINT © FORTINET Intrusion Prevention System If you notice an attack, your initial self-defense instinct may be to immediately take the server offline, then format it to remove all traces of malware. But by doing this, you’ll alert the attacker, and destroy forensic evidence. For motivated attackers, this will only educate them – their next attack will be harder to detect, and more sophisticated. Make sure your PSIRT team understands the most appropriate way to respond to each different type of intrusion. If you’re vigilant, and if you have the resources, you can also write your own custom IPS signatures. We’ll talk about how to do that next. FortiGate II Student Guide 273 DO NOT REPRINT © FORTINET Intrusion Prevention System Before you write custom IPS signatures, let’s first explain how the IPS engine works. FortiGate doesn’t compare traffic to each signature individually. This would require the CPU to load from disk and then evaluate each complete signature. In total, when fully enabled, this would be more than 8,000 disk accesses and comparisons. So instead, IPS compiles them into a decision tree, similar to the example shown here. FortiGate II Student Guide 274 DO NOT REPRINT © FORTINET Intrusion Prevention System FortiGate loads this entire decision tree into RAM. This can increase memory usage significantly, especially on desktop FortiGate models that don’t have much RAM. So if your RAM usage is already high, you should reduce it first before enabling IPS. Otherwise, your FortiGate may immediately enter conserve mode, and refuse to accept any more configuration changes! But the advantage is that the tree takes much less CPU and total RAM for a full IPS scan. To make the tree, FortiGate breaks down signatures into identical pieces – port, protocol, etc. – and shares the evaluation. So if traffic does not match that part, then the IPS engine can bypass comparisons with all similar signatures. But if it does match, then IPS continues with the next shared segment of the signature. When it finds a match, FortiGate applies its corresponding action. Remember discussing the difference between attacks and anomalies? Detecting uncertain attacks can require even more ongoing analysis, and more RAM to store traffic statistics. So if your CPU usage or RAM usage is high, and if you don’t require anomaly analysis for all protocols, clients, or servers, disable it. Better yet, offload it to an NP FortiASIC if your FortiGate model has them. Hardware accelerated anomaly detection can be configured in the CLI. FortiGate II Student Guide 275 DO NOT REPRINT © FORTINET Intrusion Prevention System To write custom signatures, first use packet capture to record packet samples. Understand and avoid mismatches with normal packets on your network, including at other OSI layers such as Layer 2 and Layer 3, which will be evaluated first. Remember: if you misconfigure a custom signature, or if you configure a custom signature that is no longer supported after you update the FortiGate firmware or IPS engine, problems like this often aren’t included in Fortinet Technical Support. So if possible, you should also test your custom signatures in a lab. FortiGate II Student Guide 276 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) We’ll show one example here. (click) All start with “F-SBID(”. (click) After that, protocol-specific key words define what part of the packet to search for a match, and what values comprise a match. Usually, a keyword is followed by a corresponding value that is its setting, except for a few standalone keywords such as “--no_case”. Each key-value pair ends with a semi-colon and a space. You can include multiple key-value pairs. The signature ends with the closing parenthesis. A reference to syntax for custom IPS signatures is in the FortiGate Handbook. Supported key words vary by the protocol decoders. For example, the SMTP protocol supports the “VRFY” command, and so there is a protocol decoder flag for it.. So if you create custom signatures, you should be sure to read the Release Notes and new Handbook before upgrading, and (if possible) test the firmware before installing it in a live traffic environment. Let’s see some examples. FortiGate II Student Guide 277 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) Here is a sample custom signature called “Ping.Death”. It searches for ICMP traffic that exceeds about 32 KB. (click) After you create and save the signature, FortiGate will automatically add an attack ID. So don’t include it when you enter the signature. (click) Next is a signature for HTTP. It searches for the pattern “POST” in a very specific location inside the packet. In normal HTTP POST requests, the method should be in this specific location. This prevents IPS from scanning the entire HTTP payload, which could contain a web page that accidentally matches, for example, due to the words “POSTAL CODE.” Your signature should be specific, but not too specific – extra comparisons reduce performance. FortiGate II Student Guide 278 DO NOT REPRINT © FORTINET Intrusion Prevention System Once you have created your custom signature, pair it with an action within an IPS sensor. Then reference that IPS sensor in a firewall policy. The steps are the same, by the way, regardless of whether you want to use custom signatures or ones predefined by FortiGuard. FortiGate II Student Guide 279 DO NOT REPRINT © FORTINET Intrusion Prevention System Here’s an example of an IPS filter being created. To include all signatures in the filter, we’ve marked ALL options. To include only a few signatures in the filter, we would only mark one option. For example, if we only marked the “Client” option, only 4 signatures would be included in the filter. Each individual signature can have multiple tags, such as HTTP, Microsoft, IIS, and TCP. The more specific you can make your filter, the less resources will be used to scan your traffic, because its parts will seldom match and so the IPS engine will quickly continue with the next comparison or scan. FortiGate II Student Guide 280 DO NOT REPRINT © FORTINET Intrusion Prevention System When the IPS engine compares traffic with the signatures in each filter, order matters. The rules are similar to firewall policy matching: topmost filters are evaluated first, and the first match applies. Subsequent filters are skipped. So position most likely matching filters at the top of the list, unless they might cause false positives. (Position those last, so that FortiGate will test them only if no previous, more sure signature matches.) Avoid making too many filters, since this will increase evaluations and CPU usage. Also avoid making very large signature trees in each filter, which will increase RAM usage – all unique pieces of the attack pattern must be loaded into RAM. Strike a balance. If an attack can be prevented in hardware (by NP FortiASIC chips, for example), or by another method (by disallowing an unnecessary protocol at the firewall level, for example), do this first. Then, for the remaining, craft careful IPS sensors to protect relevant vulnerabilities. For rate-based signatures (previously called anomalies), you can choose how to match: by source IP, destination IP, DHCP Client MAC, or DNS Domain Name. Choose whichever will generate the least entries yet behave correctly. For Internetfacing policies, this is unfortunately one that requires IPS to analyze many clients’ connections: Source IP. So enable only rate-based signatures for vulnerable protocols you actually use. Then block malicious clients for extended periods. This saves system resources and can discourage a repeat attack: FortiGate will not track statistics for that client while it is temporarily blacklisted. FortiGate II Student Guide 281 DO NOT REPRINT © FORTINET Intrusion Prevention System To apply an IPS sensor, enable IPS and then select the sensor in a firewall policy. FortiGate II Student Guide 282 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) So far we’ve shown signatures that match illegal commands and invalid protocol implementations. Those are easy to confirm as an attack. What about attacks that function by exploiting asymmetric processing, or bandwidth between clients and servers? There are many ways to make a Denial of Service attack. Some denial of service (DoS) attacks, for example, exhaust limited serverside bandwidth or sockets. Unless you know what bandwidth is abnormal for your network, you may not be able to confirm an attack. (click) The goal is to overwhelm the target – to consume resources until it can’t respond to legitimate traffic. This can be done in various ways. High bandwidth usage is only one type of DoS. Many sophisticated DoS such as Slowloris don’t require high bandwidth. For high-bandwidth DoS, remember that although your FortiGate blocks traffic floods, the flood is still consuming bandwidth up to the point of its external interface. So your servers are protected from impact, but if the upstream network is not, so your servers may still be effectively unavailable. Especially for distributed denial of service attacks, you must work with your ISP to fully prevent high-bandwidth DoS. FortiGate II Student Guide 283 DO NOT REPRINT © FORTINET Intrusion Prevention System To block DoS attacks, apply a DoS policy on a FortiGate that is between attackers and all resources that you want to protect. FortiGate II Student Guide 284 DO NOT REPRINT © FORTINET Intrusion Prevention System DoS protection exists for 4 protocols: TCP, UDP, ICMP and SCTP. Each one has 4 different types of anomaly detection. • A flood sensor detects a high volume of that particular protocol, or signal in the protocol. • Sweep/Scan detects attempts to map which of a host’s ports respond and therefore may be vulnerable. • Source signatures look for large volumes of traffic originating from a single IP. • Destination signatures looks for large volumes of traffic destined for a single IP. FortiGate II Student Guide 285 DO NOT REPRINT © FORTINET Intrusion Prevention System If you do not have an accurate baseline for your network, then when you implement DoS for the first time, be careful not to completely block network services. To prevent this, initially configure the DoS policy to log – but not block. Using the logs, you can analyze and determine normal and peak levels for each protocol. Then adjust the thresholds to comfortably, but not loosely, allow the usual peaks. Thresholds that are too high can allow your resources to be exhausted before the DoS policies trigger. Thresholds that are too low will cause FortiGate to drop normal traffic. FortiGate II Student Guide 286 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) Now we will take a look at some common types of DoS attacks. The first is called a ‘SYN flood’. In TCP, the client sends a ‘SYN’ signal to initiate a connection. The server must respond, then remember the start of the connection in RAM while it waits for the client to acknowledge (or ACK). Until ACK, the connection is only half-formed, so it won’t show up in a connection table. Normal clients will quickly ACK and begin to transmit data. But malicious clients continue – quickly or slowly, to avoid detection – to send more SYN packets, half-opening more connections, until the server’s table is full. Then, the server cannot accept more. It begins to ignore all new clients. Depending on the system, this attack can also damage hardware. (click) To defend against this, FortiGate acts as a pseudo-proxy. It waits until the client has finished connection build-up to form the back-end connection. If this doesn’t complete quickly, FortiGate begins to drop the attacker’s connection requests from the table. FortiGate II Student Guide 287 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) Another type of anomaly is an ICMP sweep. ICMP is used during troubleshooting: devices will respond with success or error messages. But attackers can use this to probe the network for valid routes and responsive hosts. (click) This provide information about your network before the attacker crafts more serious exploits. FortiGate II Student Guide 288 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) An individual DoS attack is a flood of traffic coming from a single address. It can originate from the Internet or even from your internal network. Typically a single device makes many connections or sessions, and possibly uses much bandwidth to a single location. (click) All four protocols in the DoS profile (ICMP, TCP, UDP, SCTP) have an anomaly sensor for the source. These are built to examine the traffic each IP is generating and compare that to the threshold value. FortiGate II Student Guide 289 DO NOT REPRINT © FORTINET Intrusion Prevention System (slide contains animation) A variation of this is the DDOS, or Distributed Denial of Service attack. It has many of the same characteristics. The main difference is that multiple devices are all attacking at the same time. This could be 5, or maybe 50, or 500 or more devices attacking together. (click) Remember earlier when we showed that despite FortiGate protecting the host, the resource could still become unavailable if the bandwidth to the ISP was consumed? Think about how these detections work. They do not trigger until the threshold is reached. Let’s say, for example, that the DoS sensor doesn’t trigger until 5000 sessions occur within 1 second. These 5000 sessions are allowed: first come, first served. So if multiple external devices are all generating connections to the same destination, attackers which are creating connections the fastest, will be the ones most likely to get the connections. Many of these DoS attacks can physically damage systems, so the goal is to prevent that from happening and prevent this kind of damage. But how can you find the right threshold? You must know what normal traffic thresholds are on your network – in other words, the baseline. FortiGate II Student Guide 290 DO NOT REPRINT © FORTINET Intrusion Prevention System Everything we have shown so far is inline scanning: traffic passes through FortiGate from one interface to another. But you can also deploy FortiGate outside of the direct path of packets, in a one-arm topology with a monitor-only mechanism. This is also called “sniffer mode” because it detects but does not block. To do this, connect FortiGate to a switch’s SPAN or mirroring port. The switch will send a duplicate of egressing packets to FortiGate, which FortiGate then scans. Notice that because it’s scanning a copy – not the original packet – it can’t modify or block the original packet. FortiGate II Student Guide 291 DO NOT REPRINT © FORTINET Intrusion Prevention System When should you use one-arm IPS? Historically, when IPS scanning was first invented, it was slow. Old IPS could introduce high latency. So one-arm deployment was common, but IPS on an inline firewall wasn’t. Now, hardware performance is much better. And one-arm has a significant limitation: one-arm FortiGate cannot block traffic. Because it’s on a mirrored port on the switch, not directly in between the attacker and your protected network, FortiGate isn’t placed to intervene. So today, most people use one-arm only during testing or evaluation. Think of “one-arm” IPS as “log-don’t-block.” FortiGate II Student Guide 292 DO NOT REPRINT © FORTINET Intrusion Prevention System Before sniffer mode, the only way you could demonstrate a FortiGate without changing IP addresses was to put it transparently inline with the traffic. This could potentially disrupt the network if you didn’t understand the Layer 2 topology. But now, there is no risk. FortiGate II Student Guide 293 DO NOT REPRINT © FORTINET Intrusion Prevention System Sniffer mode is enabled on a FortiGate’s physical interface, not a logical interface such as a VLAN. After you select “One-Arm Sniffer” on an interface, you can choose any security profile that uses the IPS engine. For example, you can use an application control profile if it is flow-based, since flow-based scans use the same engine as IPS. (Onearm DLP is also configurable, but via the CLI only.) FortiGate won’t allow you to choose proxy-based profiles that aren’t supported in one-arm inspection. Why aren’t all profiles/actions supported? It’s not technically possible. This is due to the nature of the topology and asynchronous scanning. To modify traffic or proxy connections, FortiGate must be in line – not out of band on a SPAN port – and stop the packet until it finishes scanning. That is, inspection must be in sync with the connection. However, one-arm scans after the interface has already forwarded the packet. Scanning and forwarding are out of sync. Since the packet has already egressed, FortiGate can’t proxy or block. That’s why it’s not possible to support all features in this mode. FortiGate II Student Guide 294 DO NOT REPRINT © FORTINET Intrusion Prevention System Now let’s see some logs that are generated by IPS. Anomalies and signature matches have different logs associated with them. Since an anomaly’s name already gives information about the traffic and the attack, such as protocol and source address, many details in the logs aren’t needed. But you often will require information about which applications or operating systems are vulnerable. You also need to know the action – whether FortiGate blocked or simply monitored (“detected”) the attack. If you configured FortiGate to only monitor, you may need to forensically investigate the targeted host. This is where host-based tripwires can be useful. FortiGate II Student Guide 295 DO NOT REPRINT © FORTINET Intrusion Prevention System When DoS policies generate logs, they are aggregated. When several incidents occur together, this reduces the number of log messages. In large attacks, the number of incidents can easily reach 100,000 in a few seconds. Generating a log entry for every packet that matches would completely utilize the CPU. So instead, FortiGate collapses incidents by periodically recording only one message for all of them, and noting the number of incidents. Here, the detection threshold was 50, and the total count is 75. So FortiGate doesn’t make 24 separate log entries (1 for each incident above 50). It’s just one log message. FortiGate II Student Guide 296 DO NOT REPRINT © FORTINET Intrusion Prevention System In the CLI, use ‘diag ips anomaly list’ to show all hosts that are currently being limited by DoS policies, and by what signature. If there’s no matching traffic, then it will not display any output. FortiGate II Student Guide 297 DO NOT REPRINT © FORTINET Intrusion Prevention System Another available diagnostic command is ‘diag autoupdate version’. This lists various IPS databases and engines that are installed on the FortiGate. It also displays the results of the last update attempt. So it can be useful if you suspect interruptions to FortiGuard connectivity. FortiGate II Student Guide 298 DO NOT REPRINT © FORTINET Intrusion Prevention System Another command that can be used is troubleshoot the IPS is ‘diag test app ipsm’. For example, you could type ‘diag test app ipsm 99’. FortiGate II Student Guide 299 DO NOT REPRINT © FORTINET Intrusion Prevention System What does the IPSEngine actually do? Notice that if you run the ‘diag test app ipsm 5’ command, and if you have any kind of flow-based inspection profile, the CPU usage of the IPSEngine process drops dramatically, but doesn’t reach 0. This is because IPSEngine is responsible for most of the things we’ve shown in this class: intrusion protection, and protocol decoders. It’s also responsible for application control, flow-based policies for antivirus, web filtering, email filtering, and DLP. FortiGate II Student Guide 300 DO NOT REPRINT © FORTINET Intrusion Prevention System Here is a review of what we discussed. We showed: • The difference between a signature that matches a known attack, versus one that matches a traffic pattern anomaly • How protocol decoders find anomalies, and how this is different than proxy-based scans • Severity levels • How to configure IPS sensors, including ones with custom signatures • Denial of Service attacks, which are a type of anomaly • One-arm deployment, both its limitations and purpose • IPS logs • Diagnostic commands for IPS, including expected output, since some processes of the IPS engine are used by other scans FortiGate II Student Guide 301 DO NOT REPRINT © FORTINET FSSO In this lesson, we will talk about Fortinet Single Sign On (FSSO). With this FortiGate feature, your users do not need to log in repeatedly, each time they access a different network resource. FortiGate II Student Guide 302 DO NOT REPRINT © FORTINET FSSO After completing this lesson, you should have these practical skills. You will be able to compare the access methods for collecting user login information using FSSO. You will also learn how to configure and test an FSSO solution to transparently authenticate users. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 303 DO NOT REPRINT © FORTINET FSSO FSSO enables FortiGate to leverage your network’s existing authentication system for firewall authentication. Once a user logs in, he or she can access other network resources without having to authenticate again. FSSO is typically used with directory service networks such as Windows Active Directory (AD) or Novell eDirectory. But it can also be implemented in other network environments. FortiGate II Student Guide 304 DO NOT REPRINT © FORTINET FSSO Depending on the server that provides your directory services, you will deploy and configure FSSO differently. In this presentation, we are going to talk mostly about the two methods available for Windows Active Directory environments. FortiGate II Student Guide 305 DO NOT REPRINT © FORTINET FSSO Let’s start with the domain controller agent mode. It requires: One domain controller agent installed on each Windows domain controller. (If you have multiple DCs, this means multiple DC agents.) The DC agents, as we will see later, monitor and forward user logon events to another FSSO component called the collector agent. The collector agent is installed on a Windows server. It consolidates events received from the DC agents, then forwards them to FortiGate. FortiGate II Student Guide 306 DO NOT REPRINT © FORTINET FSSO (slide contains animation) Here we show what happens between DC agents, the collector agent, and a FortiGate configured for FSSO authentication. When users authenticate with the DC, they provides their credentials. (click) The DC agent notices the logging event, and forwards it to the collector agent. (click) The collector agent aggregates all logon events, then forwards that information to FortiGate. The information sent by the collector agent contains the: User name, Host name, IP address, User group(s). Now FortiGate knows who the user is at that IP address, and which Active Directory group permissions also apply. (click) So if the person now tries to access the Internet, FortiGate compares the source IP address to its list of active FSSO users. In this case, the user has already logged on, so FortiGate will not request the user to authenticate again. FortiGate II Student Guide 307 DO NOT REPRINT © FORTINET FSSO Let’s see polling mode. This can be either agent-based, or agentless. First, let’s look at the agent-based polling mode. Like the DC agent mode, this requires a collector agent to be installed on a Windows server. However, it doesn’t require DC agents installed in each DC. But the tradeoff is that the server with the collector agent must be more powerful, and it will also generate unnecessary traffic when there have been no logon events. In this mode, the collector agent contacts periodically the DC and gets its information directly. FortiGate II Student Guide 308 DO NOT REPRINT © FORTINET FSSO (slide contains animation) Let’s see an example of FSSO using the agent-based polling mode. Here again is a DC, a collector agent, and FortiGate. But the DC doesn’t have an agent installed. (click) The collector agent periodically polls the DC to ask if anyone has logged in. (click) Next, the collector agent sends the login information to FortiGate. This is the same as the DC agent mode. (click) When user traffic arrives at the FortiGate, it already knows who is at that IP address, and no repeated authentication is required. FortiGate II Student Guide 309 DO NOT REPRINT © FORTINET FSSO In the cases of agent-based polling mode, there are two methods (or options) for getting logon information: • Security Event Log (WinSecLog): Polls the security events on the DC. It does not miss any logon events, because events are not normally deleted from the logs. But there can be some delay in FortiGate receiving these events if the network is large and therefore writing to the log is slow. • NetAPI: Calls the ‘netsessionenum’ function on Windows. This is faster than the other method, because it is reading a table in RAM. But the other effect is that it can sometimes miss logon events if a DC is under heavy system load. This is because sessions can be quickly created and purged from RAM, before the agent has a chance to poll and notify FortiGate. FortiGate II Student Guide 310 DO NOT REPRINT © FORTINET FSSO Finally, you can alternatively deploy FSSO without installing any agents. FortiGate will poll the DCs directly, instead of receiving login information indirectly from a collector agent. Because FortiGate collects all of the data by itself – remember, the DCs never initiate contact with a FortiGate to send login information – this method requires greater system resources on your FortiGate, and it doesn’t scale as easily. Additionally, this mode supports only the WinSecLog option. It does not support the NetAPI option as in the case of agent-based polling mode. FortiGate II Student Guide 311 DO NOT REPRINT © FORTINET FSSO (slide contains animation) Here we see FortiGate polling the DC. There is no collector agent, nor any DC Agent. (click) After the user logs in, FortiGate will discover that authentication during its next poll. (click) Again, when the user sends traffic, FortiGate already knows whose traffic that is. FortiGate II Student Guide 312 DO NOT REPRINT © FORTINET FSSO Regardless of the login collector method you choose, some FSSO requirements for your Active Directory network are the same: Microsoft Windows logon events only have the workstation name and username, but not the workstation IP address. When the collector agent gets a logon event, it will query a DNS server to resolve the IP address of the workstation. So, FSSO requires that you have your own DNS server. If a workstation IP address changes, DNS records must be updated immediately. Collectors must have connectivity with all workstations. Because an event log is not generated upon logoff, either the FortiGate or the collector agent (depending on the FSSO mode) must use a different method to verify whether users are still logged on. So, polls are done to each user workstations to see if users are still there. FortiGate II Student Guide 313 DO NOT REPRINT © FORTINET FSSO This table summarizes the main differences between DC agent mode and polling mode. DC agent solutions are usually more complex: it requires not only a collector agent, but also a DC agent per DC. However, it’s more scalable because the workload is distributed among all of the agents (the collector agent and the DC agents). Additionally, this deployment offers redundancy, because you can have more than one collector agent. And because the DC agent is hosted on the DC itself, all logon events will be captured and recorded. In comparison, if you use polling, some logon events might be missed or delayed, depending on the polling option used. FortiGate II Student Guide 314 DO NOT REPRINT © FORTINET FSSO In an Active Directory environment, FSSO can also work with NTLM authentication. We will see next an example of how NTLM authentication works. NTLM authentication does not require DC agents, but it is not fully invisible to users: they must enter their credentials again when the NTLM negotiation happens. Also, NTLM authentication is a Microsoftproprietary solution, so it can only be implemented in a Windows network. NTLM is most useful when either: Users log into DCs that, for some reason, cannot be monitored by the collector agent, or When there is a communication problem between the collector agent and one of the DCs agents. In other words, NTLM authentication is best used as a backup to FSSO. FortiGate II Student Guide 315 DO NOT REPRINT © FORTINET FSSO (slide contains animations) This shows how the messages flow during NTLM authentication. The process is triggered when FortiGate receives traffic from an IP address that doesn’t exist in the list of active FSSO users. (click) FortiGate replies with an NTLM challenge, requesting credentials. (click) The user enters the user name and password. (click) FortiGate receives them, then authenticates them with the collector agent. FortiGate will also get from the collector agent the user groups that the user belongs to. (click) If the credentials are correct, FortiGate authorizes the access. FortiGate II Student Guide 316 DO NOT REPRINT © FORTINET FSSO We mentioned that, unlike full FSSO, NTLM authentication is not transparent for users. This is because, in most of the browsers, and by default in Internet Explorer, users must manually enter their credentials whenever the browser receives a NTLM authentication challenge. However, Internet Explorer can be configured to automatically send the user’s Active Directory credentials each time it receives an NTLM challenge. To do this, open Internet Explorer’s Internet Options dialog and switch to the Security tab. Then click the “Custom Level” button and select the option “Automatic logon with current user name and password”. FortiGate II Student Guide 317 DO NOT REPRINT © FORTINET FSSO All FortiGate configurations include a user group called SSO_guest_user. When only passive authentication is used, all the users that do not belong to any FSSO group are automatically included in this guest group. This allows an administrator to configure limited network access to guess users that do not belong to the Windows Active Directory domain. However, if both passive and active authentication are in placed, the behaviors is different. Users that do not belong to any FSSO group will be prompted to enter their credentials. FortiGate II Student Guide 318 DO NOT REPRINT © FORTINET FSSO Another FSSO setting that we must configure is called “AD Access Mode”. It specifies how the collector agent accesses and collects the user and user group information. There are two modes: standard and advanced. Differences include the naming convention used to provide the domain and user name. Standard mode uses the Windows convention: Domain\Username. Advanced mode uses the LDAP convention: CN=User, OU=Name, DC=Domain. If there is not any special requirement, use standard mode. Advanced mode, however, supports nested or inherited groups. This means that users may be members of subgroups that belong to monitored “parent” groups. Additionally, advanced mode enables FortiGate to apply protection profiles to individual users and to user groups. In comparison, with standard mode, protection profiles can only be applied to user groups – not individual users. FortiGate II Student Guide 319 DO NOT REPRINT © FORTINET FSSO Let’s see the FSSO configuration now. This is the collector agent. From the FSSO Agent Configuration application, we can configure settings like the: • • • • Listening port for the communication with the DC agents. Listening port for the communication with the FortiGate. Enabling or disabling NTLM authentication. And, enabling pre-shared password authentication between the collector agent and the FortiGate. From the FSSO Agent Configuration tool, we can also access the collector agent logs, which can be used to troubleshoot FSSO issues. FortiGate II Student Guide 320 DO NOT REPRINT © FORTINET FSSO By clicking on the “Set Directory Access Information” button, we can select either standard or advanced Active Directory access mode. FortiGate II Student Guide 321 DO NOT REPRINT © FORTINET FSSO FortiGate FSSO configuration is straightforward. If FortiGate is acting as a collector for agentless polling mode, we must select “Poll Active Directory Server” and configure the IP addresses and Active Directory “Administrator” credentials for each DC. If we have external collector agents (either using the DC agent mode or the agent-based polling mode), we must select “Fortinet Single Sign On” and configure the IP address and password for each collector agent. FortiGate II Student Guide 322 DO NOT REPRINT © FORTINET FSSO Let’s see now some of the diagnostic commands available in FortiGate for FSSO. To shows the status of the communication between the FortiGate and each collector agent, use the CLI command “diagnose debug authd fsso server-status”. FortiGate II Student Guide 323 DO NOT REPRINT © FORTINET FSSO To display the list of FSSO users that are currently logged on, use the command “diagnose debug authd fsso list”. For each user, we see the user name, user group, and the IP address and workstation name from which they logged in. FortiGate II Student Guide 324 DO NOT REPRINT © FORTINET FSSO These are some additional FSSO commands, all of them under “diagnose debug authd fsso”. For example, there are commands for: • Clearing the FortiGate’s cache of all currently logged in users. • Filtering the display of that list. • Refreshing the logon and user group information. FortiGate II Student Guide 325 DO NOT REPRINT © FORTINET FSSO Here is an overview of what we discussed. We compared the methods for collecting user login information using FSSO. We also showed NTLM authentication and AD access modes. Additionally, you learned how to configure FortiGate and the collector agent for FSSO, how to troubleshoot it and monitor it. FortiGate II Student Guide 326 DO NOT REPRINT © FORTINET Certificate Operations In this lesson, you will learn how to manage certificates on FortiGate, and how to inspect the contents of encrypted traffic. FortiGate II Student Guide 327 DO NOT REPRINT © FORTINET Certificate Operations After completing this lesson, you should have these practical skills in certificate management, such as how to upload certificates, private keys, and CRLs where appropriate, and how to configure a FortiGate device and browsers to use certificates and keys for SSH, SSL, or TLS content inspection, as well as troubleshooting common misconfigurations. FortiGate II Student Guide 328 DO NOT REPRINT © FORTINET Certificate Operations Secure traffic protects your communications between you and someone else. There are 4 properties that define security in this case: data privacy, data integrity, authentication, non-repudiation. Not all secure channels will require all four features. The RFC for IPSec VPN allows tunnels to be built with no encryption. However, people almost always want privacy for important data and it’s usually pointless to make data private if you don’t know who sent it, and that it hasn’t been tampered with, in practice, most secure traffic has at least the first 3 properties. FortiGate II Student Guide 329 DO NOT REPRINT © FORTINET Certificate Operations Data privacy is achieved with encryption. Encryption applies an algorithm and key to the information, making it unintelligible to a third party before it travels across the network. Only the intended recipient, who also knows the pattern, is able to decrypt the data and access the information. There are multiple ciphers in common use, such as triple DES and AES-256. The “strength” of a cipher varies by the computational requirements for an attacker to recover the plain text. FortiGate II Student Guide 330 DO NOT REPRINT © FORTINET Certificate Operations Your data may be private, but could be corrupted in transit or falsified by a third party, therefore your traffic isn’t secure. How do we guarantee that an encrypted message arrived intact? There are several methods to verify data integrity; generally these are checksums (CHKSUM), or one-way hashes, which generate a unique value from applying the hashing algorithm to the original clear text. The sender would send the cipher text and the hash; the receiver would recover the plain text and recalculate the hash, if the calculated hash is the same as the received value, then the message is intact. FortiGate II Student Guide 331 DO NOT REPRINT © FORTINET Certificate Operations Authentication is a cornerstone of secure computing. When transmitting and receiving secure data, it is important to include the identity of the message originator. Asymmetric cryptography is often used to achieve this: a message checksum is calculated and signed using the sender’s private key, the receiver recovers the checksum using the sender’s public key, which is commonly published in a certificate; this mechanism is used in PKI. FortiGate II Student Guide 332 DO NOT REPRINT © FORTINET Certificate Operations Authentication supports the concept of non-repudiation, which means a sender cannot claim they did not send a particular message because the sender’s identity is bound to it. Again, data integrity is important because you want to ensure non-repudiation data is not forged. FortiGate II Student Guide 333 DO NOT REPRINT © FORTINET Certificate Operations Several methods of encryption involve using a piece of data called a “key” to mathematically scramble the message in a way that only the recipient can predict and undo. In symmetric cryptography the same key is used for encryption and decryption, both sides agree upon an algorithm and generate the same key, before sending messages. Plain text is processed through the agreed symmetric algorithm and key, generating the encrypted text, or cipher text. The receiver reverses this process to recover the plain text. FortiGate II Student Guide 334 DO NOT REPRINT © FORTINET Certificate Operations A key generation mechanism is required to generate the shared keys; this mechanism needs to be secure and repeated regularly to limit the amount of data exposed should a key be compromised. Symmetric cryptography is typically used for the bulk encryption of user data, because it is computationally much faster than asymmetric encryption, discussed next. FortiGate II Student Guide 335 DO NOT REPRINT © FORTINET Certificate Operations Asymmetric cryptography is a technique that uses a pair of keys: a public key and a private key. Both keys are mathematically related. They are generated from the same random number, and using the same key generator algorithm. However, because of the algorithm (large prime numbers are popular since these are impossible to factor, and very difficult and rare to find) it is extremely difficult to get the private key from the public key. It is practically impossible to guess the public key from the private key. What is encrypted with the private key can only be decrypted with the public key. In a similar way, what is encrypted with the public key can only be decrypted with the private key. FortiGate II Student Guide 336 DO NOT REPRINT © FORTINET Certificate Operations Public keys are distributed publicly. Private keys are never distributed, and must be kept secret by the owners. Public keys can be distributed using different methods: email; secure web sites; public repositories; using a Public-Key Infrastructure (PKI) server such as a CA (Certificate Authority). Private keys must be stored in a secure and private place, such as a file in a single physically secure location with very restrictive permissions. FortiGate II Student Guide 337 DO NOT REPRINT © FORTINET Certificate Operations In this example of asymmetric cryptography, the sender obtains the recipients public key to encrypt a message, only the recipient can decrypt this message using the corresponding private key. If the identity of the public key cannot be verified, using PKI, then there is a potential for a man-in-the-middle attack, allowing a third party to view the clear text without having to brute force the encryption key. FortiGate II Student Guide 338 DO NOT REPRINT © FORTINET Certificate Operations How can encryption be used to strengthen authentication? A digital certificate is a digital credential that identifies someone or something. That someone or something could be either a network user, a network service or a network device. The certificate contains information about the “entity” that is being identifying, including the entity’s public key. A digital certificate is issued and signed by a Certificate Authority (or CA), which certifies that the digital certificate and its content, is trustable and valid. FortiGate II Student Guide 339 DO NOT REPRINT © FORTINET Certificate Operations Digital certificates can be classified into three groups. A CA certificate identifies a certificate authority. It contains the CA’s public key that is needed to decrypt the signatures in the local service and user certificates. A local service certificate identifies a network service, such as an HTTPS web site or email server. A user certificate identifies a network user. User and local service certificates are also called end-entity certificates. FortiGate II Student Guide 340 DO NOT REPRINT © FORTINET Certificate Operations Certificates include information about the entity. They also contains information about the CA that signed the certificate. These are the most important fields that any certificate has: There is a serial number that is unique to each certificate signed by the same CA. In the case of a user certificate, the ‘Subject:’ contains the user login name. In the case of a local service certificate, the ‘Subject:’ can contain either the FQDN or the IP address of the server. The Signature of the CA is encrypted using the CA’s private key. The Issuer field is the name of the CA that signed the certificate. The ‘Valid-From:’ and ‘Valid-To:’ fields specify when the certificate is valid, including the expiration date. ‘Key-Usage:’ defines the roles and activities the certificate can be used in. FortiGate II Student Guide 341 DO NOT REPRINT © FORTINET Certificate Operations When a user authenticates, they send a digital certificate which includes not only their public key, but also the signature of the CA that certifies their certificate, which is encrypted using the private key of the CA. The authentication server must “trust” the CA. In other words, it must have the certificate of the CA that signed the user’s certificate. That CA certificate contains the CA’s public key, allowing the authentication server to decrypt/validate anything encrypted/signed by the CA’s private key. Additionally, for a user certificate to be valid, it cannot be listed as untrustworthy in a certificate revocation list. Furthermore, the user certificate must be within its validity period; that is, not expired. If any of these verifications failed, the user authentication would fail. FortiGate II Student Guide 342 DO NOT REPRINT © FORTINET Certificate Operations An HTTPS server(a website) identifies itself by using a digital local service certificate. When a user is connecting to the web site, the browser receives the web site’s local service certificate. In this case, it is signed by a CA called CA1 and the signature is encrypted using CA1’s private key. The user’s browser must “trust” the entity that issued the certificate. In other words, it must have the CA certificate of CA1 installed, which contains CA1’s public key. This public key is used to decrypt and validate the signature in the web site’s local certificate. The most common browsers already have preinstalled the CA certificates of the well-known public CAs. So, installing the CA certificate in the browser is usually not required as long as the web site’s certificate has been signed by a well-known CA. However, it is a required step if the certificate has been signed, for example, by a private CA. The browser also verifies that the certificate is still valid and has not expired yet. Additionally, the certificate must not be listed in any certificate revocation list. If any of these verifications fails, the browser will give a ‘certificate warning’ to the user, indicating that something is not right with the site being visited. FortiGate II Student Guide 343 DO NOT REPRINT © FORTINET Certificate Operations SSL is the cryptographic protocol used by the HTTPS protocol, and by other standard protocols, such as SMTPS and FTPS. When a connection is made to an HTTPS site, this is the protocol used between the web server and the browser to authenticate and encrypt the data. This is a fairly simplistic look at how SSL negotiations happen, which highlights both client and server certificate validation. 1. First a secure (HTTPS) URL is entered into the browser. 2. The browser then sends a Hello packet to the web server which includes the local certificate. 3. The server evaluates the certificate for validity. Does it trust the CA that signed the certificate? Is the certificate still valid? Has the certificate been revoked? The server evaluates the clients certificate in order to decide if it meets whatever security options there are. 4. Assuming the certificate is accepted the server sends a Hello back with it’s own certificate and the browser performs it’s own security checking on the servers certificate. FortiGate II Student Guide 344 DO NOT REPRINT © FORTINET Certificate Operations The browser (as the client) creates a symmetric key. This symmetric key is encrypted using the server’s public key which was received as part of the certificate in the Hello. The encrypted symmetric key is then sent to the server and decrypted using the servers Private key. A 3rd party that does not have access to the private key of the server or browser cannot decrypt the traffic, because even if they have the symmetric key they don’t have the private key needed to decode the information. FortiGate II Student Guide 345 DO NOT REPRINT © FORTINET Certificate Operations The final part of setting up encryption between parties is to negotiate exactly which protocol and cypher are going to be used in the communications. Both sides advertise what options they support. After that, the 2 sides propose combinations until an agreement is reached regarding how the encryption will actually work (which protocols will be used). If a setting can not be agreed upon then just like a rejected certificate the entire connection fails. Once both sides agree on what encryption to use, the data that is being sent gets put through those algorithms and encrypted using the symmetric key and public key from the other side, before it gets sent over the connection. FortiGate II Student Guide 346 DO NOT REPRINT © FORTINET Certificate Operations In a SSL session, asymmetric cryptography is used to generate and share a symmetric key. After that, symmetric cryptography is used to encrypt the user and server data. The symmetric key is valid only for the length of the session. If you close the current session, that symmetric key is no longer valid and cannot be used again. When a new SSL session is created, a new symmetric key will be created between the browser and the server. FortiGate II Student Guide 347 DO NOT REPRINT © FORTINET Certificate Operations The most common way of getting a digital certificate for a FortiGate or server is by generating the private and the public key first. Usually, those two keys are generated internally by the device where the certificate is going to be installed. After that, the public key is given to a public Certificate Authority, such as GoDaddy, or Verisign usually in the form of a *.CSR file. CSR stands for Certificate Signing Request. The CA verifies first that the information submitted is valid. After that the CA generates and signs a digital certificate, which contains the public key sent by the user. The CA will also encrypt the certificate and its signature using its private key. FortiGate II Student Guide 348 DO NOT REPRINT © FORTINET Certificate Operations The FortiGate generates the private and public keys. The public key is stored in a file with the standard format PKCS#10. The file contains what is called a Certificate Signing Request (CSR). The CSR also contains information about the network device as entered by the Administrator, such as IP address (or FQDN), and company name. Once the details are completed this can be downloaded and sent to a CA for signing. After the CSR is submitted, and while waiting for the signed certificate, FortiGate will show the certificate as “Pending”. FortiGate II Student Guide 349 DO NOT REPRINT © FORTINET Certificate Operations Certificate Signing Requests can be created on the FortiGate by going to System > Certificate > Local. When and admin clicks on generate, the CSR form must be filled out in order to set the details and fields that will be included in the certificate. After the CSR has been created, the status of the certificate will be Pending. While the status is Pending the certificate can not be enabled or used. The administrator can now download the PKCS#10 file and submit it to the CA. FortiGate II Student Guide 350 DO NOT REPRINT © FORTINET Certificate Operations When the administrator receives the signed certificate back from the CA, it must import it to FortiGate. After that the status of the certificate will change from “Pending” to “OK”, meaning it can be used. Adding a certificate that the FortiGate will use in SSL communications can be done without generating and signing a CSR. In that case, all 3 parts of the certificate must be loaded: The signed certificate, the public Key and the private Key/password. PKSC#12 is a file format that combines the Certificate and the Public key into a single file. Since the certificate will be used as part of encrypted communications the private portion is still required. FortiGate II Student Guide 351 DO NOT REPRINT © FORTINET Certificate Operations If you wish to have the FortiGate unit preventing certain certificates from being used, then you will need to maintain a Certificate Revocation List (CRL). A CRL contains the serial numbers of all the digital certificates that cannot be trusted anymore. For example, digital certificates of ex-employees that left the company can be added to the list. When FortiGate is validating a certificate, it will check that its serial number is not listed in a CRL. CRLs must be kept up-to-date manually by the administrator. FortiGate II Student Guide 352 DO NOT REPRINT © FORTINET Certificate Operations CRLs can be created and managed under System > Certificates > CRL in the FortiGate GUI. FortiGate II Student Guide 353 DO NOT REPRINT © FORTINET Certificate Operations Digital certificates stored in a FortiGate device can be separately backed up to a PKCS#12 file. The file will include the keys (private and public) and the certificate itself. The backup and restore can be done only from the CLI and requires the use of a TFTP server. Once this information is backed up, it can be restored back to the same FortiGate device. We can also restore it to any other FortiGate, regardless of the model, or firmware version. A backup of the FortiGate configuration also includes the keys and certificates. However, in the case of the configuration backup, the restore can only be done to a FortiGate unit of the same model and running the same firmware version. FortiGate II Student Guide 354 DO NOT REPRINT © FORTINET Certificate Operations Some FortiGate devices offer a mechanism to inspect and apply protection profiles over SSL encrypted traffic. It is called SSL Content Inspection. Under normal circumstances (without SSL Content Inspection), encrypted traffic cannot be inspected, as the firewall does not have the key that is required to decrypt the data. In order to work, the FortiGate must be located in the middle of the communication between the user’s browser and the web site example.com. When the browse connects to the site, the web server sends its certificate, which contains its public key. Its certificate has been issued to example.com by a CA. The FortiGate intercepts the web server certificate and generates a new one on the fly. The new certificate is also issued to example.com, but this time it is issued by the CA installed on the FortiGate, which may not be a public CA. The FortiGate also generates on the fly a new pair of public and private keys. The new certificate contains the public key generated by the FortiGate. So, now the FortiGate unit will use the FortiGate public key, not the web server’s public key, to start the encryption to the user’s browser. On the other side, it will use the web server’s public key to start the encryption and establish the conversation with the server. FortiGate II Student Guide 355 DO NOT REPRINT © FORTINET Certificate Operations SSL Inspection requires a SSL Proxy certificate that allows the unit to generate a new pair of keys, and a new certificate. The unit must do it on the fly and each time the user is connecting to a different site. In other words, the FortiGate must act as a sub-CA. So, the certificate that is required for SSL Inspection is not a usual one, but one that has either the ‘CA’ field equal to ‘True’, or the ‘Key Usage’ includes ‘KeyCertSign’. The FortiGate models that support SSL Inspection come from factory with one SSL Proxy certificate that can be used to SSL Inspection. It is called ‘Fortinet_CA_SSLProxy’ and is signed by a CA called “FortiGate CA”, which is not public FortiGate II Student Guide 356 DO NOT REPRINT © FORTINET Certificate Operations When doing SSL Inspection, your browser will start displaying a certificate warning each time a user is connecting to a HTTPS site. The reason for this warning is that the certificates received by the browser are now being signed by the FortiGate, which is a CA that the browsers do not know and trust. There are three ways for avoiding this warning: The first option is to download the certificate used on the SSL Proxy and install it in all the workstations as a public authority. Another option is to generate a new SSL Proxy certificate from a private CA. In that case this certificate will need to be installed into the FortiGate and configure the unit to use it for SSL Inspection. This private CA may still need to be and installed in all the workstations. Finally you may be able to purchase a suitable certificate from a public CA. This is not a limitation in FortiGates, but a consequence of how digital certificates were designed to work. The only way for any vendor device, to inspect encrypted traffic is to intercept the certificate coming from the server and generate a new one. In other words, the unit must do a man-in-the-middle attack or have the private keys already installed. FortiGate II Student Guide 357 DO NOT REPRINT © FORTINET Certificate Operations Replacing the certificate on the traffic can cause problems. Some software or servers have specific limitations on the certificates that are allowed to be used. HSTS is a security feature of the google browser Chrome. It is designed to detect Man-in-the-middle SSL attacks by making sure that any certificate presented when accessing a google resource is signed by a specific CA. If it detects any other CA it will simply refuse to continue the SSL handshake and prevent access to the website. The options available for this are limited. The only option that will allow content of the traffic to be inspected is to replace the certificate on the SSL Proxy with one that will satisfy the security settings. Another option is to disable the settings causing this. HSTS can be turned off in chrome, but this is not an option in all environments. The last option is to bypass SSL inspection of that traffic. Other servers or software can have their own requirements on the certificates that get used for SSL. FortiGate II Student Guide 358 DO NOT REPRINT © FORTINET Certificate Operations Whenever a Private CA is used for the SSL Proxy it’s important to remember to install that into your software as a Certificate Authority (CA). Failure to do this will result in warning messages in web browsers anytime there is access to any HTTPS website. It may also result in encrypted communications failing, simply because the CA on the certificates is untrusted. Once the certificate is downloaded off the FortiGate it can easily be installed into any web browser or software. Not all software uses the same certificate repository. For example, Firefox and Internet explorer are both web browsers but they use different certificate repositories. In order to avoid certificate warnings in both browsers the SSL Proxy certificate needs to be installed as a root authority in both browsers. When the certificate is being installed it’s important to make sure that it is properly setup as a root authority. Normally setting a certificate up as an authority requires a few manual selections to be made in order to properly classify the certificate. Exactly how it is done and what needs to be done manually will vary from one software to another. FortiGate II Student Guide 359 DO NOT REPRINT © FORTINET Certificate Operations Once an appropriate SSL Inspection certificate is installed on the FortiGate, enabling SSL inspection is quite simple. First, an SSL inspection profile needs to be created and configured. Here, we can specify which SSL Proxy Certificate is going to be used for SSL Inspection. The dropdown list will only show only the certificates that are valid for use with SSL Inspection. Once the certificate is selected, the secure protocols that will be inspected can also be selected. There is no option in any UTM profile to apply separate rules for secure traffic. The encrypted version of the protocol will be inspected with the same rules as the non-encrypted one. For example. HTTPS traffic will be inspected with the same options that have been enabled for HTTP. The inspection method selected will impact all of the enabled UTM profiles. If this is set to SSL Certificate Inspection then none of the SSL content can be scanned. This will prevent some feature from functioning altogether (Virus scanning, some DLP options..) and impact the accuracy of the rest. FortiGate II Student Guide 360 DO NOT REPRINT © FORTINET Certificate Operations Within the SSL inspection profile there is a section that allows for exemption of traffic some SSL inspection. There are a number of reasons why this may be necessary. The first reason would be that the act of SSL Inspection causes a problem with the traffic. HSTS with chrome, for example. Unless an appropriate certificate is used chrome will drop the connection. If access to google with chrome is a requirement and an appropriate certificate cannot be used, the only option is not to do SSL inspection of that traffic. Googles network is vast so setting up an exemption with a firewall policy may not be a feasible workaround, so the option is built into the SSL Inspection profile. Another reason that it may be necessary to bypass SSL inspection on some of the traffic would be for legal reasons. In the some countries it is illegal to do SSL inspection of banking related traffic for example. Again, setting up Firewall policies for each individual bank could be tedious, so configuring an exemption for specific categories (like Finance and Banking) would be simpler. Become familiar with whatever local laws may apply to encrypted internet traffic in your jurisdiction. FortiGate II Student Guide 361 DO NOT REPRINT © FORTINET Certificate Operations After an SSH Inspection profile has been created and configured, it must be applied to a Firewall policy in order to start inspecting traffic. The purpose of the SSH Inspection profile is to define exactly how encrypted traffic is handled. From the GUI, enabling any kind of UTM profile also requires an SSH Inspection profile to be enabled. This does not mean that traffic must be subjected to SSL Inspection and subject to Man-in-the-middle decryption by the FortiGate. It simply means that how encrypted traffic will be handled, needs to be defined when you enable UTM. From the CLI however, an SSL Inspection profile is not required because this is a more advanced method of configuration. UTM inspection without an SSL Inspection profile will result in encrypted protocols being ignored through that firewall policy. FortiGate II Student Guide 362 DO NOT REPRINT © FORTINET Certificate Operations A FortiGate device can be configure to user certificate-based user authentication for admin users. Users with a digital certificates are called PKI users. After the first user has been created from the CLI, you can now add that PKI user to a group. Once a PKI user has been added to group, that group can now be selected as part of the PKI user configuration for administrative users. The CA needs to be loaded onto the FortiGate in order to verify and compare the Certificate that gets presented. Assuming this CA is secure and kept private this will allow administrative users to connect without needing to login. The user information is linked to the certificate that gets presented for the SSL communications when attempting to access the administrative interface. FortiGate II Student Guide 363 DO NOT REPRINT © FORTINET Certificate Operations Under certain circumstances it is possible for the FortiGate to do inline SSL decoding, rather then normal man-in-the-middle inspection. Inline decoding it performed by the IPSEngine, rather then the SSL proxy. The IPSEngine is not a proxy so doing this does not break communication on layer 3, the way a proxy does. In order to accomplish this, the key negotiation is modified so that the traffic can be decrypted as needed. FortiGate II Student Guide 364 DO NOT REPRINT © FORTINET Certificate Operations Not all SSL connections can be decoded inline. It is only possible when certain technologies are being used. The IPSEngine looks at the SSL handshake as it is happening. If it detects, Client Channel, NPN, ALPN, or SPDY, then inline inspection is used automatically. If they are not detected then the SSL traffic is handed over to the SSL proxy for man-in-the-middle negotiations. FortiGate II Student Guide 365 DO NOT REPRINT © FORTINET Certificate Operations https://technotes.googlecode.com/git/nextprotoneg.html NPN is a feature of Google Chrome designed to control application layer protocol negotiation. The purpose is to help choose the protocol to use for encryption in order to help optimize secure communications. This is an older feature that is being phased out. As of Chrome versions 20 and later, it is disabled by default. NPN is not a encryption protocol. It is a method of performing the encryption handshake. FortiGate II Student Guide 366 DO NOT REPRINT © FORTINET Certificate Operations http://www.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation ALPN is the same idea as NPN. It helps to optimize and speed up SSL negotiations. While it has the same purpose the design is very different. In NPN the server makes the initial declaration of protocols, which the gets confirmed by the client. In ALPN this is reversed and the client makes the initial declaration. All the protocols that get listed in the exchange are forced to use the IANA standard numbering. ALPN (like NPN) is not an encryption protocol. It is a method for doing the encryption handshake and decides what kind of encryption to use. FortiGate II Student Guide 367 DO NOT REPRINT © FORTINET Certificate Operations Another aspect of ALPN is that it allows for streaming. Normal SSL communications only allows for 1 piece of data to be transmitted through a session encrypted with SSL. ALPN allows for multiple data streams within a single TCP session, bypassing the need to initiate new encrypted sessions for each piece of data. FortiGate II Student Guide 368 DO NOT REPRINT © FORTINET Certificate Operations A high level comparison of NPN and ALPN shows the differences in how those 2 technologies alter the SSL handshake. In the case of NPN the initial Hello includes the declaration that the client supports the NP Extension. When a server also supports this, it hello’s back that it also supports this along with the options for encryption. The client completes the handshake and advertises which protocol will be used to used for the session. Looking at ALPN the difference is that the protocol options for the session come from the client along with the initial handshake. The server selects the encryption protocol and sends that information with it’s Hello and the client finishes the SSL handshake as normal. The end result is that ALPN results in less overall packet overhead compared to NPN. In both cases, if the server does not support the extension it returns a normal Hello and SSL communications continue normally. FortiGate II Student Guide 369 DO NOT REPRINT © FORTINET Certificate Operations http://www.wikipedia.org/wiki/SPDY SPDY is a protocol supported by all versions of Chrome as well as newer versions of other browsers. Like NPN or ALPN it is also a protocol designed to optimize SSL. It’s in use on some of the larger web service provides on the internet currently. SPDY is an actual encryption protocol, unlike ALPN or NPN which are an extension of SSL. Rather then simply focusing on being secure like other methods of encryption, it also has considerations for allowing users to download content faster. Traffic is not simply encrypted, it is subjected to several different methods to reduce the amount of data that flows over the wire. Common parts of the data are turned into tokens to reduce their size and other parts are compressed using GZIP or DEFLATE. This reduces the amount of data that is being sent in order to help improve load times. FortiGate II Student Guide 370 DO NOT REPRINT © FORTINET Certificate Operations Here is a review of the topics that were discussed: • Methodologies for securing network traffic • How symmetric cryptography works • How asymmetric cryptography works • Digital certificates • Certificate-based user authentication • Mechanics of the SSL handshake • Generating and signing certificates • Importing certificates • Managing CRLs • Mechanics of content inspection • Certificate warnings • Installing the certificate from the FortiGate as a root authority • Configuring and enabling SSL content inspection FortiGate II Student Guide 371 DO NOT REPRINT © FORTINET Data Leak Protection In this lesson, we will show you how to prevent crucial private data, such as bank account routing numbers and credit card numbers, from leaving your network, and from being inappropriately transmitted. Data leak prevention is required by some compliance regimes, such as PCI DSS and HIPAA, but other networks may also find it useful to help prevent, for example, student cheating. FortiGate II Student Guide 372 DO NOT REPRINT © FORTINET Data Leak Protection After this lesson, you should have these practical skills, such as knowing when to use DLP, and knowing how to monitor specific data types, and how to configure DLP filters and sensors. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 373 DO NOT REPRINT © FORTINET Data Leak Protection FortiGate has other features, such as IPS and antivirus, that can detect and block files. What makes DLP different? Why should you use it? Traditional firewalls and first-generation UTMs were designed to prevent attacks and nuisances from getting into your network. Web filtering is only applied to traffic coming in. Likewise, despite best practice to apply it in both directions, many people apply antivirus and email filtering only to traffic coming in. But DLP is to prevent specific data from getting out. How can traffic that is leaving your network affect security? Often it’s normal for co-workers to share sensitive documents inside your network. Sensitive information is also normal between servers that work together to host a single application. But if sensitive data such as financial information becomes public, it can have serious effects. Stock prices, bank transactions, privacy, and password security can all be compromised. So DLP helps to ensure that your network follows the rules required by your real-world organization, and doesn’t give out important information. FortiGate II Student Guide 374 DO NOT REPRINT © FORTINET Data Leak Protection So how does DLP work? FortiGate scans traffic matching your firewall policy for the DLP patterns that you specify. When you configure a pattern, whether pre-defined or custom, DLP doesn’t directly inspect traffic itself. Instead, it communicates the pattern to the proxy’s or IPS engine’s processes, which actually do the scanning. So remember that when troubleshooting, you may need to investigate flow through modules that you didn’t manually enable. If the scan finds a match, it executes the filter’s corresponding action. So, in the example here, the first 2 filters didn’t match the file, but the 3rd one did, so FortiGate performed its action. FortiGate II Student Guide 375 DO NOT REPRINT © FORTINET Data Leak Protection Now that we’ve seen the basic idea, let’s start from the beginning – show how to add filters in a DLP sensor. Initially, we’ll use some default file filters and message patterns. Later, we’ll show how to customize and expand them. Most DLP behavior is dependent on the filter type. So we’ll show that in depth. But first, let’s briefly see the service inspection and action. First, change the GUI menu settings to show DLP. (By default, it’s hidden. To show it, go to System > Config > Features.) Then, go to the DLP submenu that is now available: Security Profiles > Data Leak Prevention > Sensor. Create a DLP sensor. Inside it, add a filter. In each filter, we’ll specify: • match criteria • which protocols to scan • actions that FortiGate will apply when traffic matches In the “Examine the following Services” area, choose which network protocols should be scanned. Like with other security features, secure protocols aren’t in the list of scannable network services. However, if you enabled “SSL/SSH Inspection”, FortiGate will scan both each protocol that you choose and its secure equivalent. For example, if you mark the check box for HTTP, FortiGate will also scan HTTPS. More information is in the lesson on certificates. FortiGate II Student Guide 376 DO NOT REPRINT © FORTINET Data Leak Protection To scan secure protocols, select an SSL/SSH inspection profile in the traffic’s matching firewall policy. With DLP, you usually need a profile that does full inspection. There are two levels of inspection: • Certificate-only • Full content inspection Certificate inspection only verifies the certificate and any unencrypted headers that are sent before encryption begins. Because FortiGate doesn’t interrupt the handshake, for certificate inspection, DLP can’t scan contents. So this mostly effectively bypasses DLP. When would it be effective? Only if you need to act on the certificate or URL of a web site, for example. The client sends this before the encryption handshake occurs. What if we want to scan inside the payload of the packet? In full inspection, FortiGate terminates the SSL/TLS handshake at its own interface, before it reaches the server. When certificates and private keys are exchanged, it is with FortiGate, and not the server. Next, FortiGate starts a second connection with the server. Because traffic is unencrypted while passing between its interfaces, FortiGate can inspect the contents and look for matches with DLP sensors, before it re-encrypts the packet and forwards it. FortiGate II Student Guide 377 DO NOT REPRINT © FORTINET Data Leak Protection For each filter in the DLP sensor, you must indicate the “Action” – what FortiGate should do if traffic matches. The default setting is “Log Only.” If you’re not sure which action to choose, this can be useful initially. While you study your network, use this action to see what sensitive information is being transmitted, then later fine-tune your sensor and select the most appropriate action to block sensitive files from the WAN. FortiGate II Student Guide 378 DO NOT REPRINT © FORTINET Data Leak Protection Now let’s return to the top of the filter, which is the more complex part of the configuration. Choose the type: either “Message” or “Files.” Most other available options depend on this initial choice. “Messages” scans for words, credit card numbers, or other text-based patterns directly embedded in the protocol, not as a file. There are two preconfigured “Messages” filters available: Credit Card and SSN. If the pre-defined DLP patterns don’t match exactly what you’re looking for, to configure your own custom pattern, you can use the “Regular Expression” option. Use PCRE syntax. Supported expressions and performance with complex Turing complete expressions always vary by the regular expression engine, so if you’re looking for references, look specifically for PCRE, not others such as the similarly-named Perl language. “File” changes the available options to be appropriate for files, such as file size, fingerprinting, and watermarking. FortiGate II Student Guide 379 DO NOT REPRINT © FORTINET Data Leak Protection In this example, we are blocking credit card numbers from leaving the network using preconfigured “Message” filter. “Block” action also generates log, which can be viewed under Log & Report >Traffic Log > Forward Traffic. “Log Details” provides important information that security event matches DLP and it is blocked. “DLP” provides additional information such as Filter Type, Filter Category, DLP Profile Name. FortiGate II Student Guide 380 DO NOT REPRINT © FORTINET Data Leak Protection If you choose a “File” type for the filter, and select “Specify File Type” option; “File Types” and “File Name Patterns” becomes available. “File Types” is based on examination of file contents, regardless of the file name/extension. Even if the file is renamed with different extension, DLP will still detect it. It has a corresponding drop-down menu where you’ll select which file types to scan for. “File Name Patterns” is based on examining and filtering purely on the names of files and are configured manually. Here is an example file filter table that matches all Microsoft Office files. Notice that, to do this, it contains sub-filters of both types. This is because: • Older versions of Office use a binary file format, identifiable by a binary file type scan. • Office 2010 and newer files are not binary, but a ZIP archive. They are actually XML files inside a ZIP archive. This is documented on the Microsoft website, but the link here is easier to read. It’s crucial to realize that because Office 2010 uses a nested file type, if you use file type filters with them, they will accidentally match any ZIP file, not just Office files. This is a common DLP misconfiguration. So to avoid false positives with these newer versions of Office, the default profile matches by file extension instead. Note, however, that the tradeoff is possible false negatives. FortiGate II Student Guide 381 DO NOT REPRINT © FORTINET Data Leak Protection Let’s explain the file-specific sub-filters. File name patterns are intuitive. If a file name either: • matches literally, or • matches the pattern then FortiGate will perform the action. As a result, if an important file name varies (which is usually the case – users may try to evade DLP by renaming files to a harmless-sounding name), then you should use patterns, not the literal file name. Configure FortiGate to match all intended file names – but no unintended file names. For example, browsers often rename downloads of duplicate file names to prevent accidentally overwriting an existing different yet identically named file. Before the file extension, for example, they would add “(2) “. Likewise, Windows renames copies of file so that they start with “Copy of”. So usually you should use a name pattern such as “nice*.jpg”, not the literal file name, “nicepainting.jpg”. The example here shows which filters would match the file name, and which filters wouldn’t. But what if the file name doesn’t match any pattern? What if the file name is radically different, and therefore a broad pattern would cause false positives? What if we want to block all executables regardless of name or platform, for example? FortiGate II Student Guide 382 DO NOT REPRINT © FORTINET Data Leak Protection File name matching alone is often not enough for very sensitive data. You may want a more sophisticated filter. One addition or alternative is to use file type filtering. File type matching behaves as you’d expect. This is because file types are identified not by the extension such as “.doc” – in that case, users could circumvent DLP by simply renaming the extension. Instead, FortiGate enforces file type scans the binary for matching binary patterns – how that file type stores data in specific areas, in specific patterns of 1’s and 0’s. The tradeoff for this accurate technology, however, is that unless FortiGate has a corresponding decoder that understands the binary data structure, it cannot decipher the string of zeros and ones, and therefore cannot identify the file type. FortiGate II Student Guide 383 DO NOT REPRINT © FORTINET Data Leak Protection To return to our DLP sensor’s filter, when scanning files, types and names aren’t our only option. On most networks, it’s typically not an option to block all Microsoft Office files. And blocking by file name is not effective if users intentionally try to circumvent. What other alternatives do we have? FortiGate can use a content-based filter called “document fingerprinting.” Fingerprinting identifies specific files via one or more CRC checksums, so it’s best used with files such as secure PDFs and photographs – files whose contents do not change, or that don’t change much. But fingerprinting can sometimes be configured for files that occasionally do change entirely, such as expense spreadsheets. We’ll show that next. The file itself is not stored in memory; only the checksums. So you can fingerprint many or on very large files. How accurate is the fingerprint? How many checksums DLP will calculate and store? Smaller chunks mean that more checksums will be calculated per file. So DLP will fingerprint more accurately: it will still be able to identify a file, even if someone changes it in a few places, because the checksums of the other chunks will still match. The tradeoff is that more checksums require more FortiGate memory for storage. So you must decide the best balance between performance and accuracy. FortiGate II Student Guide 384 DO NOT REPRINT © FORTINET Data Leak Protection Now let’s configure fingerprinting. Before you actually make any fingerprints, consider whether you’d like to make custom sensitivity level tags. For example, you could make a custom sensitivity level named “Finance,” then next, while configuring fingerprints, tag all money-related fingerprints. The sensitivity level has two effects: • It will appear in log files. • When you configure each filter in a DLP sensor, you will select which fingerprints the file filter will use by specifying a sensitivity level. All fingerprints having that sensitivity level will be included in that filter. For example, if you configure a filter in your DLP sensor to be a “File” type, the “File Finger Print” option appears. When you select it, its drop-down menu then becomes available. In the drop-down, you choose whether the filter will use “Critical”, “Private”, “Warning”, or your own custom group of fingerprints, according to their sensitivity level tag. FortiGate II Student Guide 385 DO NOT REPRINT © FORTINET Data Leak Protection Once you’ve defined any custom sensitivity levels, you’re ready to define your fingerprints. Go to Security Profiles > Advanced > DLP Fingerprint. Fingerprinting can be done in two ways: In the GUI, click on Create new under Manual Document Fingerprints to upload files to FortiGate so that it can create and store checksums. You can configure FortiGate to connect to a file share by clicking Create new under Document Sources . If you prefer, it can do this periodically. Each time, FortiGate can automatically recreate checksums for all files in the share, or retain old fingerprints (in case an old version of the file is still circulating). Fingerprinting via file share is useful if you must add many files, or if your files change periodically or extensively. That way, you don’t need to manually update the fingerprint each time the file changes significantly. While configuring either method, choose which sensitivity level FortiGate will use to tag those fingerprints. After fingerprints are defined, go to a DLP sensor’s filter where the type is “File” and “File Finger Print” is chosen, and select a file sensitivity level. FortiGate II Student Guide 386 DO NOT REPRINT © FORTINET Data Leak Protection In this working example, there are two manual fingerprints setup on the FortiGate. DLP will scan and inspect these rules (filters) for fingerprint matching from top to bottom. The first manual fingerprint doesn’t match with the original files, DLP will then move on to scan and inspect the next filter. As DLP stores the file checksum in chunks, it detected that second manual fingerprint file has changed from the original file and take action as defined in the DLP sensor. FortiGate II Student Guide 387 DO NOT REPRINT © FORTINET Data Leak Protection So now we’ve configured a few filters in the DLP sensor. Continue with more filters until the sensor matches all traffic that it should, but doesn’t match unintentionally. Finally, apply the DLP sensor by selecting it in a firewall policy. Here is an example DLP sensor with a few filters. Each filter searches traffic for different types of sensitive information, such as a credit card number or fingerprint. If traffic matches a filter, FortiGate will apply that filter’s action. Remember, DLP filters are evaluated for a match sequentially, from top to bottom, and FortiGate uses the first matching filter. So, for example, let’s say an email contains a credit card number (which filter 1 says to block), but also has sensitive text (which filter 5 says to log but allow). FortiGate will only use the first filter: the email will be blocked, not allowed. FortiGate II Student Guide 388 DO NOT REPRINT © FORTINET Data Leak Protection Up until now, we’ve shown DLP blocking or monitoring sensitive data. What else can DLP do? It can record traffic “summaries” – that is, logs – and, if enabled, the full files and messages that were contained in the traffic. If you were familiar with “content archiving” on older versions of FortiOS, you will recognize summary archives and full archives here. Summary archiving records a log message that summarizes the traffic, and therefore will vary by protocol. For example, with an email message, the summary archive would contain the sender’s email address, the recipient’s email address, and the size. When users access the Web, FortiGate logs would record every URL they visited. FortiGate II Student Guide 389 DO NOT REPRINT © FORTINET Data Leak Protection Full archiving records the summary log, but also a complete copy of the traffic’s contents. This can be useful in forensic investigations. It’s not meant for prolonged use, however. Depending on what you’re archiving, full archiving can require large amounts of FortiGate’s disk, CPU, and RAM resources, decreasing performance. For example, if you fully DLP archive a 100 MB file, FortiGate will actually store more than just 100 MB. It stores the data plus Ethernet, IP, and other headers that were used during network transmission, plus the log message. So it will require slightly more than 100 MB. But also, this requires RAM and CPU until the FortiGate finishes writing the file to its hard disk. Full DLP archiving also consumes limited disk space that FortiGate may need for other UTM features. So for performance reasons, it’s better to use a FortiAnalyzer or external storage device. If you need to inspect and archive email – especially for prolonged times – then FortiMail may be a better alternative. It has local archiving, plus many antispam, secure messaging, and other in-depth features that FortiGate’s SMTP proxy cannot support. FortiGate II Student Guide 390 DO NOT REPRINT © FORTINET Data Leak Protection To review, here’s the topics we covered in this lesson. We discussed: • When to use DLP • Differences between detecting sensitive data via protocol filters and files • How DLP fingerprinting works, and how to choose the best method for the number of files and how frequently they change • Logs and traffic contents that DLP can record FortiGate II Student Guide 391 DO NOT REPRINT © FORTINET Diagnostics In this lesson, we will teach you how to locate the source of problems in your network. We’ll also show you fundamental troubleshooting commands on FortiGate that you can use to pinpoint and resolve issues – everything from high CPU usage to “network unreachable” errors. FortiGate II Student Guide 392 DO NOT REPRINT © FORTINET Diagnostics After completing this lesson, you should have these practical skills that you can use. You’ll know to how to determine your network baseline, read diagnostic output, troubleshoot the physical and network layers, trace packet flow through FortiGate processing, and find the root causes of abnormally high CPU or memory usage. Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 393 DO NOT REPRINT © FORTINET Diagnostics In order to define any problem, first you must know what is your network’s normal behavior. In the graph here, the range that indicates “normal” is in blue. What is the blue line? It’s in blue, and indicates the average – our “baseline.” What is the thick black line? It’s the behavior right now. When it leaves the normal range, FortiGate generates an alert, indicated by the red “X”. “Normal” is measured and defined in many ways. It’s performance: the expected CPU and memory utilization, bandwidth and traffic volumes. But it is also your network topology: which devices are normally connected at each node, and which direction traffic should flow. It’s behavior: which protocols are blocked or proxied, and the distribution of protocols and applications used during specific times of the day, week, or year. FortiGate II Student Guide 394 DO NOT REPRINT © FORTINET Diagnostics Let’s look at each of these measurements – how you can determine if the network has a problem. If you are starting a new network, many things may not work yet. Many problems are obvious, and normal behavior is, too. But in large or established networks, the difference between “normal” and “broken” may be subtle. How can you find what to fix or improve? FortiGate II Student Guide 395 DO NOT REPRINT © FORTINET Diagnostics What is the first way to define what is “normal” for your network? Topology. Flows and other specifications about what is “normal” are derived from this. So during troubleshooting, a network diagram is essential. If you create a ticket with Fortinet Technical Support, it should be the first thing you attach. Network diagrams sometimes combine the two types: • physical • logical A physical diagram shows how cables, ports, and devices are connected between buildings and cabinets. A logical diagram shows relationships (usually at OSI logical Layer 3) between virtual LANs, IP subnets, and routers. Sometimes it also shows application protocols such as HTTP or DHCP. Let’s say that a guest is unable to use the Wi-Fi network. The client attempts to connect with a static IP of 10.0.0.5, a /24 netmask, and a gateway of 10.0.0.1. Is this normal? It’s difficult to guess. But if you have a network scheme where Wi-Fi uses DHCP to assign clients an address in the 192.168.1.0/24 subnet, and all of the subnet’s IP leases are currently taken, then the problems become obvious. FortiGate II Student Guide 396 DO NOT REPRINT © FORTINET Diagnostics Another way to define “normal” is to know the average performance range. On an ongoing basis, collect data that shows normal usage. For example, if email processing is suddenly slow, and your FortiGate’s CPU usage is 75%, what does that indicate? If weekday CPU utilization is usually 60-69%, then 75% is probably still normal. But if normal is 12-15%, there may be a problem. Get data on both typical maximum and minimum for the time and date: on a workday or holiday, for each network application, how many bits per second should ingress or egress from each interface in your network diagrams? Does the marketing department usually send an email campaign each Tuesday? This Tuesday, let’s say it contains a video. So many inbound requests for video from the media servers are probably not an attack – it’s probably normal. However, “normal” doesn’t mean it’s irrelevant. Should you expand your network’s capacity? Lease another line from your ISP? Should you add another HA FortiGate to your active-active cluster? Should you configure link aggregation, or QoS? FortiGate II Student Guide 397 DO NOT REPRINT © FORTINET Diagnostics Every 5 minutes, FortiGate generates a performance statistics log. But in large deployments with hundreds of FortiGates, it’s not practical to search event logs to calculate every normal range. SNMP or SIEMs are more scalable. If you’re getting network usage data via SNMP or syslog, remember that they’re transported via UDP. So dropped packets mean missed data. But it’s very light weight. And the newer SNMP version 3 is also more secure. To use SNMP, download the MIB files to an SNMP manager such as Cacti. MIBs define which queries and messages (called “traps”) that FortiGate supports. Configure FortiGate to accept queries from the manager’s IP address. If you select authentication and/or encryption, be sure to match the security settings, too. Collect data for at least a week to find your normal – normal usage can be different during the weekdays vs. the weekends vs. holidays. This may vary by region and business type. What is “normal” for one interface, or one FortiGate, may not be normal for another. Many places celebrate New Year’s, but it’s often not big for online shopping; meanwhile, many branch offices will be closed, for example. FortiGate II Student Guide 398 DO NOT REPRINT © FORTINET Diagnostics Once you have specifications and some data – for example, a month’s worth of system event logs, traffic logs, and SNMP queries – then you know how your network should behave. How do you determine if there’s a problem? Compare that normal behavior with now. FortiGate II Student Guide 399 DO NOT REPRINT © FORTINET Diagnostics Once your SNMP manager is receiving data about normal usage, what is next? Obviously you don’t want to stare at a screen, every hour of every day, watching your FortiGate for abnormal behavior. You want each FortiGate to notify you when abnormal events occur – for FortiGate to be proactive. FortiGate can do this in multiple ways: • Alert email or text messages, via servers defined in System > Config > Advanced • FortiAnalyzer or Syslog, via servers defined in Log & Report > Log Config • SNMP traps, via servers defined in System > Config > SNMP or ‘config sys snmp sysinfo’ How are abnormal events defined? It varies by notification method. For SNMP, they are defined on an individual basis for each SNMP manager. For alert email, they are defined globally, Logs are in the Log & Report > Log Config menus. For FortiAnalyzer or syslog servers, you define alert-worthy events for your whole network externally, on the FortiAnalyzer or syslog server, not on each FortiGate. FortiGate II Student Guide 400 DO NOT REPRINT © FORTINET Diagnostics How else can we get current statuses? Let’s show CLI commands first: you can use them via local console, even if network issues make GUI access slow or impossible. A few commands provide system statuses. ‘get system status’ provides most general purpose information. Output shows: • Model • Serial number • Boot loader version (called the “BIOS” in the output) • Firmware version (including, for virtual machines, the amount of virtual CPUs and RAM allowed and allocated – remember, normal RAM and CPU usage may vary by firmware enhancements and new features) • Host name • HA status • FortiGuard license status, system time, and versions of the FortiGuard Antivirus, IPS, and IP Reputation databases • VDOM status, number, and operation mode and others. ‘get system performance status’ provides resource usage. Together, these provide most of the same information that you can get from the GUI’s dashboard. FortiGate II Student Guide 401 DO NOT REPRINT © FORTINET Diagnostics What about network usage? ‘diagnose firewall statistic show’ categorizes packets and bandwidth by application type. If you don’t know if BitTorrents are impacting your VoIP phones, for example, this is a good places to start. ‘diagnose hardware deviceinfo nic’ varies by that interface’s NIC. Here, we see output from FortiGate VM. It shows that interface’s: • Link speed and statistics for transmitted (Tx) and received (Rx) bandwidth • Physical MAC address • Errors and collisions This command shows how much of your total bandwidth capacity is currently used on that interface. So it’s useful for planning network expansion. But it can also be used to diagnose problems. If some cables might be bad or interference may be corrupting frames, or if a hub needs to be replaced with a switch, this command can help to determine the problem. It can also help you to troubleshoot performance problems where you don’t know what version of NP4 or other ASIC the interface has, or Layer 2 loops or forwarding failures if FortiGate is operating in transparent mode. FortiGate II Student Guide 402 DO NOT REPRINT © FORTINET Diagnostics In the GUI, bandwidth, CPU load, available RAM, and bandwidth usage is displayed on the dashboard – System > Dashboard > Status. You can also view logs – if you’ve configured FortiGate to store them locally – in Log & Report > Event Log and Traffic Log. FortiGate II Student Guide 403 DO NOT REPRINT © FORTINET Diagnostics If you find that something is not normal, what should you do? It depends on the type of the problem. FortiGate II Student Guide 404 DO NOT REPRINT © FORTINET Diagnostics At the physical layer, troubleshooting analyzes which ports are plugged in, media capacity, and electromagnetic interference resulting in transmission errors. At the data link layer, diagnostics often analyze how many frames are being dropped due to CRC errors or collisions. If your FortiGate is operating in transparent mode, and you need to troubleshoot Layer 2 loops, you might also need to show bridges using ‘diagnose netlink brctl list’. If an interface is wired to a Fortinet ASIC chip that accelerates processing such as IP session handling and encryption or decryption, output can look slightly different. This shows output for an NP6 2nd revision interface from a FortiGate 3700D that is running FortiOS 5.0.9. Like the output from a CPUprocessed interface, it shows the physical MAC address, administrative status, link status, and bandwidth usage. But it shows more. Do you see the platform and chip version? Do you see also that bandwidth statistics separates your network traffic from traffic with the FortiGate itself – that is, FortiGuard updates and administrative sessions? You can accurately measure your network’s firewall throughput. Network throughput data shouldn’t include your FortiGuard, FortiManager, FortiAnalyzer, SNMP, GUI or SSH sessions. FortiGate II Student Guide 405 DO NOT REPRINT © FORTINET Diagnostics Let’s say that FortiGate can contact some hosts through port1, but not others. Is the problem in the physical or link layer? No. Connectivity has been proven with at least part of the network. Instead, you should check the network layer. To test this, like usual, we start with ping and traceroute. The same commands exist for IPv6 too: “exec ping” becomes “exec ping6”, for example. Remember: location matters. Tests will be accurate only if you use the exact same path as traffic that you are troubleshooting. To test from FortiGate (to a FortiAnalyzer or FortiGuard, for example), use FortiGate’s own ‘execute ping’ and ‘execute traceroute’ CLI commands. But to test the path through FortiGate, use ‘ping’ and ‘tracert’ or ‘traceroute’ on the endpoint – from the Windows, Linux, or Mac OS X computer, not from the FortiGate’s CLI. Due to NAT and routing, you may need to specify a different ping source IP address – the default is the IP of the physical interface, but you might want to use a VIP or FortiGuard push address, for example. If there is no response, verify that the target is configured to respond to ICMP echo requests. Also notice the first option, “data-size,” and the “tos” option. If you need to test quality of service (QoS), or whether IPS is successfully configured to block oversize “ping of death” attacks, “exec ping” can do that, too. FortiGate II Student Guide 406 DO NOT REPRINT © FORTINET Diagnostics Does a route exists between the source and destination, but there are intermittent interruptions, or some applications fail? Then the problem may be with the session table, with port address translation (that is, PAT), or with higher-layer protocols. FortiGate’s entire session table could be many millions of entries. Also, usually you want to clear only sessions for affected traffic, not interrupt others. To do this, use filters. These are the steps, in order. What happens if you clear the session table, but there is no filter? All sessions would be interrupted. For protocols with transmission control like TCP, the client and server may be able to recover gracefully. But for stateless protocols such as UDP – and this includes logs such as UDP syslog about attacks – the data could be lost. It is up to the individual application to detect and recover from the interruption. FortiGate II Student Guide 407 DO NOT REPRINT © FORTINET Diagnostics In the IP session table, output for each entry will vary slightly by the transport protocol – ICMP, TCP, UDP, and so on – in the encapsulation layer above IP. But in general, it contains: • Protocol number (6 is TCP) • Connection state (since most sessions are TCP connections) • Remaining time-to-live (TTL) until session expiry • Destination port number (TCP socket) • Traffic shaping (QoS), if any • Packet counter • How NAT or PAT is done (including the NATed IP address) • Counts if the session was offloaded to an NP ASIC processor for hardware acceleration • Session handling flags (state=) All of these are important. Let’s look at each in detail. FortiGate II Student Guide 408 DO NOT REPRINT © FORTINET Diagnostics In the ‘proto=‘ field of the session table, there is a number. Each number corresponds to a “service” – that is, the protocol that is used in the next layer of packet encapsulation. Proxies and protocol decoders in packet capture often examine both this and the destination port number. So if a route exists, but the session table shows that the client is trying to use a service that is not allowed by the firewall policy, for example, FortiGate will not allow connectivity. (Even if it is allowed, if a FortiGate explicit proxy is configured, but the client is attempting to establish a session on the wrong port number, connectivity via that protocol will fail. It won’t match the socket.) The most commonly used protocols are ICMP, TCP, UDP and SCTP. Their protocol numbers are shown here. FortiGate II Student Guide 409 DO NOT REPRINT © FORTINET Diagnostics The session table also records the state of TCP connections. There are 2 numbers: the state of the connection between the FortiGate and the client, and the state of the connection from the FortiGate to the sever This is because FortiGate in NAT/route mode terminates the TCP connection, and makes a second connection to the back-end server. Unless FortiGate proxies the session, the first number normally should be 0. We’ll talk more about session expiry later. FortiGate II Student Guide 410 DO NOT REPRINT © FORTINET Diagnostics Although UDP is a message-oriented, stateless protocol – it doesn’t inherently require confirmed bidirectional connections like TCP, so there is no connection state – FortiGate’s session table does use the “proto_state=” field to track UDP conversations. When FortiGate receives the first packet, it creates the entry and sets the state to ‘0’. If the destination replies, FortiGate updates the state flag to ‘1’ for the remainder of the conversation. Notably, ICMP such as ping and traceroute have no protocol state. FortiGate II Student Guide 411 DO NOT REPRINT © FORTINET Diagnostics SCTP sessions also have distinct states, so those are also separate. FortiGate II Student Guide 412 DO NOT REPRINT © FORTINET Diagnostics Aside from information about the IP session itself, the session table includes how FortiGate is handling the session: bridging, IPS, and so forth. In the FortiOS kernel, each session has state flags for handling. The session table’s “state=“ field shows these flags. Here, the example shows 3 flags: this session is being logged (state=log), traffic shaped (shape), and subject to a firewall policy (may_dirty). Session state flags don’t comprehensively track all possible firewall states. But many that it does track are important. Understanding the NPU flag (npu) is critical. If it’s disabled, then the session is: Processed by CPU Not hardware accelerated by specialized FortiASIC chips (so usually performance will decrease) Visible to the kernel (session statistics, packet capture, etc.) But if a session is offloaded, the NP or other chip maintains the session state during almost the whole session. The kernel is only aware of the state at the beginning and end. This is discussed in detail in the hardware acceleration lesson. FortiGate II Student Guide 413 DO NOT REPRINT © FORTINET Diagnostics Now we’ve shown what’s in the session table. We’ve also shown you how to manually remove specific session table entries during troubleshooting, by setting a filter before running the command to clear them. But when will FortiGate automatically remove an entry? FortiGate will automatically remove IP sessions from the table when one of three things happens, either: • Session timeout • TCP connection tear-down • TCP connection timeout Notice that IP sessions are sometimes removed due to events at the higher, TCP layer – not just due to the IP layer session timeout. FortiGate II Student Guide 414 DO NOT REPRINT © FORTINET Diagnostics If the session table appears normal, but a specific protocol fails, you can examine higher layers of the network stack via packet capture. Packet capture can show any packet ingressing or egressing. Basic packet capture is shown in the firewall policy lesson. Let’s show 2 more notable options. By default, the packet capture will run until you press Ctrl + C to stop it, and will use timestamps in seconds and milliseconds relative to the start of the packet capture. This is what happens if you leave the count and timestamp arguments blank, and press the Enter key. To capture only a specific number of packets that match your filter, type a number for the count. To use a timestamp in absolute UTC time (a) or local time (l), type either ‘a’ or ‘l’. These are useful for correlating packet traces with logs, but shouldn’t be used if you want to open the paceket trace in Wireshark, because they will interfere with the packet’s own time stamp. Let’s see those options in some examples. FortiGate II Student Guide 415 DO NOT REPRINT © FORTINET Diagnostics The 1st trace shows does not use the settings for packet count or timestamp; the 2nd does. In the example at the top, the command ran until we manually interrupted it by pressing Ctrl + C, or disconnecting our management session. When interrupted, it had captured 4 packets. But on busy networks, by the time you press Ctrl + C, this might be 4,000 packets… To compare, the example at the bottom stopped automatically after exactly 3 packets because that’s what we indicated via the counter argument. With regard to time stamps, the first command did not specify. By default, time stamps are relative to when the trace started. In the output, an ICMP ping began about 2.1 seconds after the trace. To compare, in the example on the bottom, the command has the option for a local timestamp: the letter “L”. This trace was taken on November 14th, 2014 at 10:28 AM (according to the FortiGate’s clock). To discover corresponding traffic or system events, we would check the logs and SNMP messages with a matching 10:28 AM time stamp. FortiGate II Student Guide 416 DO NOT REPRINT © FORTINET Diagnostics Does packet capture show that normal packets arrive, only for FortiGate to drop them internally? To find which feature is dropping packets, you can follow packets through FortiGate’s internal decision tree – the packet flow. In the firewall policy lesson, we show “diagnose debug flow.” But it‘s useful for more than simply firewall policies. Packet flow also shows routing and UTM scan decisions. To review, here are the steps to record packet flow: 1. Enable packet flow output. 2. Define a filter. 3. Enable recording of the debug log. 4. On your computer, either make sure that the buffer is large enough, or configure your terminal emulator to save output to a text file. (Like packet capture, flow traces generate text quickly – usually scrolling too quickly to read.) 5. Start the trace. 6. Stop when you’ve finished. FortiGate II Student Guide 417 DO NOT REPRINT © FORTINET Diagnostics Not all problems are network connectivity failures. Sometimes, it’s just slowness. What causes latency? Once on the physical media, bits travel relatively quickly – the speed of light or electricity. Latency is usually due to slow processing at each hop. If your monitoring shows that bandwidth usage is normal and links are not saturated, then you should also check: CPU usage RAM usage sometimes disk usage If usage is high, tools can find which feature is consuming the most. However, you can troubleshoot more quickly if you know precisely which change corresponds with when the problem began. So it’s a good idea to gradually enable features. Don’t enable everything at once. If the CPU or RAM usage is too high, and you’ve just enabled all or many features, it will be more complex to determine how to lower the usage. Always begin with both “diagnose sys top 1” and “get system performance status” when investigating very high CPU levels. When the CPU usage is high, “diagnose sys top,” which by default refreshes every 5 seconds, may not be accurate enough. Adding the number 1 at the end causes the display to refresh more often. FortiGate II Student Guide 418 DO NOT REPRINT © FORTINET Diagnostics Let’s begin by showing ”get system performance status”. At the top, output shows that FortiGate that has a multicore CPU: usage is shown for each core, CPU0 to CPU3. This is followed by the RAM usage. At the bottom, output shows your network traffic. If the bit rate (throughput) or number of sessions is higher than normal for your network, sometimes this can also explain slowness, even if the RAM or CPU usage is not very high. FortiGate II Student Guide 419 DO NOT REPRINT © FORTINET Diagnostics Next, let’s examine output for “diagnose sys top”. At the top, total CPU and RAM usage are shown. “User” space is made of inspection like antivirus scans, whereas “system” space is used for operating system activities such as routing traffic and reading or writing files. This is essential to understanding all of the other system usage statistics, and your baseline. Next, FortiGate lists processes that use the most CPU and RAM. Some common processes include: ipsengine, scanunitd and other inspection processes reportd fgfmd for FortiGuard and FortiManager connections Forticron for scheduling management processes (newcli, miglogd, cmdb, sshd, and httpsd) To sort the list by highest CPU, press Shift-P. To sort by highest RAM usage, press Shift-M. FortiGate II Student Guide 420 DO NOT REPRINT © FORTINET Diagnostics Previously, we showed that “diagnose sys top” has a column for process state. This explains the relationship between the states. Most of the time, the process state will be either “R” or “S”. This means the process is doing something (running), or waiting to be told to do something (sleeping). Occasionally you may also see processes in the “D” state while writing to a disk. Obviously, if the process is frequently in the D state, or never leaves it, this could mean there is a problem reading or writing to that device. You should never see a process in a Z state. It’s a zombie process and it means the OS has encountered an error it can’t continue from. Only a reboot can terminate it. FortiGate II Student Guide 421 DO NOT REPRINT © FORTINET Diagnostics Is one of the inspection features, such as IPS, using most of the CPU? You can globally, temporarily bypass that specific feature with the command “diagnose test app”. Set the flag to 5. Then verify the CPU usage again. Has it decreased to acceptable levels? While the CPU has some temporary relief, you can connect to the GUI to quickly disable or adjust those parts of your configuration. For complex configurations, this is usually faster than trying while the CPU usage is high. For example, if “top” indicated that the IPS engine had the biggest CPU workload, you could temporarily toggle off all IPS inspection. This would immediately lower the CPU usage. Then, you would check logs to find unnecessary workload, then adjust those settings before re-enabling IPS. FortiGate II Student Guide 422 DO NOT REPRINT © FORTINET Diagnostics “diagnose sys top” can also be used to look at memory usage, not just CPU. Remember that FortiOS itself uses some RAM, too – not only the scan processes. The first commands show RAM used by spawned processes such as IPSEngine. To show memory used by the operating system itself, use these other commands below. FortiGate II Student Guide 423 DO NOT REPRINT © FORTINET Diagnostics “diagnose sys top-summary” is slightly different from the “diagnose sys top” command. This command is better for examining memory usage. Why? This command collects all memory being used a process and its child processes, including any memory that is shared between the processes, such as antivirus signatures loaded into RAM. FortiGate II Student Guide 424 DO NOT REPRINT © FORTINET Diagnostics Let’s compare output from “diagnose sys top” and “diagnose sys top-summary”. Output is very different. In the “diagnose sys top” output, processes are listed multiple times, but in the “diagnose sys top-summary” output, each is listed only once. The name is marked by an X if the processes has been forked multiple times. Because RAM for all forks is added together into a total, this output is better when you need to determine which feature to adjust in order to make the most impact when correcting performance. What is forking? FortiGate II Student Guide 425 DO NOT REPRINT © FORTINET Diagnostics Forking is when the operating system makes multiple copies of a process in order to either subdivide processing load, or handle multiple similar tasks. If “diagnose sys top” shows scanunitd running 3 times, “diagnose sys top-summary” would show 1 entry with an “x3”, meaning it was forked 3 times. But “diagnose sys top-summary” shows that scanunitd is using 12 MB of RAM, while “diagnose sys top” indicates that scanunitd should be using just under 2 MB. Why do they indicate different RAM usage? The 10 MB anti-virus database isn’t duplicated in RAM for each child process; it is loaded into shared memory, which isn’t counted by “diagnose sys top”. FortiOS doesn’t allow different processes to communicate directly. So if memory wasn’t shared, then FortiOS would be required to load a copy of the antivirus database for each scan process. Each individual process would be using around 11 MB; only 3 concurrent scans would require 33 MB. Performance would decrease. Either that or the entire database would need to be passed through the operating system stack. FortiGate II Student Guide 426 DO NOT REPRINT © FORTINET Diagnostics To see FortiGate’s overall memory usage, including shared memory, use this command. At the top is RAM usage. Below this, usage is analyzed. Different models will obviously have different values, since RAM varies by model. FortiGate II Student Guide 427 DO NOT REPRINT © FORTINET Diagnostics What if you want to see memory allocation for the kernel, not shared memory? Use “diagnose hardware system slab”. Note that this is a very low-level look at the device. For example, there is an entry for inodes, which are essentially pointers for file handles. A large number of inodes indicates that there are an abnormally large number of files open by the operating system. So while this may not directly help you to troubleshoot, it can be useful in rare cases where Fortinet Technical Support needs to provide this information to programmers. FortiGate II Student Guide 428 DO NOT REPRINT © FORTINET Diagnostics If your FortiGate is unstable, your problem may not be with the configuration – it could be corrupted firmware or damaged hardware. How can you diagnose this? Rather than simply installing a new firmware image, you can use the console to temporarily load a new firmware image for testing, before you upgrade. New firmware can contain new features that change the original behavior. If your network depends on a previous default setting, for example, this can require that you adjust the configuration. But until you discover this, will traffic flow be broken? If you upgrade (for example, from FortiOS 4.3 to 5.0) you can use this feature in order to load the new image and try it out before actually saving it to your FortiGate’s disk. This way, if you discover upgrade issues, you can simply reboot, and FortiGate will revert to the previous firmware and configuration while you plan your migration strategy. You can also use this feature to load special HQIP software that can diagnose hardware problems. FortiGate II Student Guide 429 DO NOT REPRINT © FORTINET Diagnostics Damage to RAM during shipping, for example, like with any other electronic device, can cause intermittent crashes. If you suspect hardware failure, download special HQIP hardware testing images from the Fortinet Technical Support web site. There‘s a basic test image, an advanced test (which we recommend for RMA), a hard disk testing image, and flash disk testing image. Run its tests to see if hardware has failed. How do you load the diagnostic image? FortiGate II Student Guide 430 DO NOT REPRINT © FORTINET Diagnostics To load an image, power cycle or reboot your FortiGate. Then, from a local console, enter the boot loader menu. Download the image from a TFTP server. If you choose “Default”, the boot loader will save the firmware image to disk, and load it every time it boots up. If you select “Run”, FortiGate will only temporarily load the image into RAM. It won’t install it to disk. After a reboot or power cycle, RAM will reset, and the temporary image will be forgotten. For a diagnostic image, don’t save it to disk – instead, choose the Run option, then wait. Save the output to a file. If the hardware requires an RMA, Fortinet Technical Support will ask you for the HQIP output in order to authorize the RMA. You can also use this method for testing new firmware images and patches. This way, if you discover issues, you can simply power cycle to return to the previous firmware. If you decide to install the new firmware, but want a “clean install” instead of an upgrade, use the boot loader menu to format the flash disk first. This will reform the partition tables if they have been damaged, before you install a new FortiOS image. FortiGate II Student Guide 431 DO NOT REPRINT © FORTINET Diagnostics Here is a review of what we discussed. We showed: How to determine your network’s baselines How to monitor your network for abnormal behavior your network Commonly used CLI commands for diagnosing network and system problems, such as: • “diag sys session list” • “diag sniffer packet” • “diag sys top-summary” How to test firmware upgrades and hardware FortiGate II Student Guide 432 DO NOT REPRINT © FORTINET Hardware Acceleration In this lesson, we will show how FortiGate ASIC chips and mezzanine cards accelerate network performance. This includes discussing how processing that is accelerated by specialized hardware is different from processing by traditional, general-purpose CPUs. FortiGate II Student Guide 433 DO NOT REPRINT © FORTINET Hardware Acceleration After completing this lesson, you should have these practical skills. This lesson is mostly about tuning your configuration for performance. You should be able to use FortiGate features provided by the Network Processor (NP), Content Processor (CP), Security Processor (SP), and System on a Chip (SoC), such as offloaded IP sessions, accelerated IPsec and SSL encryption, and accelerated IPS and antivirus scans. FortiGate II Student Guide 434 DO NOT REPRINT © FORTINET Hardware Acceleration To begin, how can your configuration impact performance? Not all configurations are supported by hardware acceleration. So what does “hardware acceleration” mean? With hardware acceleration, a FortiGate’s CPU transfers some of its processing load to a specialized processor: • Network Processors (NP) • Security Processors (SP) • Content Processes (CP) Offloading frees up CPU cycles, and offloaded tasks execute faster on specialized hardware than they do on a general-purpose CPU. It’s a similar idea to how your computer uses the GPU on its graphics card: GPU often have dedicated RAM of their own, and GPU circuits are designed to be more efficient at processing images. FortiGate II Student Guide 435 DO NOT REPRINT © FORTINET Hardware Acceleration Like your computer uses its GPU to calculate graphics, your FortiGate uses its specialized chips to process networking and security. These specialized chips are called ASICs (Application-Specific Integrated Circuits). FortiGate ASICs are identified by their type (NP, SP, CP…) and version (1, 2, 3...). Generally, newer versions have more features and better performance. ASICs are wired into the circuit board, and therefore are not upgradable. FortiGate II Student Guide 436 DO NOT REPRINT © FORTINET Hardware Acceleration What types of processing does each ASIC do? Network Processors (NP) can handle packet forwarding, IPsec cryptography and hashing, link aggregation, HA, and a few other types of packet processing. Security Processors (SP) have their own CPU and memory, and can run security profile processes such as IPS and other flow-based inspection. FortiGate II Student Guide 437 DO NOT REPRINT © FORTINET Hardware Acceleration Content Processors (CP) do some types of content inspection, such as pattern matching, but they also handle SSL cryptography. NP can also handle cryptography, so what is the difference? CP acts like a co-processor in terms of its physical wiring: unlike most NP, CP are not bound to a specific network interface. System-on-a-Chip (SoC) processors combine a traditional system CPU with both a CP and NP. FortiGate II Student Guide 438 DO NOT REPRINT © FORTINET Hardware Acceleration Now that we’ve briefly compared the types of ASIC chips, let’s look at the evolution of each chip, and how to configure your FortiGate to use each ASIC for performance boosts. We’ll also show how offloading changes expected output for diagnostics. We’ll begin with NP. FortiGate II Student Guide 439 DO NOT REPRINT © FORTINET Hardware Acceleration This diagram shows how FortiGate decides whether or not to accelerate packet forwarding and IP session handling. For each new session, the first packet always goes to the kernel, on the CPU. If the NP supports all features you’ve configured FortiGate to apply to that session, then the kernel sends an instruction to the NP. This programs it to handle that session. Otherwise, if the NP doesn’t support everything that’s required, the kernel must continue to process all of that session’s packets. All subsequent packets for the fast path session is forwarded by the NP, not the CPU. The NP accelerates transmission. Finally, upon the last packet – a TCP “FIN” (finish) or “RST” (reset) signal, for example, or if there are errors – then the NP returns the session to the CPU so it can tear down the session. FortiGate II Student Guide 440 DO NOT REPRINT © FORTINET Hardware Acceleration Several hardware revisions of Network Processors exist. The first and seconds revisions can offload most types of IPv4 traffic. The next generation, NP4, has a significant performance increase over earlier versions. NP6 doubles that, and adds support for IPv6, CAPWAP traffic (for wireless control and provisioning) and multicast. FortiGate II Student Guide 441 DO NOT REPRINT © FORTINET Hardware Acceleration To find information about each of your FortiGate’s network processors, use the CLI command ‘get hardware npu’. FortiGate II Student Guide 442 DO NOT REPRINT © FORTINET Hardware Acceleration The first three versions of the NP do not support traffic statistics (including logs) except for the first and last packets in the IP session. Why? Because those two packets – when the session is being formed, and torn down – are handled by the kernel, on the CPU, before the session information is passed to an ASIC. In between, the ASIC chip processes packets mostly autonomously, so the kernel is not aware of statistics occurring during that time. (Remember that – we will notice its effects again during diagnostics.) And NP1 through NP4 did not have the memory to be able to keep their own statistics. NP6 is capable. It also supports the SNMP Ethernet MIB, so it can answer queries about these statistics, too. FortiGate II Student Guide 443 DO NOT REPRINT © FORTINET Hardware Acceleration To be eligible for offload, the traffic match the ASIC chip’s design criteria. For NP4, the criteria are: • Layer 2 type/length must be set to 0X0800. IEEE 802.1q and 802.3ad traffic can also be offloaded • Layer 3 must be unicast IPv4. (Multicast and IPv6 are not supported by NP4.) • Layer 4 must be UDP, TCP, SCTP or ICMP • Header or content must not require modification by a session helper • Traffic must not inspected by any kind of security profile, such as antivirus or web filtering • Traffic must not have originated from the firewall itself either • Ingress and egress ports must be on the same NP4, unless there is an EEI bridge between two communicating NP4s So you can see by comparing with this list that the NP6 criteria are like NP4, except that NP6 adds support for IPv6, NAT64, NAT46 and others. FortiGate II Student Guide 444 DO NOT REPRINT © FORTINET Hardware Acceleration FortiGate models with NP6 are physically wired together with an Integrated Switch Fabric (ISF). This allows communication between all interfaces and the NP6 processors without passing through the CPU. So offloading is possible, even if ingress and egress are not on the same processor. FortiGate II Student Guide 445 DO NOT REPRINT © FORTINET Hardware Acceleration To verify that a session is offloaded, use the CLI command ‘diagnose sys session list’. Offloaded sessions have the “npu info” line. FortiGate II Student Guide 446 DO NOT REPRINT © FORTINET Hardware Acceleration A minute ago, we mentioned that the kernel is not aware of what is happening with a session while it is being handled by an NP. So it impacts logging. What else does it impact? Packet capture involves the FortiGate’s kernel, which uses the CPU. NP chips do not send all of their data back to the CPU, since this would counteract acceleration. As a result, once a session is offloaded to an NP, the sniffer will not see those packets. During troubleshooting, you often need to see the entire session. So you may need to temporarily disable offloading. You can do this on a per-policy basis, in the CLI. FortiGate II Student Guide 447 DO NOT REPRINT © FORTINET Hardware Acceleration NP does more than just IP layer packet forwarding: • Active-Active HA load balancing • IPsec cryptography • Link aggregation • Basic anomaly detection that occurs before the software IPS engine • Basic traffic shaping FortiGate II Student Guide 448 DO NOT REPRINT © FORTINET Hardware Acceleration In HA active-active, the offload criteria is the same as for a standalone FortiGate. Hardware acceleration of user traffic is decided by each individual FortiGate in the cluster. Generally, traffic is load balanced for content inspection purposes, so hardware acceleration does not apply. It is, however, the redirection of packets in the same session that is offloaded, whereby the network processor re-writes the MAC addresses thus offloading the CPU from these interrupts. FortiGate II Student Guide 449 DO NOT REPRINT © FORTINET Hardware Acceleration If an IPsec tunnel uses encryption and hashing algorithms supported by the network processor, then the IPsec user data processing can be offloaded. FortiGate II Student Guide 450 DO NOT REPRINT © FORTINET Hardware Acceleration To verify IPsec traffic is offloaded, use the CLI command ‘diagnose vpn tunnel list’. This shows the status and statistics for each VPN tunnel. If it contains a line with ‘npu_flag’, the tunnel is being offloaded. FortiGate II Student Guide 451 DO NOT REPRINT © FORTINET Hardware Acceleration Network processors can also accelerate traffic for 802.3ad link aggregation – if all aggregated interfaces are associated with the same NP. (Depending on which vendors you’re familiar with, link aggregation is also called “NIC teaming,” “channeling,” or “link bonding.”) To determine if the channel is offloaded, use the CLI command ‘diagnose netlink aggregate’. Will all link aggregation-related processing be offloaded? No, again, offloading doesn’t occur until the CPU establishes the session and sends it to the NP. So in the initial phase of hashing – which is how the kernel decides which interface in the aggregate will send the first frame – the CPU is still involved. Offloading occurs after link aggregate hashing. FortiGate II Student Guide 452 DO NOT REPRINT © FORTINET Hardware Acceleration Some network processors can also detect some anomalies and drop those packets. This occurs in hardware, independently from and before the IPS engine is involved. To do this, configure the interface with ‘set fp-anomaly’. For example, you could configure your NP processor to drop packets with an unknown protocol number. FortiGate II Student Guide 453 DO NOT REPRINT © FORTINET Hardware Acceleration Some types of traffic shaping can be offloaded to a network processor. Limiting and prioritization are supported however guaranteed bandwidth cannot be offloaded and is handled by the CPU. The network processors have limited shaper objects (NP6 has more shaping objects and packet flow improvements), therefore traffic shaping by the CPU is still common. FortiGate II Student Guide 454 DO NOT REPRINT © FORTINET Hardware Acceleration Now that we’ve talked about which configurations that NP can improve performance for, let’s discuss SP. FortiGate II Student Guide 455 DO NOT REPRINT © FORTINET Hardware Acceleration Like a network processor, a security processor can also offload packet transmission. It can offload multicast, IPv4, IPv6, and NAT64 traffic. But it can also perform flow-based content inspection and provides SYN proxy functionality. FortiGate II Student Guide 456 DO NOT REPRINT © FORTINET Hardware Acceleration Like network processors, security processor features increase with each revision. The first revision can handle IPS and encrypted multicasting offload. The second revision added support for flow-based inspection. The third revision has performance benefits. FortiGate II Student Guide 457 DO NOT REPRINT © FORTINET Hardware Acceleration To determine the type of security processor in your FortiGate model (if any), use the CLI command “diagnose npu spm list”. In the example here, “xh0” indicates that an “FMC-XH0” model mezzanine expansion card is installed. This product family uses SP3. FortiGate II Student Guide 458 DO NOT REPRINT © FORTINET Hardware Acceleration Security processors mostly accelerate security related features, a network processor does not support these sessions. Security processors handling flow-based inspection, such as flow AV, IPS and application control, provide significant throughput benefits. FortiGate II Student Guide 459 DO NOT REPRINT © FORTINET Hardware Acceleration Flow-based IPS in a firewall policy can be offloaded; the ingress and egress interfaces must be bound to the same security processor. FortiGate II Student Guide 460 DO NOT REPRINT © FORTINET Hardware Acceleration DoS policies, depending on the type, can also be offloaded to the security processor. Like with antivirus, ASIC-based IPS doesn’t support proxy-based scans, since this would require more dedicated memory, or shared memory which would decrease performance. FortiGate II Student Guide 461 DO NOT REPRINT © FORTINET Hardware Acceleration An interface on a security processor can act as a TCP SYN proxy, dropping all connections not completed by the client within the timeout period, therefore providing greater protection for your backend servers against SYN floods. FortiGate II Student Guide 462 DO NOT REPRINT © FORTINET Hardware Acceleration With a SYN proxy inline, the client must close the three way handshake before the connection is passed to the kernel to establish the connection to the server, thus preserving CPU resources. FortiGate II Student Guide 463 DO NOT REPRINT © FORTINET Hardware Acceleration The SYN proxy is configured in the DoS profile ‘tcp_syn_flood’ setting, and applied to an interface with security processor. FortiGate II Student Guide 464 DO NOT REPRINT © FORTINET Hardware Acceleration Next, let’s show you the features of CP chips, and which configurations can use them for higher performance. FortiGate II Student Guide 465 DO NOT REPRINT © FORTINET Hardware Acceleration The content processor is a co-processor for the CPU. Since the very first FortiGate models, Fortinet has included a CP in the design. Those first models are obviously obsolete by now, so we won’t start at the beginning. Where will we start? CP4 has existed for some time, but is still relevant. Let’s start there. • Processes content • Generate pseudorandom numbers for cryptography • Encrypt and decrypt DES, 3DES, and AES for IPsec Phase 2 • Calculate SHA-1 and MD5 checksums for message authentication • Validate RSA public keys in PKCS#1 certificates FortiGate II Student Guide 466 DO NOT REPRINT © FORTINET Hardware Acceleration CP5 added FIPS and RFC compliance, and improved IPsec offloading with support for IKE and RSA. Additionally, its random number generator is compliant with SSL, which would become especially relevant to the next generation, CP6. FortiGate II Student Guide 467 DO NOT REPRINT © FORTINET Hardware Acceleration CP6 added hardware support for SSL, which was required for performance given the growing popularity of SSL VPN and SSL inspection. FortiGate II Student Guide 468 DO NOT REPRINT © FORTINET Hardware Acceleration CP8 added support for an IPS engine for signature pattern-matching, extended cryptographic support to include ARC4 and SHA-256, and large public keys. Additionally CP8 chips can be stacked for scalability. FortiGate II Student Guide 469 DO NOT REPRINT © FORTINET Hardware Acceleration Which CP does your FortiGate have? To determine this, use the CLI command ‘get hardware status’. FortiGate II Student Guide 470 DO NOT REPRINT © FORTINET Hardware Acceleration Finally, let’s look at a type of ASIC that integrates two of the others: SoC. FortiGate II Student Guide 471 DO NOT REPRINT © FORTINET Hardware Acceleration System on a Chip (SoC) combines a general purpose CPU with Fortinet’s custom ASIC network, security and content processors, into a single chip. Usually found in desktop or small office models because it allows smaller form factors, but cannot handle a carrier grade computing load, the biggest benefit of SoC is greater cost and energy efficiency. FortiGate II Student Guide 472 DO NOT REPRINT © FORTINET Hardware Acceleration With the CP8 and partial NP integrated onto a SoC processor, FortiGate can accelerate IP session handling, IPS, IPsec, and SSL. FortiGate II Student Guide 473 DO NOT REPRINT © FORTINET Hardware Acceleration A SoC processor integrates three ASICs. • The VPN module includes the SSL, TLS, and IPsec engines, which handle the encryption and decryption of traffic and message authentication algorithms. • The NPLite module is a light version (with fewer features) of an NP processor. It accelerates session handling. • The IPS deterministic finite automata (DFA) module is used to offload some IPS signaturematching. FortiGate II Student Guide 474 DO NOT REPRINT © FORTINET Hardware Acceleration Here is a review of what we discussed. We showed: • Architecture of each of the FortiASIC chip families • Which features can be offloaded to each chip • Differences between the chips • How to find which chips your model has • How to determine if traffic is taking advantage of offloading FortiGate II Student Guide 475 DO NOT REPRINT © FORTINET IPv6 In this lesson, we will show fundamentals of IPv6, and how to configure your FortiGate for it. This includes examples of how to enable security features in an IPv6 environment. FortiGate II Student Guide 476 DO NOT REPRINT © FORTINET IPv6 After completing this lesson, you should have these practical skills in IPv6 fundamentals and be familiar with FortiOS IPv6 features and their configuration: • IPv6 routing and firewalling • transition technologies such as dual-stack, NAT64 and 6to4 tunneling • IPv6-compatible security profiles Lab exercises can help you to test and reinforce your skills. FortiGate II Student Guide 477 DO NOT REPRINT © FORTINET IPv6 The newer version of the Internet Protocol adds an almost inexhaustible number of addresses thanks to a 128-bit long address field, compared to the 32-bits used by version 4. Since every connected device on the Internet needs an IP address, there will be increasing pressure to move to IPv6 as more non-computer devices come online in the so-called Internet of things. IPv6 specifies a new packet format designed to minimize packet header processing by routers. Because the headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not interoperable, therefore transition technologies are required to exchange traffic between the different networks. Such technologies include NAT64, tunneling, and dual-stack, which are covered in this call. That said, most transport and application-layer protocols need little or no change to operate over IPv6. FortiGate II Student Guide 478 DO NOT REPRINT © FORTINET IPv6 IPv6 packets only use the headers needed, and can concatenate as many headers as required. For example, a packet that does not require routing will not have the routing header. There are as many extension headers as there are protocols on IPv4, plus new headers. Example extension headers include: Hop by Hop (data to be processed by all the routers in the path of the packet); ICMPv6, TCP, UDP; Fragmentation; Routing; Destination Options (parameters/data that must be processed only by the destination host only); Authentication (AH, IPSEC); and Encrypted (ESP, IPSEC). FortiGate II Student Guide 479 DO NOT REPRINT © FORTINET IPv6 There are three types of addresses: unicast, anycast, and multicast. Unicast is an identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. Anycast is an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance). Multicast is an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. There are no broadcast addresses in IPv6; their function being superseded by multicast addresses. FortiGate II Student Guide 480 DO NOT REPRINT © FORTINET IPv6 IPv6 defines a 128-bit (16 bytes) address space. The 128-bit address is divided into eight 16-bit hexadecimal blocks, separated by colons. Therefore, theoretically there can be total 2^128 possible IPv6 addresses. The Prefix Length specifies how many left-most bits of the address belong to the network. It is comparable to the subnet mask in IPv4. A unicast address is composed of a Subnet ID (the first 64 bits) and an Interface ID (the other 64 bits). FortiGate II Student Guide 481 DO NOT REPRINT © FORTINET IPv6 To make the 128-bit address simpler, some abbreviations are possible. Take the address, 2000:5374:7564:656e:7431:0000:0000:1000. Leading zeros in a 16-bit block can be skipped, 2000:5374:7564:656e:7431:0:0:1000. A double colon can replace consecutive zeros or leading or trailing zeros within the address, 2000:5374:7564:656e:7431::1000. Note that the double colon can appear only once in an address. Any IPv6 host/node can have many IPv6 addresses on the same network interface card (NIC). FortiGate II Student Guide 482 DO NOT REPRINT © FORTINET IPv6 IPv4 network masks (255.255.0.0, etc.) are not practical with 128 bits. On IPv6, we now use prefixes as with IPv4, but with the huge address space of IPv6. Typical prefixes for IPv6 are: /48 an organization; /48 for a home user (or /64 if they are absolutely sure the address won’t change); and /128 for a point-to-point. FortiGate II Student Guide 483 DO NOT REPRINT © FORTINET IPv6 The Global Unicast Addresses is the most used prefix. This is the prefix from which your ISP provides your IPv6 addresses. Link-Local addresses are designed for addressing on a single link for purposes such as auto-address configuration, neighbor discovery, or when no routers are present. Routers must not forward any packets with link-local source or destination addresses to other links. Site-Local addresses are designed for addressing inside of a site without the need for a global prefix. Routers must not forward any packets with site-local source or destination addresses outside of the site. RFC 2373 describes the IPv6 Addressing Architecture (http://www.ietf.org/rfc/rfc2373.txt). FortiGate II Student Guide 484 DO NOT REPRINT © FORTINET IPv6 An IPv6 anycast address is an address assigned to more than one interface (typically belonging to different nodes). A packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thereby turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address. FortiGate II Student Guide 485 DO NOT REPRINT © FORTINET IPv6 An IPv6 multicast address is an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses have the FF00 prefix plus 112 bits group id. After the first 8 bits of the prefix (0xFF), the next 4 bits are the flags (the first 0x0 of the prefix) and indicate a permanent (0x0) or transient (0x1) address. The next 4 bits (the second 0x0 of the prefix) is the scope of the multicast group. FortiGate II Student Guide 486 DO NOT REPRINT © FORTINET IPv6 The "meaning" of a permanently-assigned multicast address is independent of the scope value. In the example, the "NTP servers group" is assigned a permanent multicast address with a group ID of 101 (hex). Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non-permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one site bears no relationship to: • a group using the same address at a different site • a non-permanent group using the same group ID with different scope, or • a permanent group with the same group ID Multicast addresses must not be used as source addresses in IPv6 packets or appear in any routing header. FortiGate II Student Guide 487 DO NOT REPRINT © FORTINET IPv6 IPv6 uses the Internet Control Message Protocol (ICMP), as defined for IPv4, with a number of changes. The resulting protocol is called ICMPv6 and has an IPv6 Next Header value of 58. ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets and to perform other internet-layer functions, such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of IPv6. The table shows common IPv6 types and codes. The Related Messages column indicates the message type. Its value determines the format of the remaining data. The code field depends on the message type. ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages are identified by a zero in the high-order bit of their message Type field values. Thus, error messages have message types from 0 to 127; informational messages have message types from 128 to 255. ICMPv6 is defined in RFC 4443. FortiGate II Student Guide 488 DO NOT REPRINT © FORTINET IPv6 This specification defines the Neighbor Discovery Protocol (NDP) for IPv6. Nodes (hosts and routers) use NDP to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use NDP to find neighboring routers willing to forward packets on their behalf. Finally, nodes use the protocol to actively keep track of which neighbors are reachable and which are not, as well as to detect changed link-layer addresses. When a route—or the path to a router fails — a host actively searches for functioning alternates. NDP replaces the following IPv4 mechanisms: ARP, ICMPv4 Router Discovery, ICMPv4 Redirect. NDP is defined in RFC 4861. FortiGate II Student Guide 489 DO NOT REPRINT © FORTINET IPv6 The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. Address autoconfiguration typically generates the global address on the network prefix, the node MAC address, and some additional bytes to complete the address space. IPv6 autoconfiguration is defined in RFC 4862. The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. FortiGate II Student Guide 490 DO NOT REPRINT © FORTINET IPv6 This slide demonstrates the stages a node progresses through to create link local and global unicast addresses. During the stateless ICMP6 autoconfiguration, no DNS information is exchanged. When using autoconfiguration, DHCP6 may be used to provide DNS and other values. If DHCP6 is configured as stateful, it may provide other options, such as providing an address from a range, querying a node, or changing an address. The gateway is provided by the router announcing the prefix. FortiGate II Student Guide 491 DO NOT REPRINT © FORTINET IPv6 The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. On the other hand, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), defined in RFC 3315, is used when a site requires tighter control over exact address assignments. Clients and servers exchange DHCP messages using UDP. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that the client need not be configured with the address or addresses of DHCP servers. To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client's link will relay messages between the client and server. FortiGate II Student Guide 492 DO NOT REPRINT © FORTINET IPv6 For HTTP, to use a literal IPv6 address for an adapter URI, enclose the IP address in square brackets "[", "]". For example, the nomenclature for a URI with the IPv6 address 2001:DB8:2a:1005:230:48ff:fe73:989d would be: [2001:DB8:2a:1005:230:48ff:fe73:989d]. Some changes to the application layer protocols are required to recognize the IPv6 address format. For DNS, a Name record for an IPv6 address is known as a AAAA record. FortiGate II Student Guide 493 DO NOT REPRINT © FORTINET IPv6 IPv6 transition mechanisms are technologies that facilitate the transitioning of the Internet from its initial (and current) IPv4 infrastructure to the successor addressing and routing system of IPv6. As IPv4 and IPv6 networks are not directly interoperable, these technologies are designed to permit hosts on either network to participate in networking with the other network. FortiGate II Student Guide 494 DO NOT REPRINT © FORTINET IPv6 The difference in security is that IPsec may be installed separately for IPv4, whereas it is a mandatory and integral part of the IPv6 stack and therefore available with any implementation. The IPsec specification defines protocols for the Authentication Header (AH) and the Encapsulating Security Payload header (ESP). With IPv6, these headers are included as Extension headers. The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone. The ESP header is either inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology. The header diagram, which applies to both IPv4 and IPv6, is taken from its RFC. FortiGate II Student Guide 495 DO NOT REPRINT © FORTINET IPv6 There are two fields in the IPv6 header that can be used for Quality of Service (QoS): the Traffic Class and the Flow Label field. The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. The Traffic Class field is specified in RFC 2474, and introduces the term “DS field” for the Traffic Class field. The goal of this specification is that DiffServ routers have a known set of DS routines, which are determined by the value in the DS field. The forwarding path behaviors thus includes the differential treatment an individual packet receives, as implemented by queue service disciplines and/or queue management disciplines. These perhop behaviors are useful and required in network nodes to deliver differentiated treatment of packets. The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. The Flow Label field is specified in RFC 6437, and may be used by a source to label packets for which it requests special handling by the IPv6 routers, such as non-default QoS or real-time service. Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify the flow to which a particular packet belongs. FortiGate II Student Guide 496 DO NOT REPRINT © FORTINET IPv6 Numerous IPv4 routing protocols are available for finding routes between networks, and almost every one of them has an IPv6 version or extension. As with IPv4, there are still interior gateway protocols (IGPs) and exterior gateway protocols (EGPs), distance vector based and link-state-based routing protocol algorithms. FortiGate II Student Guide 497 DO NOT REPRINT © FORTINET IPv6 FortiOS provides support for IPv6 firewalling, translation technologies for IPv4 and IPv6 interoperation, and security profiles. Malware and network-based threats are largely independent of the IP version. FortiOS is typically deployed with dual stack routing, where administrators assign both IPv4 and IPv6 addresses to interfaces. You can configure the FortiOS IPv6 features from the CLI or by enabling IPv6 through the GUI (System > Config > Features). Some IPv6 settings, however, remain CLI only. FortiGate II Student Guide 498 DO NOT REPRINT © FORTINET IPv6 To get started, configure an interface for IPv6 and add a prefix. Specify an easy to remember address and add a prefix for the same network. This causes FortiOS to send out router announcements supporting the auto configuration of your IPv6 enabled host. FortiGate II Student Guide 499 DO NOT REPRINT © FORTINET IPv6 Hosts on a link connected to a FortiGate may receive their address via SLAAC (stateless) or DHCPv6 (stateful). The address range for technical documentation is 2001:db8::/32 and is used throughout this lesson. FortiGate II Student Guide 500 DO NOT REPRINT © FORTINET IPv6 The example CLI configuration enables stateless autoconfiguration. It defines a network prefix that connected hosts use to create a global address. The interface IPv6 configuration is a sub-branch of the interface CLI. You can configure dual stack by configuring the IPv4 address and configuring an IPv6 address in the sub-branch. The onlink flag indicates the address is assigned to the interface on that specific link. FortiGate II Student Guide 501 DO NOT REPRINT © FORTINET IPv6 In this example, a host’s global address is provided in the stateful autoconfiguration process. Rather that receiving a prefix, the node sends a DHCPv6 request to the link-scope multicast address. The DHCPv6 response allocates an address from the configured range. FortiGate II Student Guide 502 DO NOT REPRINT © FORTINET IPv6 You can configure a FortiGate interface to receive it’s global IPv6 address via DHCPv6. FortiGate II Student Guide 503 DO NOT REPRINT © FORTINET IPv6 NAT64 is a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. Together with DNS64, these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication is initiated when either end uses existing, NAT-traversal, peer-to-peer communication techniques, such as Interactive Connectivity Establishment (ICE). Stateful NAT64 also supports IPv4-initiated communications to a subset of the IPv6 hosts through statically configured bindings in the stateful NAT64, which could be achieved using VIP46 in FortiOS. FortiGate II Student Guide 504 DO NOT REPRINT © FORTINET IPv6 DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. The IPv6 address contained in the synthetic AAAA RR is algorithmically generated from the IPv4 address and the IPv6 prefix assigned to a NAT64 device. DNS64 is defined in RFC 6052. FortiGate II Student Guide 505 DO NOT REPRINT © FORTINET IPv6 This configuration shows a sample NAT64 policy that is configured from the CLI. The source interface is an IPv6-enabled interface and the destination interface is an IPv4-enabled interface. FortiGate II Student Guide 506 DO NOT REPRINT © FORTINET IPv6 NAT66 is a stateless IPv6-to-IPv6 Network Prefix Translation (NPTv6) function, designed to provide address independence to the edge network. It is transport-agnostic with respect to transports that do not checksum the IP header. NAT66 provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. NAT66 is experimental and defined in RFC 6296. Note the IETF does not recommend the use of Network Address Translation (NAT) technology for IPv6. FortiGate II Student Guide 507 DO NOT REPRINT © FORTINET IPv6 You can apply security profiles to IPv6 firewall polices in the same way as IPv4 firewall polices. FortiGate II Student Guide 508 DO NOT REPRINT © FORTINET IPv6 FortiOS implements several tunneling protocols that are part of the transition technologies, allowing IPv6 communication to tunnel across an IPv4 network. FortiOS implementation includes IPsec to secure IPv6 in IPv4 tunnels. This mechanism is outlined in RFC 4891. FortiGate II Student Guide 509 DO NOT REPRINT © FORTINET IPv6 From a security perspective, we will focus on IPv6 tunneling over an IPv4 IPsec tunnel. To do this, in FortiOS create an IPsec interface mode tunnel, as with the regular site-to-site VPN configuration. Your Phase 2 selectors, routes, and firewall policies are all IPv6. FortiGate II Student Guide 510 DO NOT REPRINT © FORTINET IPv6 The diagnose command branch allows you to get status information and manually manipulate the IPv6 configuration. In the route list, note the link-local and multicast prefixes. In the neighbor-cache list, look for the autoconfuguration address for both FortiOS and any host. Note how the MAC address is used in the autoconfuration addresses. Remember in IPv6 there is no ARP, the neighbor mechanism replace this. From a Windows host you can view the neighbor-cache using the command “netsh interface ipv6” show neighbors (or “ip -6 neighbor show” in Linux). The packet sniffer supports IPv6. The following are example IPv6 filters: ‘ip6 and host 2000:5374:7564:656e:7431::3000’ to capture IPv6 host ‘ip6 and net 2000::/8’ to capture IPv6 prefix ‘ip6 and tcp port 80’ to capture TCP port number FortiGate II Student Guide 511 DO NOT REPRINT © FORTINET IPv6 In this lesson, we covered the following topics. We explained the IPv6 fundamentals necessary to configure FortiOS in an IPv6 environment and enable features such as transition technologies and security profiles. We also looked at the common diagnostic commands, and new commands, for IPv6 networks. FortiGate II Student Guide 512