Current FortiDDoS-F documentation organizes DDoS mitigation around Service Protection Policies (SPPs), protected subnets, traffic learning, system-recommended thresholds, and per-layer mitigation behavior. The important design principle is that a DDoS policy should reflect the normal traffic profile of the service it protects. Factory defaults or emergency thresholds can keep a device running during setup, but current Fortinet guidance emphasizes learning real traffic and generating system recommendations before long-term prevention mode.
Within Fortinet Security Operations, FortiDDoS policy is less about one global “block floods” rule and more about defining service boundaries whose Layer 3, Layer 4, and Layer 7 traffic can be baselined independently.
The existing early signs of a DDoS attack article provides the general detection context. FortiDDoS turns those rate and protocol anomalies into learned, enforceable thresholds.
Start with Service Protection Policies
An SPP defines the protected subnets and the traffic counters/thresholds FortiDDoS uses for that protected service group.
Services with very different traffic behavior should usually live in different SPPs so one busy application does not set a permissive baseline for another.
Group by similar traffic characteristics, business function, and expected attack/response behavior rather than only by convenient subnet boundaries.
Learn before enforcing
Current FortiDDoS-F guidance recommends allowing traffic to run long enough to create representative traffic statistics before adopting system-recommended thresholds.
The current handbook specifically advises at least about a week for initial learning in normal deployments.
Include weekday/weekend, backup, batch, maintenance, marketing events, and known peak periods so recommendations do not treat normal business bursts as attacks.
System-recommended thresholds should be the default starting point
FortiDDoS calculates large numbers of thresholds across protocol layers and directions from observed traffic statistics.
Fortinet recommends relying on this system intelligence in most cases and changing values manually only when administrators understand the affected packet rates and protocol behavior.
Export or record current threshold settings before large changes so the team can compare or roll back after tuning.
Thresholds exist at several levels
FortiDDoS monitors aggregate SPP traffic as well as per-destination, per-source, port, protocol, and other Layer 3/4/7 dimensions.
A SYN flood to one VIP, a UDP source-port reflection pattern, and an application-layer flood can require different controls even when total bandwidth is similar.
Review the relevant threshold family instead of raising the entire SPP limit because one legitimate workload caused an alert.
Detection mode is useful during threshold change
When changing system recommendations or tuning aggressive thresholds, use detection/monitoring behavior where supported to observe what would be mitigated before enforcing broadly.
Older Fortinet guidance explicitly recommends returning an SPP to detection while changing recommendations, then restoring prevention after logs show no unexpected drops.
Production change windows should include application owners because DDoS false positives can look like ordinary packet loss or connection resets.
Emergency setup should remain temporary
Current FortiDDoS-F documentation describes Emergency Setup as inappropriate for normal long-term mitigation because it is too simple for modern DDoS traffic.
Use emergency settings only when the environment must be protected before sufficient learning is available.
Schedule the full SPP/traffic-statistics/system-recommendation process immediately afterward instead of letting temporary thresholds become permanent configuration.
Manual thresholds require expert justification
FortiDDoS permits manual adjustment of threshold settings.
Use this for known service behavior that learning did not represent correctly—for example an application that never legitimately uses a certain UDP pattern or a protocol with predictable caps.
Document the business reason, old/new value, traffic evidence, owner, and expiry/review trigger so one emergency tweak does not remain unexplained for years.
Outbound mitigation should be intentional
Some system-recommendation behavior can leave outbound thresholds at system maximum depending on platform/release settings.
Organizations that need protection against compromised internal systems participating in outbound DDoS should review outbound SPP policy separately.
Do not assume inbound protection automatically creates a full egress abuse-control policy.
Application owners should validate normal peak traffic
DDoS devices see rates; application owners understand flash crowds, API fanout, software updates, live events, and business seasonality.
Use planned load tests and known peak windows to verify thresholds before large product launches.
DDoS mitigation in cloud environments follows the same principle: mitigation must distinguish business scale from attack scale.
Alerting and mitigation logs should feed incident response
Track which SPP, threshold, source/destination, protocol, and mitigation action activated and whether service health degraded.
Correlate FortiDDoS events with firewall, application, CDN, load balancer, and upstream-provider telemetry.
During an attack, the goal is not merely to know the device is dropping traffic but to verify that legitimate user success remains within service objectives.
FortiDDoS policy succeeds when learned normal behavior becomes a controlled mitigation boundary
The mature deployment separates dissimilar services into SPPs, learns representative traffic, uses system recommendations, validates in detection mode, documents manual exceptions, and monitors both mitigation and application health.
DDoS protection becomes reliable when thresholds reflect the service being defended rather than arbitrary generic packet-rate numbers.
SPP boundaries should be reviewed whenever applications move behind new load balancers, VIPs, CDNs, or shared address pools. If two services with different traffic patterns are collapsed behind the same protected subnet, the learned thresholds may become too permissive for the quieter service. Revisit SPP membership during network/application architecture changes rather than treating initial policy grouping as permanent.
Traffic learning should exclude known abnormal periods when possible. A one-week window that contains a real DDoS attack, stress test, or accidental loop can teach the appliance that malicious rates are normal. Keep a calendar of load tests and incidents, inspect traffic statistics before saving recommendations, and regenerate baselines when the learning period was contaminated by abnormal behavior.
Current FortiDDoS-F guidance describes hundreds of thousands of possible thresholds per SPP and direction. This is precisely why manual tuning should be exceptional. Human operators cannot realistically hand-maintain every L3/L4/L7 parameter. Use the platform’s statistical recommendations for broad coverage and reserve manual thresholds for a small set of well-understood service behaviors.
Threshold percent adjustment and low-traffic floors should be treated as global sensitivity knobs within the SPP. Small changes can alter many generated thresholds simultaneously. Before lowering them, export current values, switch to a safer observation mode, and compare dropped/flagged traffic by protocol and destination. A 10% change across thousands of parameters can have a much larger effect than one edited scalar threshold.
Mitigation policy should account for source distribution. A volumetric flood from many sources looks different from a high-rate attack from one source, reflected/amplified UDP, SYN floods, or application-layer request floods. Review the threshold family and mitigation mechanism that actually triggered instead of responding to every DDoS event by globally raising bandwidth limits.
Protected-service owners should know how mitigation affects connection state. SYN validation, rate limiting, source tracking, or application-layer controls can change latency and connection behavior during attack conditions. Test representative client traffic through prevention mode under controlled load so application teams understand expected symptoms before a real attack.
Upstream capacity remains part of the architecture. An on-path appliance cannot protect an internet link that saturates before attack traffic reaches it. For very large attacks, coordinate with ISP, cloud/CDN scrubbing, or upstream DDoS services. FortiDDoS policy is most effective when the physical and provider capacity can deliver enough traffic to the appliance for mitigation.
Operational dashboards should show protected-service health alongside attack counters. Measure legitimate request success, latency, server CPU, connection errors, and business transactions while FortiDDoS mitigates. A rule that drops 99% of malicious packets but also blocks 15% of customers is not a successful mitigation outcome.
After every attack, compare learned thresholds, triggered mitigations, false positives, upstream behavior, and application health. Do not immediately raise thresholds because one attack caused prolonged mitigation; that can simply create a larger window for the next attacker. Change thresholds only when post-incident evidence shows normal traffic was incorrectly constrained.
SPP change control should preserve a known-good threshold snapshot. Before major tuning, export threshold/configuration data and record the traffic-statistics period used for recommendations. If a change unexpectedly blocks legitimate traffic, operators should be able to restore the prior policy quickly rather than reconstructing thousands of values manually.
Capacity planning should include asymmetric inbound/outbound service behavior. DNS, APIs, and content services can have response traffic much larger than request traffic, while other protocols behave differently. Review thresholds per direction so normal response amplification is not misclassified as outbound attack traffic.
Business-continuity exercises should include upstream saturation and FortiDDoS bypass/failure modes. Test what happens if one appliance/link fails, if traffic must move through an alternate path, or if mitigation itself becomes overloaded. DDoS resilience depends on network architecture and runbooks as much as threshold quality.
Policy ownership should include both network security and application engineering. Network teams understand packet behavior and mitigation, while application teams know legitimate spikes, client retry patterns, and protocol quirks. Joint review prevents thresholds from being tuned purely for network cleanliness at the expense of customer traffic.
Document one tested rollback per SPP: prior thresholds, operating mode, protected subnets, and expected verification checks. During an attack or false-positive incident, operators should be able to restore the last known-good protection state quickly without disabling DDoS protection entirely.
Mitigation policy should be tested against representative legitimate peaks as well as attacks. Baselines that learn only quiet periods can overreact to real business events, while thresholds that tolerate every burst may delay protection when traffic becomes abusive.
