Using FortiDDoS ACLs

This section includes the following information:

• ACL Overview
• ACL Structure
• Define system ACL objects
• Define Global Access Control Lists
• Define Do Not Track Policies
• Define SPP Access Control Lists
• Define Service Protection Profiles

ACL Overview

With some notable exceptions, ACLs are ineffective for DDoS mitigation since most DDoS attacks use spoofed Source IP addresses. Geolocation and Source IP ACLs will miss widely randomized Source IPs in DDoS attacks. However, ACLs can be useful for the following:

• Blocking known UDP reflection ports that have no legitimate use
• Offloading other infrastructure like firewalls from ACLing “normal” traffic from undesirable countries or prefixes
• Blocking known NTP Reflection packets (Mode 5/7) – please see the NTP Profile for this specific ACL

Note: ACLs are not connection-direction sensitive. If for example you ACL an external server IP address to prevent it from sending unsolicited traffic to you, any if your users attempting to connect to that server will be blocked because all inbound packets (a SYN-ACK, for example) will be blocked from that Source IP.

ACL Structure

ACLs are defined in several places for different reasons:

• Global ACLs always drop traffic no matter the Detection/Prevention Mode of SPPs.

  Global ACLs use System ACL Objects defined in System > Address and Service and apply those Objects to Global Protection > Access Control Lists

• Do Not Track Policy ACLs use the same System ACL Objects defined in System > Address and Service and apply those Objects to Global Protection > Do Not Track Policy > Track and Allow or Do not Track ACLs. Do Not Track Policies do not support Geolocation objects.
• SPP ACLs use the same System ACL Objects defined in System > Address and Service and apply those Objects to Service Protection > Service Protection Policy > ACL.

  SPP ACLs drop or report and allow packets along with other SPP features and threshold depending on the Detection / Prevention Mode status of the SPP.

• SPP Profile ACLs

  Some Service Protection > Profiles support ACLs that do not require System ACL Objects:

  • Service Protection > ICMP Profile allows the entry of ICMP Type/Code ACLs.
  • Service Protection > HTTP Profile > HTTP Param ACL allows the entry of Regex expressions for URLs, Hosts, Referers, Cookies or User Agents ACLs.
  • Service Protection > NTP Profile allows a checkbox ACL for NTP Reflection Deny (NTP packets using Mode 6 or Mode 7 parameters)
  • Service Protection > DNS Profile > DNS Resource Record Type ACL allows the entry of DNS Resource Record ranges.

  In all cases, these ACLs will apply to any SPP to which that Profile is applied and will follow SPP Detection/Prevention Mode rules.

• Blocklist ACLs are bulk Global ACLs populated by uploading:
  • Lists of IPv4 Addresses to Blocklist > Blocklisted IPv4
  • Lists of DNS FQDNs to Blocklist > Blocklisted Domains

  Please refer to the handbook section on these functions for additional information.

• IP Reputation and Domain Reputation are specialized, dynamic, subscription-based ACLs for malicious and botnet IP Addresses and Domains. Other than subscription purchase there is no user management needed

  Note: IP Reputation and Domain Reputation are not required for DDoS Mitigation.

Define system ACL objects

You can create System Objects for:

• IPv4 and/or IPv6 addresses, subnets and ranges, geolocation
• Services for Layer 3 Protocols, Layer 4 TCP and/or UDP Ports
• Address and Service Groups to include multiple objects from above

These objects/groups are then used to create:

• Global ACLs
• Global Do Not Track and Track and Allow ACLs
• Service Protection Policy (SPP) ACLs

Define System ACL objects via System > Address and Service for:

• Address IPv4
  • Address/netmask
  • Address Range

    Note: Address/netmask and Address Ranges can be ACLed as Sources or Destinations in the Access Control List. Destination ACLs should be used to block traffic to your inside protected public IPs. Source ACLs normally block traffic from outside public IP addresses.

  • Geolocation
  
  

  To configure using the CLI: config system address4 edit addr1 set type {ip-netmask|ip-range|geo} set ip-netmask <ip/mask> set ip-max <ip> set ip-min <ip> set country <string> next end

• Address IPv4 Group
  • Groups IPv4 Addresses, Ranges and/or Geolocations from above into a single object.
  
  
• Address IPv6
  • Address/netmask
  • Address Range
• Address IPv6 Group
  • Groups IPv6 Addresses or Ranges from above into a single Object.
• Service
  • IP Protocols (0-255)
  • ICMP (Protocol 1)
  • TCP, UDP or both TCP and UDP:
    • Destination Ports
    • Source Ports

    Note: Common UDP Reflection Source Port Objects are pre-configured. These can be deleted, modified, added to Service Groups as desired.

  To configure using the CLI: config system service edit <name> set protocol-type {ip|icmp|tcp|udp|tcp-and-udp} set specify-source-port {enable|disable} set source-port-min <0-65535> set source-port-max <0-65535> set destination-port-min <0-65535> set destination-port-max <0-65535> next end

  
  
• Service Group
  • Groups Services into a single Object
  
  

Define Global Access Control Lists

Define Global ACLs via Global Protection > Access Control List > IPv4 or IPv6.

Note:

• Global ACLs are always in Prevention Mode, dropping traffic regardless if the individual Service Protection Profiles are in Detection or Prevention Mode.
• Global ACL drops will always show in the default SPP in 6.1.x versions.
• The Global ACL list is searched top-to-bottom. You many need to re-order the list using the arrow buttons on the right for correct behavior.

ACL Settings

Setting	Description
Name	a-Z,0-9, - , _ only
Status	Enable or disable ACL
Action	Reject = block/drop Accept = process the packet with for all other mitigations. This is not a allow-list indicator. See Do Not Track Policy for Allow-list configuration and behavior
Source Type	Address or Address Group (for IPv4 or IPv6 depending on the menu chosen)
Source Address	Pulldown showing all available System ACL objects
Destination Type	Address or Address Group (for IPv4 or IPv6 depending on the menu chosen)
Destination Address	Pulldown showing all available System ACL objects
Service Type	Service or Service Group
Service	Pulldown showing all available System Service ACL objects

To configure using the CLI: config ddos global {acl | acl6} edit <entry_index> set source-address <address_name> set action {accept | deny} next end

Define Do Not Track Policies

Do Not Track policies define two different types of Allowlists for IPv4 and/or IPv6 addresses, subnets or ranges:

• Do Not Track
  • No traffic nor drops will be reported for this ACL – there is no visibility of any traffic to or from this address
  • Traffic is not used for learned Traffic Statistics
  • Use this very carefully and ever use this for protected IP addresses. If an attacker can discover this IP address, he can launch attacks FortiDDoS will not monitor.
• Track and Allow
  • FortiDDoS processes traffic normally and reports virtual drops a but packets are always allowed to pass. Think of this as a mini-Detection Mode for IP addresses or subnets.
  • Use this ACL with care. While FortiDDoS reports attack traffic, it may not be obvious that the system is allowing the traffic to pass, even when all SPPs are in Prevention Mode.

  Note: Allowlists are relevant whether the IP address is a Source or a Destination.

Define Do Not Track Policies via Global Protection > Do Not Track Policy > IPv4 or IPv6

1. Use the Do Not Track IP Address dropdown menu to select the System ACL object for the policy.
2. Select Track and Allow or Do not Track.

Define SPP Access Control Lists

Define SPP ACLs via Service Protection > Service Protection Policy > ACL.

Note:

• The SPP must be defined first before you can add any ACLs
• ACL Settings and allowable entries are identical to the Global settings above.
• SPP ACLs confirm to SPP Detection/Prevention rules.

To configure using the CLI: config ddos spp rule edit <spp_name> config acl edit <acl_name> set status { enable | disable } set action { reject | accept } set ip-version { IPv4 | IPv6 } set source-address4-type { addr4 | addr-grp4 } set source-address-v4 <IPv4 Address> set source-address-v4-group <IPv4 Address Group> set source-address6-type { addr6 | addr-grp6 } set source-address-v6 <IPv6 Address> set source-address-v6-group <IPv6 Address Group> set service-type { service | service-grp} set service-id <Service> set service-grp-id <Service Group> next end next end

Define Service Protection Profiles

Service Protection Profiles for IP, ICMP, TCP, HTTP, SSL/TLS, DNS and NTP contain feature settings used to define mitigations when the Profiles are assigned to Service Protection Policies. The following Profiles support ACLs:

IP Profile

Some feature selections in the IP Profile are effectively ACLs:

IP Private Check	Drops packets whose Source IP is in private IP ranges like 10.0.0.0/8
IP Multicast Check	Drops packets whose Source IP is in private IP range 224.0.0.0/4
Above options should be enabled for all IP Profiles for any Service Protection Policy
IP Fragment Check
Other Protocol Fragment	Drops any fragmented packet for Protocols 0-255, other then TCP (Protocol 6) and UDP (Protocol 17)
TCP Fragment	Drops any fragmented packet for TCP (Protocol 6)
UDP Fragment	Drops any fragmented packet for UDP (Protocol 17)

Unless you have expert understanding, these Fragment ACLs must be disabled for all IP Profiles used in any Service Protection Policy. Instead, use the 3 Fragment Thresholds that FortiDDoS automatically learns.

ICMP Profile

After creating a new ICMP Profile you can create ICMP Type/Code ACLs for ICMPv4 and/or ICMPv6.

Note: For non expert-users, enable “ICMP Type Code Anomaly”. This drops all non-IETF/IANA-ratified Types and Codes. Less than 150 Types and codes of 65,536 combinations are ratified.

To create more granular ICMP Type/Code ACLs:

1. Select the ICMP Profile to edit.
2. Enable ICMP Type Code ACL.
3. Create New ACL.
   
4. Enter Type/Code Ranges. You are allowed to create a total of 8 per ICMP Profile.

HTTP Profile

After creating an HTTP Profile, you can create HTTP Param ACLs for URLs, Hosts, Referers, Cookies and/or User Agents. Regex entries allow wildcard ACLs.

NTP Profile

NTP Reflection Deny is an available option in the NTP Profile. NTP Reflection Deny drops any packet where the Mode field is 6 (readvar) or 7 (monlist). These Modes are deprecated and are only used for amplified reflected NTP floods.

Enable this for all NTP Profiles.

Additional NTP Profile settings are discussed in the NTP Profile.

DNS Profile

After creating a DNS Profile, you can create DNS Resource Record Type ACLs.

1. Edit the DNS Profile
2. Create New DNS Resource Record Type ACL range

DNS expert use only. IETF RFCs allow 65,536 possible DNS Resource Records but only a handful are in current use but they are widely scattered across the full range. Study the RFCs carefully before ACLing Resource Records. FortiDDoS’s various Query and Response thresholds and validations will fully protect from any Resource Record used in a DDoS attack.

The DNS Profile also allows you to ACL DNS Fragments, which are the first DNS Query or Response packet with the More Fragments bit set (subsequent fragmented packets have no Layer 4 headers to identify them as DNS packets and will be seen as Layer 3 UDP Fragments).

Unless you are an expert user, disable this option. DNS Responses from EDNS0-enabled servers can exceed normal MTUs resulting in fragmented packets. Use the FortiDDoS automatically learned DNS Fragment Threshold to mitigate DNS Fragment (usually Reflected Response) floods.