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 230,000 parameters for the Protected Subnets
Specific SPP mitigation features
Seven Service Protection Profiles assigned to the SPP, each with additional SPP mitigation features for IP, TCP, ICMP, HTTP, SSL/TLS, NTP and DNS traffic
SPP-specific ACLs
SPP-specific Cloud Signaling for Cloud DDoS Service partners

SPPs can be individually toggled between Prevention (mitigation) Mode and Detection (monitor) Mode.

All graphing is done per SPP with logs showing SPP and Protected Subnet and Protected IP.

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	1500F
SPPs	4	8	8	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.

Note: Configuring a new SPP requires system configuration of more than 230,0000 Round Robin Databases for that SPP. This can take several minutes, depending on the model but is a one-time action.

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
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.
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.
HTTP profile	Enables/disables specific HTTP protection features.
SSL/TLS profile	Enables/disables SSL/TLS anomaly and renegotiation protections. Important for HTTPS servers but can be used by all SPPs.
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.
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.