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 SPP Profile ACLs
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.
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
- Use the Do Not Track IP Address dropdown menu to select the System ACL object for the policy.
- 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 SPP Profile ACLs
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 than TCP (Protocol 6) and UDP (Protocol 17) Note: Expert use. Incorrectly configured firewalls and home routers can result in highly fragmented IPSEC (ESP protocol 50) or GRE (Protocol 47). Use the Other Protocol Fragment Threshold which is automatically learned and set by the system for each SPP. |
TCP Fragment |
Drops any fragmented packet for TCP (Protocol 6) Note: Expert use. Unless you are absolutely sure that no TCP Fragments can be present, use the TCP Fragment Threshold which is automatically learned and set by the system for each SPP. |
UDP Fragment |
Drops any fragmented packet for UDP (Protocol 17) Note: Expert use. Unless you are absolutely sure that no UDP Fragments can be present, use the UDP Fragment Threshold which is automatically learned and set by the system for each SPP. |
IP Reputation |
|
DDoS |
Drops packets whose Source or Destination IP is associated with DDoS C&C servers. Note: This is not a “signature” for DDoS attacks. Today’s DDoS attacks use spoofed Source IPs or legitimate IPs from reflecting servers. These cannot be ACLed without unintended consequences. FortiDDoS more than 200,000 other mitigations will stop attacks. |
Anonymous Proxies |
Drops packets whose Source or Destination IP is associated with Anonymous Proxies |
Phishing |
Drops packets whose Source or Destination IP is associated with Phishing sites. |
Spam |
Drops packets whose Source or Destination IP is associated with Spam email. |
Tor |
Drops packets whose Source or Destination IP is associated with Tor exit nodes |
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:
- Select the ICMP Profile to edit.
- Enable ICMP Type Code ACL.
- Create New ACL.
- 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
DNS expert use only. DNS ACLs for FQDNs files, FQDN and Regex Lists, and DNS Resource Records are complex, and errors can significantly affect DNS services both inbound and outbound. Contact Fortinet for advice. |
The DNS Profile supports 5 different ACLs:
-
DNS Fragment(s), which are the first DNS Query or Response packet with the More Fragments bit set (subsequent fragmented packets in Responses 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.
-
Forbid DNSSEC, which drops any DNSSEC packet (RR Option 41). This ACL is for expert use and should remain disabled for normal use. Today most DNS resolvers request DNSSEC responses and most Authoritative DNS servers support DNNSEC.
-
FQDN Files for large (150k) Allowlist/Block list entries – more information below
-
FQDN Lists for:
-
Regular – normal text/punycode FQDNs
-
Regex – Regular Expressions for pattern matching within the FQDN
Note: All three FQDN Files, Regular, and Regex can be used simultaneously but they can all only be Allowlist or Blocklist, controlled by the FQDN Control List Type feature in the DNS Profile.
See more information below.
-
-
Resource Record ACLs block specific or ranges of unused Resource Records from 0-255. See more information below
FQDN Files (Allowlist/Blocklist files)
Each SPP Profile allows you to add large numbers of FQDNs (maximum 150k) as CSV files to the Blocklist or Allowlist enabled in the DNS Feature Controls.
Normally the FQDN is set to Allowlist and the entries are the FQDNs of the protected Authoritative DNS server (enterprise-class – the 150,000 FQDNs allowed is not large enough for DNS hosting providers).
There is a further option in the DNS Feature controls to match Queries to the Allowlist only when the SPP is under DNS Query flood.
The FQDN Control List (Blocklist or Allowlist) is processed before any other DNS feature, anomaly or validation. For example, a DNS Query that is allowed to pass by the DNS Control List and gets a good Response will populate the LQ and TTL tables with FQDN, Type, Class and TTL.
File format is CSV or TXT, with one FQDN per line.
For further detail, please see DNS Profile.
FQDN List
Create individual FQDN (maximum 1024) and/or Regex (maximum 128) entries here. These entries follow the FQDN Control List Type settings selected for the DNS Feature Controls, Allowlist or Blocklist.
Please note this means you cannot have a Blocklist with FQDN List exceptions, for example.
FQDN List entries are not searchable from the FQDN file search, instead you can filter for FQDN List entries using the Add Filter function.
FQDN List - Regular
Enter domain names here if you need a small number of domains. Otherwise use FQDN files as above
For further detail, please see DNS Profile.
FQDN List – Regex
Enter regular expressions here for more complex domain name matches.
For further detail, please see DNS Profile.
The DNS Resource Record Type ACL
The DNS Resource Record Type ACL allows blocking of any number of DNS Resource Record Types by QTYPE number. The DNS QTYPE field allows 65,536 TYPES of which fewer than 100 are defined and less are in common use.
The following Qtypes can be blocked:
-
Known Qtypes which are not needed (for example: ALL/ANY=255)
-
Deprecated Qtypes (for example: NULL=10)
-
Undefined Qtypes (for example: 32770-65279)
DNS Resource Record Type ACLs are defined in numeric ranges. A single ACL entry has DNS Resource Record Type Start = DNS Resource Record Type End.
A further option in the DNS Profile Feature Controls allows Query Resource Record matching to this ACL only when the SPP is under Query Flood