Forti''R6 5HOHDVH 1RWHV Version 4..

Transcription

1 Forti Version 4..

2 FORTINET DOCUMENT LIBRARY FORTINET VIDEO GUIDE FORTINET BLOG CUSTOMER SERVICE & SUPPORT FORTIGATE COOKBOOK FORTINET TRAINING SERVICES FORTIGUARD CENTER FORTICAST END USER LICENSE AGREEMENT FEEDBACK Monday, September 11, 2017 FortiDDoS Release notes Revision 2

3 TABLE OF CONTENTS Change Log 4 Introduction 5 What s new 6 Hardware support 9 Image checksums 10 Upgrading 11 Supported upgrade paths 11 Section 1: Upgrading using GUI 14 Section 2: Upgrading via CLI 15 Section 3: Upgrading via BIOS 17 Sample console log 19 Downgrading 21 Factory reset 23 Resolved issues 24 Common Vulnerabilities and Exposures 28 Known issues 29

4 Change Log Change Log Date Change Description Initial release for version Revision 2 with updated note under the section 'Upgrading'. 4 Release Notes 4.4.0

5 Introduction Introduction This document provides a list of new/changed features, upgrade instructions and caveats, resolved issues, and known issues for FortiDDoS build The TP2ASIC version is , Date: Aug 18, FortiDDoS is a network behavior anomaly (NBA) prevention system that detects and blocks network attacks that are characterized by excessive use of network resources. These attacks are known as distributed denial of service (DDoS) attacks. For additional documentation, please visit: Release Notes

6 What s new What s new FortiDDoS release includes the following new features and enhancements: New features and Enhancements FortiGuard Domain Reputation is a subscription-based service that periodically (daily/weekly) and automatically downloads a list of about 1 Million known-malicious domain names based on FortiGuard's continuous research. The Domain Reputation ACL is entered in FortiDDoS' hardware mitigation TP2s resulting in no performance degradation despite the size of the list. Users can also continue to add up to approximately 200,000 Blacklisted Domain ACLs which are also entered in the TP2s for maximum performance. All traffic and drop-related graphs can now be displayed with the former linear Y-axis or a logarithmic Y-axis. The logarithm axis allows better views of widely diverse graphs. The default TCP Session timeout of eight minutes is now configurable from 1 second to 1023 hours. This allows FortiDDoS to: match firewall timeouts. create specific SPPs for authenticating servers like SSL VPN where long periods of idle traffic can happen after authentication. SPPs with authenticating servers should have Slow Connection tracking turned off. Specific Source and Destination IPs (Extended Timeout Policy) can use the Extended TCP Session timeout that overrides the standard SPP TCP Session timeout and Slow Connection Tracking. This could be used by Hosting providers to allow specific customers to log on to their servers via SSH or FTP, for example, for long periods, without being timed-out, while the web servers are protected from Slow Connection attacks from other clients. TCP Slow Connections settings are now configured per SPP. Proxy IP Policy is added. Users can now: add specific IP addresses (not subnets) to the Proxy IP in addition to the IPs found algorithmically. prevent specific IP addresses (not subnets) from being used in the Proxy IP list, even if found algorithmically. SPP names (as well as ID #) are added to Executive Summary, Summary and Detail Log screens. Tunneling (for use of a web proxy) on the IP Reputation configuration page, now works for System Registration, IP Reputation, Domain Reputation and (Cloud) Signaling. Pagination has been added to all pages where long lists might be created, to ease navigation and improve response. Latin American Spanish and Portuguese is now supported in the FortiDDoS GUI. 6 Release Notes 4.4.0

7 What s new New features and Enhancements Dashboard improvements: System Status widget has been organized for better readability. SPP Operating Mode - Inbound and Outbound 'LEDs' in the System Status Widget can now be used to Switch the SPP and direction between Detection and Prevention by clicking on the LED. A new graph has been added. Graph displays aggregated (all) SPP traffic inbound or outbound, showing ingress and egress traffic. This is a quick display of traffic and attacks (if egress is lower than ingress) for the entire appliance. Graph can be linear or logarithmic Y-axis and is continuously refreshed. Attack Log is now filterable by Time as well as Date via date filter. CLI command get system ha now shows 'effective mode' as Master, Slave or Fail. Remote log settings can be configured to suppress low-drop-count logs by defining a minimum drop threshold value. At this threshold or higher, the drops will be sent to Syslog and SNMP trap receivers. All the log information can still be viewed under Attack Log, Reports and Executive Summary. SNMP v3 support is added for Event Traps (CPU, Memory, Disk Usage). See System > SNMP > User. Applying Domain Blacklists to the hardware from user files can take several minutes. This is done in the background and the user can leave the page while this is processed. A progress message and 'spinner' have been added to the page to indicate if the process is not complete. Configured Reports now show the system Host Name in place of the system Serial Number. The default Host Name is the system Serial Number so Report information will not change unless the Host Name is changed. SPP thresholds as set by System Recommendations or manually can now be exported as CSV. To improve user understanding the following items have been renamed: 'Aggressive aging due to slow connection' is renamed 'Foreign Packets (Aggressive Aging and Slow Connections)'. 'Foreign packets" is renamed 'Foreign Packets (Out-of-State)'. DDoS Attack Log event is renamed from: 'Slow connection: Aggressive aging' to 'Foreign Packets (Aggressive Aging and Slow Connections)'. TCP and UDP Port 0 traffic is now reported as Port Denied Drops. Improvements are made in field entry validation throughout the GUI/CLI/REST entries. In general, special characters that should not be allowed are no longer allowed. Previous entries that include special characters will not be affected on upgrade. String length validation is checked in all fields. Some labels were modified for clarity. Some special characters which are not recommended in various system fields for security purposes were previously allowed via GUI or CLI. The following characters will no longer be allowed except in some L7 fields like URLs, Referers and Hosts; and authentication fields like LDAP Distinguished Name. Previously entered special characters will not be invalidated. < > % ` ~ ^ & ( ) [ ] { } = Release Notes

8 What s new New features and Enhancements Multiple subnets can be saved in Trusted Hosts field for Radius/LDAP Default access strategy. Global ACL options for 'Accept' and 'Deny' are now context-sensitive. The pre-populated "admin" text in the user field of the login dialog box has been removed. NTP operation is improved. System ensures all network connections are ready before attempting to access NTP server. Unsuccessful access to NTP server generates an event log. Added column headings for event log CSV exports, for readability. An Event log item is added to confirm successful or failed SPP Factory Reset. SPP Policy validation is improved to prevent entry of broadcast addresses. Exported/downloaded Blacklisted IPv4 Addresses and Blacklisted Domains' file name includes the system Serial Number, Date and Time for easier identification. Additional information (Type All/Any) has been added to the DNS Info Anomaly label. 8 Release Notes 4.4.0

9 Hardware support Hardware support This release supports the following hardware models: FortiDDoS 200B FortiDDoS 400B FortiDDoS 600B FortiDDoS 800B FortiDDoS 900B FortiDDoS 1000B FortiDDoS 1000B-DC FortiDDoS 1200B FortiDDoS 2000B FortiDDoS 2000B-USG FortiDDoS A series models are not supported. Release Notes

10 Image checksums Image checksums To verify the integrity of the firmware file, use a checksum tool to compute the firmware file s MD5 checksum. Compare it with the checksum indicated by Fortinet. If the checksums match, the file is intact. MD5 checksums for software releases are available from Fortinet Customer Service & Support: Figure 1: Customer Service & Support image checksum tool After logging in to the web site, in the menus at the top of the page, click Download, and then click Firmware Image Checksums. Alternatively, near the bottom of the page, click the Firmware Image Checksums button. (The button appears only if one or more of your devices have a current support contract.) In the Image File Name field, enter the firmware image file name including its extension, then click Get Checksum Code. 10 Release Notes 4.4.0

11 Upgrading Supported upgrade paths Upgrading Note: FortiDDoS TP2 hardware takes longer to upgrade than x86-based systems. Prepare your maintenance window to accommodate at least 20 minutes for the upgrade (most will not take this long but some may). In some cases, you need to upgrade to an intermediate release before the final upgrade (2 x 20 minutes). Plan accordingly, after you understand the upgrade path from the table below. We strongly recommend that while you can upgrade via GUI, you also connect to the console port, which will provide status messages during the upgrade process, while the GUI is offline. Changes in will result in the GUI not being fully functional for about 3 minutes after it becomes available following upgrade (while other background tasks are completed). If you get 'internal server error' responses from the GUI, please wait for several moments and try again. Supported upgrade paths Use the following instructions to upgrade to FortiDDoS Steps Current Release Upgrade method Upgrade path 1 <4.1.5 BIOS ONLY 1. Upgrade to Upgrade to Follow Step Upgrade to Follow Step 3. Refer to section 3 for detailed upgrade procedure to GUI/CLI/BIOS 1. Upgrade to Upgrade to Follow Step 3. Refer to sections 1, 2 and 3 for detailed upgrade procedure. If desired, create a new SPP for DNS servers. Allow the system to operate for one week (recommended) and then generate traffic Statistics for all active SPPs (even if new DNS SPP was not created). Run System Recommendations to set new System Recommended Thresholds. We suggest you place SPPs into Detection Mode for several hours to days to monitor for falsepositives, then tune Thresholds and place SPPs into Prevention Mode. Release Notes

12 Supported upgrade paths Upgrading Steps Current Release Upgrade method Upgrade path to GUI/CLI/BIOS Upgrade directly to Refer to sections 1, 2 and 3 for detailed upgrade procedure. In 4.3.x, a new Method Per Source Scalar has been added to all SPPs. After upgrading, there will be no Threshold for these. We suggest to allow the system to operate for one week after upgrade, then generate Traffic Statistics and view the Method Per Source Scalar. Either manually set this Threshold by multiplying the Inbound Traffic measurement by three and entering that number in the Threshold or run System Recommendations for all thresholds. If you create new System Recommendations, we suggest to place the SPPs into Detection mode for a few days and review drops for false positive errors. Note the following: If you are upgrading via BIOS, failure to follow the upgrade path will result in the loss of system configuration and all stored data for graphs and reports. Upgrading FortiDDoS takes significantly longer than x86-based systems. For upgrading from the GUI, we recommend connecting a console as well, which will allow you to see upgrade information during the process. Otherwise please expect >15 minutes for an upgrade - the time will vary depending on the number of TP2 processors in the appliance. To track the progress of upgrade from any version, check the console and once the upgrade is done, clear your browser cache and refresh. FortiDDoS and later releases adds additional parameter monitoring and Thresholds for DNS Features. When upgrading from Releases prior to 4.2.0, in order to activate these Thresholds, FortiDDoS needs to operate for several hours to several days. Then you need to run Traffic Statistics Reports and System Recommendations to create Thresholds. It is recommended that DNS servers be placed in a separate SPP to facilitate this. If you have Asymmetric Traffic, allow the system to operate for at least 8 days after upgrade, then re-run 1-week Traffic Statistics and System Recommendations. This will modify the TCP High Port Thresholds to improve graphing and responsiveness. This is required even though you may have followed instructions to re-run Traffic Statistics as part of the upgrade process. For FortiDDoS 4.2.x, the SPP Statistics shows data for packets/period while 4.3.x shows packets/sec. So the same level of traffic data shown in 4.2.x and 4.3.x would be different. 12 Release Notes 4.4.0

13 Upgrading Supported upgrade paths Prerequisites The procedures explain the upgrade from If your system is not at 4.2.3, please refer to the table above and follow the instructions. Download the firmware file from the Fortinet Technical Support website: Check that the upgrade info file is available on your FortiDDoS system: On the System Status page, click on the CLI Console window to connect and see the # prompt. Enter: f cat /var/log/upgrade_info.txt If you do not see 4,2,0 or 4,2,1, followed by the system Serial Number or Host Name and # prompt, check which Release is showing in the System Summary page and if 4.2.0, or is showing, contact Fortinet support. This file is needed to properly upgrade your system. Examples: 4,2,0 FI800B # 4,2,1 FDD-169 # Back up your configuration before beginning this procedure: If you later revert to an earlier firmware version, the active configuration is deleted, and you will want to restore the configuration that worked well with the earlier version. Attempting to use a system configuration from a newer firmware release on a downgraded firmware release may have unexpected results. Make a note of configuration items that are disabled in your active configuration. Configurations that are not enabled are not preserved in the upgrade to For example, if a custom HTTP service port, log remote port, or event log port have been configured and then disabled in an earlier version, the configuration information is not preserved in the upgrade to You must have super user permission (user admin) to upgrade firmware. After upgrade you may need to regenerate system recommended Thresholds. If so, record any manually-set Thresholds before upgrading so you can re-enter these after new Thresholds have been set. Release Notes

14 Section 1: Upgrading using GUI Upgrading Section 1: Upgrading using GUI Ensure that you have read the general Upgrading section before you start an upgrade. Note: You can upgrade directly to FortiDDoS via GUI from any version above For any version below 4.2.3, you MUST upgrade to and then to The following figure shows the user interface for managing firmware. For this upgrade, you must use Partition 2. To install firmware: 1. Go to System > Maintenance > Backup & Restore tab. 2. Under Firmware Upgrade/Downgrade, in the row for Partition 2, click the Upload and Reboot icon to display the upload file controls. 3. Use the upload file controls to select the firmware image file. 4. Click OK to upload the file, install the firmware, and restart the system. Always use Partition 2 for upgrades even if Partition 2 is showing a newer Release than Partition 1. From 4.2.3, partition choices will not be shown. WARNING: The reboot takes several minutes (as many as 15) longer for larger systems and there is no progress indicator on the GUI. FortiDDoS must write register information to each TP2 which takes considerably longer than simply loading x86 firmware as in most systems. This is only a factor in the upgrade reboot. Once installed, the TP2 firmware is persistent and will only change with a further upgrade. It is very important the system not be disturbed or power cycled during this process. A power cycle will result in an unusable system that must be returned to factory for repair. Ideally, leave the system for 20 minutes. If the system has NOT recovered in that time, contact Fortinet Support. 5. Clear your browser cache to avoid potential issues that can be caused by caching. During upgrade, the console will show upgrade progress information if a terminal is connected to it. See the Sample console log for reference. 6. Login and from Dashboard, confirm that the firmware version is correct. 14 Release Notes 4.4.0

15 Upgrading Section 2: Upgrading via CLI Section 2: Upgrading via CLI Ensure that you have read the general Upgrading section before you start an upgrade. Note: You can upgrade directly to FortiDDoS via CLI from any version above For any version below 4.1.5, you MUST upgrade to and then to To install firmware: 1. Connect your management computer to the FortiDDoS console port using an RJ-45-to-DB-9 serial cable or a nullmodem cable. Use the following terminal settings: Speed (Baud Rate): 9600 Data Bits: 8 Stop Bits: 1 Parity: None 2. Initiate a connection to the CLI and log in as the user admin. 3. Use an Ethernet cable to connect FortiDDoS mgmt1 to the TFTP server directly, or connect it to the same subnet as the TFTP server. 4. If necessary, start the TFTP server. 5. Enter the following command to transfer the firmware image to the FortiDDoS system: execute restore image tftp <filename_str> <tftp_ipv4> where <filename_str> is the name of the firmware image file and <tftp_ipv4> is the IP address of the TFTP server. For example, if the firmware image file name is image.out and the IP address of the TFTP server is , enter: execute restore image tftp image.out The following message appears: This operation will replace the current firmware version! Do you want to continue? (y/n) 6. Type y. The system gets the image from the TFTP server, installs the firmware, and restarts. See the Sample console log for reference. WARNING: The reboot takes several (as long as 15) minutes longer for larger systems (see the progress examples from the console output below). FortiDDoS must write register information to each TP2 which takes considerably longer than simply loading x86 firmware as in most systems. This is only a factor in the upgrade reboot. Once installed, the TP2 firmware is persistent and will only change with a further upgrade. It is very important the system not be disturbed or power cycled during this process. A power cycle will result in an unusable system that must be returned to factory for repair. Ideally, leave the system for 20 minutes. If the system has NOT recovered in that time, contact Fortinet Support. To verify that the firmware was successfully installed, login and use the get system status command, confirming the version information is correct: Release Notes

16 Section 2: Upgrading via CLI Upgrading FI200B # get system status Version: FortiDDoS-200B v4.4.0,build0505, TP2ASIC Version: Date: Aug 3, 2017 IP Reputation DB: ( :00:03) Domain Reputation DB: Serial-Number: FI200B BIOS version: Log disk: Capacity 62 GB, Used 548 MB ( 0.85%), Free 62 GB RRD disk: Capacity 369 GB, Used 164 GB (44.54%), Free 204 GB Hostname: FI200B HA configured mode: standalone HA effective mode: standalone Distribution: International License Type: - Uptime: 1 days 3 hours 19 minutes Last reboot: Thu Aug 10 12:20:51 PDT 2017 System time: Fri Aug 11 15:39:55 PDT 2017 FI200B # IMPORTANT: Releases 4.1.6, and included improvements to system recommended thresholds and threshold ranges. If you upgraded from any release lower than 4.2.0, take the following additional steps after the upgrade to has completed and the system has restarted: If you now have a DNS SPP, you will need to leave that SPP in learning mode (no Thresholds and in Detection mode only) for as long as possible (1 week recommended). After one week you can run Traffic Statistics and set thresholds, as well as configure DNS Features and Anomaly settings. Then run for another week in Detection mode to check that Thresholds and settings are correct. For every other SPP, immediately enter the following commands to re-generate traffic statistics over the longest period of known clean traffic: config spp edit <spp_name> config ddos spp threshold-report set generate enable set report-period {last-hour last-8-hours last-24-hours last-week last-month lastyear} end Create System Recommendation with the following commands: config spp edit <spp_name> config ddos spp threshold-adjust set threshold-adjustment-type system-recommendation set threshold-system-recommended-report-period {1-hour 8-hours 1-day 1-week 1-month 1-year} end Re-enter the manual threshold settings you want to continue using from your previous configuration. See Thresholds for commands. 16 Release Notes 4.4.0

17 Upgrading Section 3: Upgrading via BIOS Section 3: Upgrading via BIOS Ensure that you have read the general Upgrading section before you start an upgrade. Note: You can upgrade directly to FortiDDoS via BIOS from any version above For any version below 4.1.5, you MUST upgrade to and then to The system configuration will be lost when upgrading using BIOS. For this reason, BIOS upgrade should only be used for upgrading new systems that have not been put in service. If you want to delete customer configuration and traffic data from a system, use CLI commands: execute factory-defaults: to delete configuration. execute formatlogdisk: to delete traffic data and logs. To upgrade the firmware: 1. Download the new firmware image. 2. Copy the file to a location you can access from the FortiDDoS appliance using TFTP. 3. Connect to the FortiDDoS appliance console. 4. Reboot the system and, when prompted, press any key to display the BIOS configuration menu. 5. Select option G so that the system can get the new firmware image from the TFTP server and load it when it reboots. The following example shows the CLI sequence: FI-1KBXXXXXXXXX # exe reboot This operation will reboot the system! Do you want to continue? (y/n) y System is rebooting... The system is going down NOW!! Please stand by while rebooting the system. FortiDDoS-1000B (19: ) Ver: Serial number:fi1kbxxxxxxxxxx RAM activation CPU(00:000306a9 bfebfbff): MP initialization CPU(01:000306a9 bfebfbff): MP initialization CPU(02:000306a9 bfebfbff): MP initialization CPU(03:000306a9 bfebfbff): MP initialization CPU(04:000306a9 bfebfbff): MP initialization CPU(05:000306a9 bfebfbff): MP initialization CPU(06:000306a9 bfebfbff): MP initialization CPU(07:000306a9 bfebfbff): MP initialization Total RAM: 8192MB Enabling cache...done. Scanning PCI bus...done. Allocating PCI resources...done. Enabling PCI resources...done. Zeroing IRQ settings...done. Verifying PIRQ tables...done. Boot up, boot device capacity: 15272MB. Press any key to display configuration menu Release Notes

18 Section 3: Upgrading via BIOS Upgrading [G]: Get firmware image from TFTP server. [F]: Format boot device. [B]: Boot with backup firmware and set as default. [I]: Configuration and information. [Q]: Quit menu and continue to boot with default firmware. [H]: Display this list of options. Enter Selection [G]: Please connect TFTP server to Ethernet port "MGMT". Enter TFTP server address [ ]: Enter local address [ ]: Enter firmware image file name [image.out]: FDD_1000B-v440-build0505-FORTINET.out MAC:085B0E9F061C ######################################################################### Total bytes data downloaded. Verifying the integrity of the firmware image. Total kB unzipped. Save as Default firmware/backup firmware/run image without saving:[d/b/r]?d Programming the boot device now Reading boot image bytes. Initializing FortiDDoS... System is started. 6. Set the management port IP address and gateway IP address using the console. 7. If you saved and edited the configuration file, restore it using the CLI or web UI. 8. If you did not save a configuration file, you must reconfigure the user accounts and system options. 18 Release Notes 4.4.0

19 Upgrading Sample console log Sample console log Sample console log while upgrading from to 4.4.0: FI200B # execute restore image tftp FDD_200B-v4.4.0-build0505-FORTINET.out This operation will replace the current firmware version! Do you want to continue? (y/n)y Connect to tftp server Please wait... ########################################################################################################## Get image from tftp server OK. Verifying the integrity of the firmware image. FI200B # The system begins to upgrade... Firmware upgrade in progress... New image: FI200B FW-build Done. 2 The system is going down NOW!! Please stand by while rebooting the system. FortiDDoS-200B (20: ) Ver: Serial number:fi200b RAM activation CPU(00:000306a9 bfebfbff): MP initialization CPU(01:000306a9 bfebfbff): MP initialization CPU(02:000306a9 bfebfbff): MP initialization CPU(03:000306a9 bfebfbff): MP initialization CPU(04:000306a9 bfebfbff): MP initialization CPU(05:000306a9 bfebfbff): MP initialization CPU(06:000306a9 bfebfbff): MP initialization CPU(07:000306a9 bfebfbff): MP initialization Total RAM: 8192MB Enabling cache...done. Scanning PCI bus...done. Allocating PCI resources...done. Enabling PCI resources...done. Zeroing IRQ settings...done. Verifying PIRQ tables...done. Boot up, boot device capacity: 15272MB. Press any key to display configuration menu Reading boot image bytes. Initializing FortiDDoS...\ufffd Release Notes

20 Sample console log Upgrading System is started. Updating Application Image FortiASIC-TP.0: update started. Reconfigure process takes a few minutes FortiASIC-TP.0: 0% Complete FortiASIC-TP.0: 10% Complete FortiASIC-TP.0: 20% Complete FortiASIC-TP.0: 30% Complete FortiASIC-TP.0: 40% Complete FortiASIC-TP.0: 50% Complete FortiASIC-TP.0: 60% Complete FortiASIC-TP.0: 70% Complete FortiASIC-TP.0: 80% Complete FortiASIC-TP.0: 90% Complete FortiASIC-TP.0: FPGA image download complete. FortiASIC-TP.0: Checking update image on FPGA... FortiASIC-TP.0: Checking update image on FPGA...OK, GBL_RUPD_RECONFIG_STAT = 0x3 FortiASIC-TP.0: UPDATE FPGA OK, WAIT FOR REBOOT... FortiASIC-TP.0: update finished FortiDDoS-200B (20: ) Ver: Serial number:fi200b RAM activation CPU(00:000306a9 bfebfbff): MP initialization CPU(01:000306a9 bfebfbff): MP initialization CPU(02:000306a9 bfebfbff): MP initialization CPU(03:000306a9 bfebfbff): MP initialization CPU(04:000306a9 bfebfbff): MP initialization CPU(05:000306a9 bfebfbff): MP initialization CPU(06:000306a9 bfebfbff): MP initialization CPU(07:000306a9 bfebfbff): MP initialization Total RAM: 8192MB Enabling cache...done. Scanning PCI bus...done. Allocating PCI resources...done. Enabling PCI resources...done. Zeroing IRQ settings...done. Verifying PIRQ tables...done. Boot up, boot device capacity: 15272MB. Press any key to display configuration menu Reading boot image bytes. Initializing FortiDDoS...\ufffd System is started. FI200B login: 20 Release Notes 4.4.0

21 Downgrading Downgrading Use the following instructions to downgrade, if necessary, from FortiDDoS or earlier releases. Note the following: All the configurations would be lost on downgrading using GUI, CLI or BIOS. Downgrading returns the system to factory default with no user configuration. If you do not have a stored backup configuration of the earlier release and must downgrade, you will need to backup your current configuration, edit the first line to the correct destination (downgraded) firmware release, build number and date, and restore that configuration file. If you are unsure of this step, contact Fortinet Support. Downgrades below are NOT recommended for bug and security reasons. If you need to downgrade below you may need to alter your current configuration, removing all NTP configurations and removing multiple remote syslog servers if configured. Please contact Fortinet Support if you need to downgrade below When downgrading from 4.3.x to releases before 4.2.3, there may be no default IP assigned to the Management 1 port. This will need to be set via CLI. We do not recommend downgrading to releases earlier than Downgrading from and earlier versions You can use the web UI, CLI or BIOS to downgrade from and earlier releases. You can downgrade directly to the release you want to use. To downgrade firmware: 1. Take a backup of your configuration. Downgrade will delete the current configuration and will set everything to factory defaults. Use GUI: 1. Go to System > Maintenance > Backup & Restore tab. or Use CLI: 2. Select Back Up option and click Back Up B # execute backup config tftp 137.conf Connect to tftp server Please wait... # Send config file to tftp server OK. 2. Load new build via GUI/ CLI or BIOS. For GUI: 1. Go to System > Maintenance > Backup & Restore tab. 2. Select the file and upload. The system will reboot. For CLI: B # execute restore image tftp FDD_900B-v4.4.0-build0505- FORTINET.out This operation will replace the current firmware version! Do you want to continue? (y/n)y Connect to tftp server Please wait... Release Notes

22 Downgrading #################################################################### #### Get image from tftp server OK. Verifying the integrity of the firmware image. This operation will downgrade the current firmware version! You will lose your existing configuration Do you want to continue? (y/n)y B # 3. The system will reboot and reprogram the FPGA. This takes about min based on what appliance you are using. WARNING: Reboot or power fail during this process will result in unusable product, requiring RMA. 4. Once the system is up, assign the IP address and restore the saved configuration. System will reboot and apply the configuration. The system should be ready to use. 22 Release Notes 4.4.0

23 Factory reset Factory reset If you want to restore a system to factory defaults with no customer configuration or traffic data, do the following from CLI: # execute formatlogdisk - removes all traffic data. # execute factoryreset - removes all configurations. Release Notes

24 Resolved issues Resolved issues The resolved issues listed below do not list every bug that has been corrected with this release. For inquires about a particular bug, please contact Fortinet Customer Service & Support. Mantis ID Description In some cases, combinations of login failures and logged-in user timeouts will result in Event Log not showing any events unless any filter is applied to the Event Log If the alert connectivity test fails, the system may be unresponsive for several minutes and you cannot navigate away from the page. The system/gui will eventually return with a failure message. fixed in with a one-minute time-out and note with GUI test button One customer was reporting large numbers of drops when a Threshold is set for TCP Port 443 but there was no actual traffic on that port. Specific testing in has been unable to reproduce this System-generated packets such as RSTs and SYN-ACKs/TC=1 were shown on the Port Statistics graphs but not on the SPP Statistics graphs Under high attack loads, ICMPv6 attack events occasionally did not show the correct protected IP or subnet ID In 4.2.x, multi-line strings were allowed in the Body or Reports s. This was removed in 4.3.x and is returned in Values for Thresholds larger than the system maximum could be entered via CLI with no error message and values then set to system maximum. Error message has been added When creating port ranges via CLI, the system will accept out-of-bounds entries with no messaging. Error message has been added In rare cases, if there are 100% drops for TCP Ports, UDP Ports, ICMP or URLs, Ingress traffic graphs may not show Under heavy traffic conditions, DDoS Attack Log, 'Save as PDF' may not create the PDF Under stress, some L7 HTTP Flood events did not show Protected IP SYN ingress rates were peak rates per period while egress rates are averages over the same period, which resulted in mismatched graph data. Egress now shows peak rates as well Diagnostics > Sources showed direction as 0/1 instead of Inbound /Outbound. 24 Release Notes 4.4.0

25 Resolved issues Mantis ID Description If Persistent HTTP Transactions is disabled, (default in 4.3.1) Method per Source still checks every packet for correct header. This can result in higher than expected Method per Source counts DNS QDCount label updated to reflect setting. Valid QDCounts are 0 or Report with type 'Default Subnet' might not display data Save as PDF for Exec Summary - DDoS Attack log displays first column as 'Attack' for all tables. This is correct for some tables but incorrect for others Releases prior to auto-refreshed the Dashboard page. This was removed in 4.3.x and is replaced in In some cases, after upgrading to 4.3.x, the top level Aggregate Drop graph does not show Layer 3 Anomaly Drops but Anomaly Aggregate and Layer 3 Anomaly graphs show the drops. Fixed when upgrading from < 4.3.x to Executive Summary > DDoS Attack Log graph - Save as PDF may show SPP:All, even though 'All' cannot be selected Click combinations while editing admin accounts could expose Password and Confirm Password fields The authentication strategy for user 'admin' could be changed to Radius or LDAP. This user should always be a local user A non-admin user with limited access to one SPP might be able to create Reports for other SPPs and Global The same IPv6 Address could be entered in Do not Track policy and Address ACL rules DNS NODATA Responses were being dropped as anomalies Protected IP was missing in 'top attack destination' drops widget Deleting Management IPs, rebooting box and adding management IPs, resulted in SSH connection refusal. Second reboot fixed the problem Non-admin users with access to only one SPP might have been able to view Reports for other users For 600B/900B only: Executive Summary > DDoS Attack Log > Top Attacked Destinations > Detail pop-up is empty Slow connection values shown on GUI were incorrect for type 'None'. Release Notes

26 Resolved issues Mantis ID Description Maximum GUI length for SPP Service: URL Deny ACL is increased from 1023 in 4.3.x to Command: diagnose hardware get deviceinfo data-ports did not always return results Slow TCP Connection Observation Period (Global) was incorrectly labeled with a range of Correct range of is included in Log and Report menus are seen even if user has no access to them When defining Users, the Trusted Host field is not accepting multiple hosts Maximum length of URL entered from GUI for SPP ACL was 1024 characters when it should be 2047 characters In SPP ACL list, 'Service Action' column incorrectly showed 'Deny' for some 'Allow' conditions Filters set in Attack Logs were reset when SPPs changed but check box selections still showed. Filters will now be persistent across SPP changes Event Log would show two 'Invalid user:login failed' logs and one successful login event for a single login URL was only calculating for 1023 characters. This has been extended to 1400 characters. There is no standard for URL length but the default maximum length is about 2000 characters. If you are using URLs of longer than 1400 characters, please contact your Fortinet CSE or Support Invalid HTTP version anomaly drops events did not show the Protected IP Occasionally, a few DNS blacklisted domain drops are reported to incorrect SPPs There was no way to cancel a change to the SPP Switching measurement when the confirmation warning was seen If some objects had maximum-length name, it could not be deleted from GUI but could be deleted from CLI Disabling an Alternate SPP did not remove its details from the GUI System allowed out-of-order manual attack log purge dates If FortiDDoS is connected to an external bridge, with automatic traffic switching to the Monitor ports, a reboot may result in FortiDDoS failing to pass traffic. 26 Release Notes 4.4.0

27 Resolved issues Mantis ID Description Global Settings > Address > Local Address Config/Local Address Config IPv6 both allowed duplicate entries. Note that if there are duplicate entries in the existing configuration before upgrade, the upgrade will remove the second and subsequent entries. Duplicate entries would not work in previous releases, even though they could be entered Sessions Diagnostic GUI page could become unresponsive if all options were unchecked On Event Log page under Log & Report > Log Access > Logs, if Health Check filter is checked by itself, matching Event Logs are displayed but event Details sometimes could not be opened In some cases, when changing SPP Thresholds between PPS and Mbps, incorrect thresholds may result A configuration could be uploaded to different model FortiDDoS with unpredictable results Attack/Cloud Signaling mode could be changed while devices had valid connection and registration. This is now prevented unless registration is removed Global Settings > Settings > Signaling was not properly validating IP address entries If Signaling Shared Key contains blanks, Attack/Cloud Signaling will not work correctly. Field now validates characters SNMP Community string and SNMP v3 User string could be left blank Admin account could assign credentials with blank passwords It may have been possible to add duplicate host IPs in SNMP settings. Note that if there are duplicate entries in the existing configuration before upgrade, the upgrade will remove the 2nd and subsequent entries. Duplicate entries would not work in previous releases, even though they could be entered Time interval on Alert Settings page shows maximum of when the actual max is Service provider and third-party attack/cloud signaling may not have worked correctly for protected IPv6 subnets Removed TCP Port 143 (IMAP) and added Port 139 (NetBIOS) to Threshold settings Invalid formats of uploaded files for IPv4 Blacklists resulted in an error message but no way to acknowledge the message and continue On 1200B only, the System > Interface drop-down menu includes unsupported modes. The only valid modes are 'Auto' for 10GE and '1000Full' for GE Under some conditions drops on SPP-4 could result in false drops showing in SPP-0. Release Notes

28 Resolved issues Mantis ID Description It was not possible to disable all three Event Traps in System > SNMP, if all that was required was MIB access Attack/Cloud Signaling should only be sent when an SPP is switching to itself When 'Restrict DNS Queries to Specific Subnets' ACL was configured, Attack/Cloud Signaling would not be sent Non-admin user logins with limited permissions can result in no visible graphs CLI command for Signaling > Customer Premise devices (config ddos global customer-premisesdevices) allowed non-standard characters A non-admin read-write user may not have been able to access Port Statistics graphs Restoring an SPP configuration would not work if 'Restrict DNS Queries to Specific Subnets' ACL was configured for that SPP If enabled, Drop Range Header may not have dropped fragmented HTTP In some cases, when a L3 flood also contains L4 anomalies, drops will show in both graphs. Normally, we would expect the L3 Flood drops to take precedence and no L4 drops would be seen SNMP v3 entries could be saved without selecting security level. Default security is now included In multi-card FortiDDoS systems, ACL Denied Protocols (0-255) may not show the protected IP in every event EDNS0 DNS packets >512 Bytes and >1500 Bytes were incorrectly checked for premature end-ofpacket anomalies REST API Query might not work if no local user is logged-in to system and might be allowed with incorrect password. Common Vulnerabilities and Exposures FortiDDoS is no longer vulnerable to the CVE-References in the below table. Visit for more information. Mantis ID CVE References Release Notes 4.4.0

29 Known issues Known issues This section lists the known issues of this release, but is not a complete list. For inquires about a particular bug, please contact Fortinet Customer Service & Support. Mantis ID Description If a user tries to enter Management IP port as Destination /24 and Gateway as via GUI, FortiDDoS will store it as: Destination /24 and Gateway If the user attempts to enter Gateway as via CLI, the system returns 'Invalid IP address'. This will only occur if the user enters an IP address ending in.255 from the GUI If a Deny ACL is set and then removed within a 5-minute reporting period, the drops associated with that ACL will be shown as a Flood Drop Event. This is as-designed behavior and has been documented in Help documentation. It will be removed from future 'Known Issues' lists System does not send RSTs to DNS server under some L7 DNS TCP floods (DNS Query/Src, DNS Packet - Track/Src). Sources will be blocked if configured. It is unlikely that Source Blocking is used for DNS and also unlikely that there will be TCP-based floods which require a real connection For TCP and UDP Port graphs, if a port shows 0 traffic for a long period of time and then some traffic arrives, the port graph may show the most recent traffic across the zero-traffic period Based on the hardware logic, 'Unsolicited Inbound DNS Response Drops' will show in Outbound graphs On multi-tp2 models, traffic with Ethertypes 0x9100 (QinQ) and 0x88a8 (802.1ad/aq) are not load-balanced across more than 1 TP2. Ethertype 0x8100 (802.1q) works as expected The default all-route IPv6 address - ::/0 - does not result in IPv6 blocking when entered in a global ACL Some IPv6 ACL entries are not validated against previous entries for overlapping subnets To reduce logging, FortiDDoS attempts to combine similar small attacks before reporting in the Attack Log. If there are very large numbers of small attacks (slow connections, for example), the GUI becomes slow while the background tasks are completed System allows duplicate IP addresses or IP/subnet masks between Global and SPP Address config. Global ACLs will take precedence Report schedule hour configuration does not adjust for Daylight Savings Time change. For example, if reports are scheduled to run at 9 am, they will run at 10 am after time change. Release Notes

30 Known issues Mantis ID Description When downgrading from 4.3.x to any Releases before 4.2.3, there may be no default IP assigned to the Management 1 port. This has to set via CLI. We do not recommend downgrading to releases earlier than Please read the Downgrading section of this Release Notes carefully before attempting a downgrade Only local admin users can access REST API calls. No Remote or Local non-admin users will be able to perform any actions using REST API calls. This is as-designed and included here for information only. This will be documented in appropriate system and REST API documentation 'Boot Alternate Firmware' button should not be used. This option will be removed in future releases Downgrading the system from 4.3.x to 4.2.x or lower releases and then upgrading directly back to 4.3.x does not recreate eve_subcode table which will result in some attack events missing from the logs 'Event Remote Log' allows duplicate entries Editing an existing entry to an invalid string in Admin/Radius/LDAP Trusted hosts clears the original value Remote Log entry IP address is not validated by system SPP ID numbers are not validated when entered via CLI. User should take care to avoid duplicates if working in CLI When there are a very large number of connections, Diagnostic > Sessions /Sources page may not be current When applying large files to hardware for IPv4 Blacklist, the system responds that the process has succeeded when in fact the process may take several minutes to complete in the background. The process is confirmed finished when the 'Number of addresses applied' field increments to the number of IPs in the list There is no validation between the timeouts for Slow TCP Connection Observation Period, TCP Session Idle Timeout and TCP Session Extended Timeout. Whatever period is chosen for Slow TCP Connection Observation Period, TCP Session Idle Timeout should be longer and TCP Session Extended Timeout should be longer still Using RADIUS authentication may prevent users from accessing all SPPs If system is in Wire Mode link synchronization and one link has failed, (resulting in 2nd link being failed by the system) a reboot will lose that link synchronization. On reboot, the failed link will not be reflected to the second link. 30 Release Notes 4.4.0

31 Known issues Mantis ID Description There is no validation if user enters the same IP address in Extended Timeout Policy and ACL Deny policy. ACL Deny will take precedence In testing, Port Statistics and SPP Statistics graphs may not match exactly due to data collection timing improves this and does not affect real-world information Report Type SPP with multiple SPPs selected only generates report for the first selected SPP. Release Notes

32 Copyright 2017 Fortinet, Inc. All rights reserved. Fortinet, FortiGate, FortiCare and FortiGuard, and certain other marks are registered trademarks of Fortinet, Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet s internal lab tests. In no event does Fortinet make any commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.