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.
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 des- tination 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_ses– sion
If the number of concurrent ICMP connections from one source IP address exceeds the configured threshold value, the action is executed.
300 concurrent sessions
Anomaly Name Description Recommended Threshold
icmp_dst_ses– sion
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 des- tination IP address exceeds the configured threshold value, the action is executed.
2000 packets per second
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.
- continuous – blocks any packets that match the anomaly criteria once the threshold has been reached
- periodical – allows matching anomalous traffic up to the rate set by the threshold. 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.
One–Arm IDS
Interface-based policy only defines what and how IPS functions are applied to the packets transmitted by the interface. It works no matter if the port is used in a forwarding path or used as an One-Arm device.
To enable One-Arm IDS, the user should first enable sniff-mode on the interface,
config system interface edit port2
set ips-sniffer-mode enable next
end
Once sniff-mode is turned on, both incoming and outgoing packets will be dropped after IPS inspections. The port can be connected to a hub or a switch’s SPAN port. Any packet picked up by the interface will still follow the interface policy so different IPS and DoS anomaly checks can be applied.
IPv6 IPS
IPv6 IPS signature scan can be enabled by interface policy. The user can create an normal IPS sensor and assign it to the IPv6 interface policy.
config firewall interface-policy6 edit 1
set interface “port1” set srcaddr6 “all”
set dstaddr6 “all” set service6 “ANY”
set ips-sensor-status enable set ips-sensor “all_default”
next end
Traffic Destined to the FortiGate unit
IPS enabled in firewall policies can only inspect the traffic pass through FortiGate unit, not the traffic destined to FortiGate unit. Enabling IPS in interface-policy allows IPS to pick up any packet on the interface so it is able to inspect attacks targeting FGT.
Dropped, Flooded, Broadcast, Multicast and L2 packets
In many evaluation or certification tests, FortiGate firewall is often required to log any packets dropped by the firewall. In most of cases, these packets are of invalid headers so firewall just drops them silently. It is natural to forward all these packets to IPS first so FortiGate firewall is able to generate logs for invalid packets.
Flooded, broadcast and multicast traffics do not reach any of services in the forwarding path. They can be inspected by the interface policy as long as they match the addresses defined. Potentially, L2 packets can also be sent to IPS for inspection through interface-policy, but it is not enabled in FortiOS 4.0.
GUI and CLI
Now in FortiGate, there are two places that IPS can be enabled, in a firewall policy and in an interface policy. In the firewall policy implementation, IPS sensor can be configured in both CLI and GUI. When adding an IPS sensor to an interface policy it must be done through the CLI. There is no GUI input window for the “Interface Policy”. There is however, a DoS Policy section in the GUI.
thanks for the great article how do we check the current rate of request and connections