DoS Protection
Denial of Service (DoS) policies are primarily used to apply DoS anomaly checks to network traffic based on the FortiGate interface it is entering as well as the source and destination addresses. DoS checks are a traffic anomaly detection feature to identify network traffic that does not fit known or common traffic patterns and behavior. A common example of anomalous traffic is the denial of service attack. A denial of service occurs when an attacking system starts an abnormally large number of sessions with a target system. The large number of sessions slows down or disables the target system, so that legitimate users can no longer use it.
DoS policies are similar to firewall policies except that instead of defining the way traffic is allowed to flow, they keep track of certain traffic patterns and attributes and will stop traffic displaying those attributes. Further, DoS policies affect only incoming traffic on a single interface. You can further limit a DoS policy by source address, destination address, and service.
DoS configurations have been changed a couple of times in the past. In FortiOS 4.0, DoS protection is moved to the interface policy, so when it is enabled, it is the first thing checked when a packet enters FortiGate. Because of this early detection, DoS policies are a very efficient defense that uses few resources. Denial of service attacks, for example, are detected and its packets dropped before requiring security policy look-ups, antivirus scans, and other protective but resource-intensive operations.
A DoS policy examines network traffic arriving at an interface for anomalous patterns usually indicating an attack. This does not mean that all anomalies experience by the firewall are the result of an intentional attack.
Because an improperly configured DoS anomaly check can interfere with network traffic, no DoS checks are preconfigured on a factory default FortiGate unit. You must create your own before they will take effect. Thresholds for newly created sensors are preset with recommended values that you can adjust to meet the needs of your network.
To create a Denial of Service policy determine if it needs to be an IPv4 or IPv6 policy, then go to:
Policy & Objects > IPv4 DoS Policy for IPv4.
Policy & Objects > IPv6 DoS Policy for IPv6.
The Enable SSH Deep Scan feature is enabled by default when creating a new
SSL/SSH Inspection profile. There are situations were this feature can cause issues so be sure that you would like it enabled before applying it.
DoS Protection
Settings used in configuring DoS
Incoming Interface
The interface to which this security policy applies. It will be the that the traffic is coming into the firewall on.
Source Address
This will be the address that the traffic is coming from and must be a address listed in the Address section of the Firewall Objects. This can include the predefined “all” address which covers any address coming in on any interface. Multiple addresses or address groups can be chosen
Destination Address
This will be the address that the traffic is addressed to. In this case it must be an address that is associated with the firewall itself. For instance it could be one of the interface address of the firewall, a secondary IP address or the interface address assigned to a Virtual IP address. Just like with the Source Address this address must be already configured before being used in the DoS policy. Multiple addresses, virtual IPs or virtual IP groups can be chosen.
Service
While the Service field allows for the use of the ALL service some administrators prefer to optimize the resources of the firewall and only check on the services that will be answered on an interface. Multiple services or service groups can be chosen.
Anomalies
The anomalies can not be configured by the user. They are predefined sensors set up for specific patterns of anomalous traffic
The anomalies that have been predefined for use in the DoS Policies are:
| Anomaly Name | Description | Recommended Threshold |
| tcp_syn_flood | If the SYN packet rate of new TCP connections, including retransmission, to one destination IP address exceeds the configured threshold value, the action is executed. | 2000 packets per second. |
| tcp_port_scan | If the SYN packet rate of new TCP connections, including retransmission, from one source IP address exceeds the configured threshold value, the action is executed. | 1000 packets per second. |
| tcp_src_session | If the number of concurrent TCP connections from one source IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions. |
| Anomaly Name | Description | Recommended Threshold |
| tcp_dst_session | If the number of concurrent TCP connections to one destination IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions. |
| udp_flood | If the UDP traffic to one destination IP address exceeds the configured threshold value, the action is executed. | 2000 packets per second. |
| udp_scan | If the number of UDP sessions originating from one source IP address exceeds the configured threshold value, the action is executed. | 2000 packets per second. |
| udp_src_session | If the number of concurrent UDP connections from one source IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions. |
| udp_dst_session | If the number of concurrent UDP connections to one destination IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions. |
| icmp_flood | If the number of ICMP packets sent to one destination IP address exceeds the configured threshold value, the action is executed. | 250 packets per second. |
| icmp_sweep | If the number of ICMP packets originating from one source IP address exceeds the configured threshold value, the action is executed. | 100 packets per second. |
| icmp_src_ session | If the number of concurrent ICMP connections from one source IP address exceeds the configured threshold value, the action is executed. | 300 concurrent sessions |
| icmp_dst_ session | If the number of concurrent ICMP connections to one destination IP address exceeds the configured threshold value, the action is executed. | 3000 concurrent sessions |
| ip_src_session | If the number of concurrent IP connections from one source IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions. |
| ip_dst_session | If the number of concurrent IP connections to one destination IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions. |
| sctp_flood | If the number of SCTP packets sent to one destination IP address exceeds the configured threshold value, the action is executed. | 2000 packets per second |
DoS Protection
| Anomaly Name | Description | Recommended Threshold |
| sctp_scan | If the number of SCTP sessions originating from one source IP address exceeds the configured threshold value, the action is executed. | 1000 packets per second |
| sctp_src_session | If the number of concurrent SCTP connections from one source IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions |
| sctp_dst_session | If the number of concurrent SCTP connections to one destination IP address exceeds the configured threshold value, the action is executed. | 5000 concurrent sessions |
Status
The status field is enabled to enable the sensor for the associated anomaly. In terms of actions performed there is no difference between disabling a sensor and having the action as “Pass” but by disabling sensors that are not being used for blocking or logging you can save some resources of the firewall that can be better used elsewhere.
Logging
Regardless of whether the traffic is blocked or passed through the anomalous traffic will be logged.
Pass
Allows the anomalous traffic to pass through unimpeded.
Block
For Thresholds based on the number of concurrent sessions blocking the anomaly will not allow more than the number of concurrent sessions set as the threshold.
For rate based thresholds where the threshold is measured in packets per second, the Action setting “Block” prevents the overwhelming of the firewall by anomalous traffic in one of 2 ways. Setting which of those 2 ways will be issued is determined in the CLI.
l continuous – blocks packets once an anomaly is detected. This overrides individual anomaly settings. l periodical – allows matching anomalous traffic up to the rate set by the threshold.
If the period for a particular anomaly is 60 seconds, such as those where the threshold is measured in concurrent sessions, after the 60 second timer has expired, the number of allowed packets that match the anomaly criteria is reset to zero. This means that if you allow 10 sessions through before blocking, after the 60 seconds is up, another 10 will be allowed. The attrition of sessions from expiration should keep the allowed sessions from reaching the maximum.
To set the type of block action for the rate based anomaly sensors:
config ips global set anomaly-mode continuous set anomaly-mode periodical end
Threshold
The threshold can be either in terms of concurrent session or in packets per second depending on which sensor is being referred to.