Step 6: Define SPPs and subnets

Service Protection Policies (SPPs) and Protected Subnets are the heart of FortiDDoS protection. SPPs define or contain:

Protected Subnets
Learned Traffic Statistics and Thresholds for over 200,000 parameters for the Protected Subnets
- Note: Traffic Statistics and Thresholds are recorded and set per-SPP no matter how many protected subnets are in the SPP or how large the subnets are. However, monitored parameters are a mixture of:
  - Per-Destination IP (single IPs in the Protected Subnets) – SYN-per-Destination, for example
  - Per- Source IP (single IPs from OUTSIDE the SPP) – SYN-per-Source, for example
  - Per-Source Port (single UDP ports from any number of IPs OUTSIDE the SPP – UDP Port Thresholds automatically look at Source ports from 1 to 9,999 from outside the SPP, for example
  - Per-Destination Port (aggregate rate to a TCP or UDP port and one or many IPs in the SPP)
  - Aggregate to the SPP (all Protected Subnets) - SYN, for example
- When thresholds are crossed, FortiDDoS performs different functions for different parameters. It may:
  - Validate the Source IP – SYN or DNS Query, for example
  - Validate packet content - DNS LQ or DNS TTL, for example
  - Rate limit the parameter no matter the number of Sources or Destinations – UDP Port and UDP Port Reflection, for example
  - Rate Limit the Source – SYN-per-Source, DNS Query-per-Source, for example
  In addition, 38 important Thresholds, called Scalars, feature machine-learned Adaptive Thresholds that adjust each threshold for medium-term seasonality in the traffic.
Specific SPP mitigation features
Nine Service Protection Profiles assigned to the SPP, each with additional SPP mitigation features for IP, TCP, ICMP, HTTP, SSL/TLS, NTP, DNS, DTLS and QUIC traffic
SPP-specific ACLs
SPP-specific Cloud Signaling for Cloud DDoS Service partners

SPPs can be individually toggled between Prevention Mode (mitigation) and Detection Mode (monitor: report drops but pass all traffic).

All Monitor graphing is done per SPP and per parameter, with Attack Logs showing over 150 different attack types, many with “depth”. For example, for:

UDP Port Flood events, any attacked port from 1-65,535 will be shown in the log
UDP Reflection Flood events, any of 1-9,999 Source Ports will be shown in the log

Additional log information comprises the SPP, Protected Subnet, Protected IP, and in cases of per-Source drops or confirmed non-spoofed Source IPs, the Source IP is also included.

Protected Subnets from an IPv4/32 or IPv6/128 are defined in each SPP. FortiDDoS automatically subnets for you. You can assign a /24 subnet to the “Infrastructure” SPP with a /32 IP address from that /24 to the “Web” SPP and a second /32 to the “Firewall” SPP. FortiDDoS will monitor and learn traffic for each /32 (and SPP containing that /32) separately from the /24.

This Section will focus on creation of SPPs and Protected Subnets so that the system can begin learning traffic parameters as quickly as possible. Other than the configurations shown here, all other settings must remain default. For further configuration of additional SPP Settings and Thresholds please see Service Protection Policy Feature Settings.

Defining SPPs

For enterprise users, configure SPPs, at a minimum, to protect different services:

Firewalls, email servers, WiFi gateways, outbound Proxies and other outbound connection originators (and outbound DNS Query originators)
Web servers
Authoritative DNS servers
VPN Servers
Full subnet(s) (for IP addresses not covered above)

Different types of services require different types of mitigations. Combining different services into a single SPP may result in “lowest-common-denominator” protection.

Conversely, if you have different types of web servers on different IP addresses, particularly if some servers allow client logins, separating the non-login and login servers in two different SPPs can be useful.

Balancing this is the effort to manage Thresholds on multiple SPPs. Initial setup will take longer with more SPPs and while ongoing SPP “maintenance” is minimal, the fewer the better.

For hosting and ISP users, end-user services may not be obvious or most users are residential or mobile. If users are homogeneous, spread the subnets across several SPPs. If there are clear differences like residential/commercial or residential/mobile you can create SPPs for those. In all cases, the “enterprise” services for the hosting provider or ISP should be defined like the enterprise section above.

FortiDDoS models provide differing numbers of SPPs:

Model	VM04	VM08	200F	VM16	1500/ 1500F-LR	2000F	3000F
SPPs	4	8	8	16	16	16	16

One SPP (default) is always present and cannot be renamed or deleted. The default SPP gathers traffic for subnets that are not defined in other SPPs. If needed, the default SPP can be used for explicit Protected Subnets. If using the default SPP, place the largest subnets you have in this SPP.

Before you begin:

You must have a good understanding of the list of SPPs you need to deploy.
You must have a good understanding of the features you want to enable.
You must have Read-Write permission for Service Protection settings.

Caution: The name of the SPP cannot be modified once it has been created. Ensure that you are satisfied with the name before you do further SPP configuration. The only way to have a different SPP name is to delete the SPP and create a new one.

Note: Deleting an SPP removes a significant amount of graph and log data. Please see instructions to delete SPPs.

Creating a new Service Protection Policy

Go to Service Protection > Service Protection Policy and click Create New.
In the SPP configuration window, enter the SPP Name only and click Save.
Once saved, you can:
1. Continue with creating additional SPPs
2. Edit the created SPP and continue with further SPP configuration including Protection Profile Settings, Protection Subnets or ACLs.

To configure using the CLI:

config ddos spp rule

edit <spp_name>

end

Configuring protected subnets

Before you begin:

You must have a good understanding of the subnets you will be protecting
You must have Read-Write permission for Service Protection settings.

Configure subnets (from IPv4 /24 or IPv6 /128) protected by an SPPs settings and threshold with the following steps:

Go to Service Protection > Service Protection Policy and select the Service Protection Policy from the list.
Navigate to Protection Subnets and click Create New
Name of the Protected Subnet (Max length = 35 characters, a-Z, 0-9 and “-“ or “_” only)
Enter the IP/netmask. Note: IPv4 and IPv6 subnets can be used in the same SPP
Leave all other fields as default and click Save
Note: Once saved, you cannot edit the Name of the Protected Subnet. You must delete it and re-enter the Name and Subnet information.
Continue adding additional subnets until finished.
When finished, clicking Cancel from the Service Protection Policy page will return you to the SPP List where you can edit additional SPPs to add more Protected Subnets

Applying Service Protection Profiles

Before you begin:

You must have a good understanding of the protection requirements for each SPP.
You must have Read-Write permission for Service Protection settings.

Note: While preferred, it is not critical that Service Protection Profiles be applied when defining SPPs and Protected Subnets. You can return to the SPP and add them at any time but they must be applied before the SPP is set to Prevention Mode since many mitigations will not be used unless the Profiles are assigned. This section will be repeated in Service Protection Policy Feature Settings.

There are 7 Service Protection Profiles that must be assigned to each SPP. In some cases one Profile can be used for all SPPs but in other cases each SPP will require a unique profile. Please see SPP Profiles Overview for details on SPP Profiles Overview.

SPP Profiles	Description
IP profile	Enables/disables ACLs for IP header anomalies, Private address space, multicast address space, fragments and IP Reputation. Normally a single Profile can be used for all SPPs Profile can be used with Symmetric or Asymmetric Mode.
ICMP profile	Enables/disables ACLs for ICMP anomalies and can ACL all unused ICMP Type/Codes (only about 114 of the available 65k ICMP Types and Codes are ratified by IANA and IETF). Optionally, defines ACLs for specific Types/Codes or ranges of Types/Codes. Use with care. For example Type/Code 3:4 is requires for TCP PathMTU calculation. Most users can use a single Profile for all SPPs. Profile can be used with Symmetric or Asymmetric Mode
TCP profile	Enables/disables a significant number of TCP features and mitigations. This Profile is critical for SYN Flood mitigation. Most users can use a single Profile for all SPPs. Profile may need modification for Asymmetrc Mode — see Understanding Asymmetric Traffic.
HTTP profile	Enables/disables specific HTTP protection features. Profile can be used with Symmetric or Asymmetric Mode Use with care — see HTTP Profile.
SSL/TLS profile	Enables/disables SSL/TLS anomaly and renegotiation protections. Important for HTTPS servers but can be used by all SPPs. Profile may need modification for Asymmetric Mode — see Understanding Asymmetric Traffic and SSL/TLS Profile
NTP profile	Enables/disables several NTP anomaly checks and 2 important NTP Reflection flood mitigations. Most users can use a single Profile for all SPPs. Profile requires modification for Asymmetric Mode — see Understanding Asymmetric Traffic and NTP Profile.
DNS profile	Enables/disables several DNS anomaly checks as well as several important DNS Flood attack features. Separate DNS Profiles are needed for Authoritative DNS servers; recursive DNS Servers; Firewalls, email servers and other users of outbound DNS Queries; web servers; and other infrastructure. DNS Reflection Floods are used against all infrastructure, not just DNS servers, so appropriate Profiles are required on all SPPs. Profile requires modification for Asymmetric Mode — see Understanding Asymmetric Traffic and DNS Profile.
DTLS profile	Enables/disables one DTLS anomaly check and one state check. Profile requires modification for Asymmetric Mode – see Understanding Asymmetric Traffic and DTLS Profile.
QUIC profile	Enables/disables four QUIC anomaly checks and one state check. Profile requires modification for Asymmetric Mode – see Understanding Asymmetric Traffic and QUIC Profile.