A denial of service (DoS) occurs when an attacker overwhelms server resources by flooding a target system with anomalous data packets, rendering it unable to service genuine users. A distributed denial of service (DDoS) occurs when an attacker uses a master computer to control a network of compromised systems, otherwise known as a ‘botnet’, which collectively inundates the target system with excessive anomalous data packets.
DDoS attacks vary in nature and intensity. Attacks aimed at saturating the available bandwidth upstream of your service can only be countered by adding more bandwidth. DoS policies can help protect against DDoS attacks that aim to overwhelm your server resources. DoS policy recommendations
The preferred primary defense against any type of SYN flood is the DoS anomaly check for tcp_syn_flood threshold. The threshold value sets an upper limit on the number of new incomplete TCP connections allowed per second. If the number of incomplete connections exceeds the threshold value, and the action is set to Pass, the FortiGate unit will allow the SYN packets that exceed the threshold. If the action is set to Block, the FortiGate unit will block the SYN packets that exceed the threshold, but it will allow SYN packets from clients that send another SYN packet.
The tools attackers use to generate network traffic will not send a second SYN packet when a SYN+ACK response is not received from the server. These tools will not “retry.” Legitimate clients will retry when no response is received, and these retries are allowed even if they exceed the threshold with the action set to Block.
FortiGate units with network acceleration hardware, whether built-in or installed in the form of an add-on module, offer a third action for the tcp_syn_flood threshold. Instead of Block and Pass, you can choose to Proxy the incomplete connections that exceed the threshold value.
When the tcp_syn_flood threshold action is set to f, incomplete TCP connections are allowed as normal as long as the configured threshold is not exceeded. If the threshold is exceeded, the FortiGate unit will intercept incoming SYN packets from clients and respond with a SYN+ACK packet. If the FortiGate unit receives an ACK response as expected, it will “replay” this exchange to the server to establish a communication session between the client and the server, and allow the communication to proceed.
UDP and ICMP packets can also be used for DoS attacks, though they are less common. TCP SYN packets are so effective because the target receives them and maintains a session table entry for each until they time out. Attacks using UDP or ICMP packets do not require the same level of attention from a target, rendering them less effective. The target will usually drop the offending packets immediately, closing the session.
Use the udp_flood and icmp_flood thresholds to defend against these DoS attacks.
A denial of service is the result of an attacker sending an abnormally large amount of network traffic to a target system. Having to deal with the traffic flood slows down or disables the target system so that legitimate users can not use it for the duration of the attack.
Any network traffic the target system receives has to be examined, and then accepted or rejected. TCP, UDP, and ICMP traffic is most commonly used, but a particular type of TCP traffic is the most effective. TCP packets with the SYN flag are the most efficient DoS attack tool because of how communication sessions are started between systems.
Communication sessions between systems start with establishing a TCP/IP connection. This is a simple three step process, sometimes called a “three-way handshake,” initiated by the client attempting to open the connection.
Establishing a TCP/IP connection
The three-way handshake is a simple way for the server and client to each agree to establish a connection and acknowledge the other party expressing its intent. Unfortunately, the three-way handshake can be used to interfere with communication rather than facilitate it.
Defending against DoS
When a client sends a SYN packet to a server, the server creates an entry in its session table to keep track of the connection. The server then sends a SYN+ACK packet expecting an ACK reply and the establishment of a connection.
An attacker intending to disrupt a server with a denial of service (DoS) attack can send a flood of SYN packets and not respond to the SYN+ACK packets the server sends in response. Networks can be slow and packets can get lost so the server will continue to send SYN+ACK packets until it gives up, and removes the failed session from the session table. If an attacker sends enough SYN packets to the server, the session table will fill completely, and further connection attempts will be denied until the incomplete sessions time out. Until this happens, the server is unavailable to service legitimate connection requests.
A single client launches a SYN flood attack
SYN floods are seldom launched from a single address so limiting the number of connection attempts from a single IP address is not usually effective.
With a flood of SYN packets coming from a single attacker, you can limit the number of connection attempts from the source IP address or block the attacker entirely. To prevent this simple defense from working, or to disguise the source of the attack, the attacker may spoof the source address and use a number of IP addresses to give the appearance of a distributed denial of service (DDoS) attack. When the server receives the spoofed SYN packets, the SYN+ACK replies will go to the spoofed source IP addresses which will either be invalid, or the system receiving the reply will not know what to do with it.
A client launches a SYN spoof attack
The most severe form of SYN attack is the distributed SYN flood, one variety of distributed denial of service attack (DDoS). Like the SYN flood, the target receives a flood of SYN packets and the ACK+SYN replies are never answered. The attack is distributed across multiple sources sending SYN packets in a coordinated attack.
Multiple attackers launch a distributed SYN flood
The distributed SYN flood is more difficult to defend against because multiple clients are capable of creating a larger volume of SYN packets than a single client. Even if the server can cope, the volume of traffic may Defending against DoS
overwhelm a point in the network upstream of the targeted server. The only defense against this is more bandwidth to prevent any choke-points.
This section describes in general terms the means by which attackers can attempt to compromise your network using attacks at the network level rather than through application vulnerabilities, and steps you can take to protect it. The goal of an attack can be as complex as gaining access to your network and the privileged information it contains, or as simple as preventing customers from accessing your web server.
Because of popular media, many people are aware of viruses and other malware as a threat against their computers and data, but some of the most costly malicious attack in history have been against networks. A 2016 study found that a single DDoS attack could cast a company over $1.6 million. Depending on the size and type of company the areas of expense can be:
The following topics are included in this section:
Monitoring, in the form of logging, alert email, and SNMP, does not directly protect your network. But monitoring allows you to review the progress of an attack, whether afterwards or while in progress. How the attack unfolds may reveal weaknesses in your preparations. The packet archive and sniffer policy logs can reveal more details about the attack. Depending on the detail in your logs, you may be able to determine the attackers location and identity.
While log information is valuable, you must balance the log information with the resources required to collect and store it.
Protection against attacks is important, but attackers often use vulnerabilities and network tools to gather information about your network to plan an attack. It is often easier to prevent an attacker from learning important details about your network than to defend against an attack designed to exploit your particular network.
Attacks are often tailored to the hardware or operating system of the target, so reconnaissance is often the first step. The IP addresses of the hosts, the open ports, and the operating systems the hosts are running is invaluable information to an attacker. Probing your network can be as simple as an attacker performing an Blocking external probes address sweep or port scan to a more involved operation like sending TCP packets with invalid combinations of flags to see how your firewall reacts.
An address sweep is a basic network scanning technique to determine which addresses in an address range have active hosts. A typical address sweep involves sending an ICMP ECHO request (a ping) to each address in an address range to attempt to get a response. A response signifies that there is a host at this address that responded to the ping. It then becomes a target for more detailed and potentially invasive attacks.
Address sweeps do not always reveal all the hosts in an address range because some systems may be configured to ignore ECHO requests and not respond, and some firewalls and gateways may be configured to prevent ECHO requests from being transmitted to the destination network. Despite this shortcoming, Address sweeps are still used because they are simple to perform with software tools that automate the process.
Use the icmp_sweep anomaly in a DoS policy to protect against address sweeps.
There are a number of IPS signatures to detect the use of ICMP probes that can gather information about your network. These signatures include AddressMask, Traceroute, ICMP.Invalid.Packet.Size, and ICMP.Oversized.Packet. Include ICMP protocol signatures in your IPS sensors to protect against these probes/attacks.
Potential attackers may run a port scan on one or more of your hosts. This involves trying to establish a communication session to each port on a host. If the connection is successful, a service may be available that the attacker can exploit.
Use the DoS anomaly check for tcp_port_scan to limit the number of sessions (complete and incomplete) from a single source IP address to the configured threshold. If the number of sessions exceed the threshold, the configured action is taken.
Use the DoS anomaly check for udp_scan to limit UDP sessions in the same way.
Every TCP packet has space reserved for eight flags or control bits. They are used for communicating various control messages. Although space in the packet is reserved for all eight, there are various combinations of flags that should never happen in normal network operation. For example, the SYN flag, used to initiate a session, and the FIN flag, used to end a session, should never be set in the same packet.
Attackers may create packets with these invalid combinations to test how a host will react. Various operating systems and hardware react in different ways, giving a potential attackers clues about the components of your network.
The IPS signature TCP.Bad.Flags detects these invalid combinations. The default action is pass though you can override the default and set it to Block in your IPS sensor.
The anti-replay CLI command allows you to set the level of checking for packet replay and TCP sequence checking (or TCP Sequence (SEQ) number checking). All TCP packets contain a Sequence Number (SEQ) and an Blocking external probes
Acknowledgement Number (ACK). The TCP protocol uses these numbers for error free end-to-end communications. TCP sequence checking can also be used to validate individual packets.
FortiGate units use TCP sequence checking to make sure that a packet is part of a TCP session. By default, if a packet is received with sequence numbers that fall out of the expected range, the FortiGate unit drops the packet. This is normally a desired behavior, since it means that the packet is invalid. But in some cases you may want to configure different levels of anti-replay checking if some of your network equipment uses non-RFC methods when sending packets.
Configure the anti-replay CLI command:
config system global set anti-replay {disable | loose | strict}
end
You can set anti-replay protection to the following settings:
If any packet fails a check it is dropped.
Enable ICMP error message verification to ensure an attacker can not send an invalid ICMP error message.
config system global check-reset-range {disable | strict}
end
If the FortiGate unit receives an ICMP error packet that contains an embedded IP(A,B) | TCP(C,D) header, then if FortiOS can locate the A:C->B:D session it checks to make sure that the sequence number in the TCP header is within the range recorded in the session. If the sequence number is not in range then the ICMP packet is dropped. Strict checking also affects how the anti-replay option checks packets.
Select the level of checking performed on protocol headers.
config system global check-protocol-header {loose | strict}
end
Blocking external probes
If the packet fails header checking it is dropped by the FortiGate unit.
Attackers employ a wide range of tactics to try to disguise their techniques. If an attacker disguises a known attack in such a way that it is not recognized, the attack will evade your security and possibly succeed. FortiGate security recognizes a wide variety of evasion techniques and normalizes data traffic before inspecting it.
Information sent across local networks and the Internet is encapsulated in packets. There is a maximum allowable size for packets and this maximum size varies depending on network configuration and equipment limitations. If a packet arrives at a switch or gateway and it is too large, the data it carries is divided among two or more smaller packets before being forwarded. This is called fragmentation.
When fragmented packets arrive at their destination, they are reassembled and read. If the fragments do not arrive together, they must be held until all of the fragments arrive. Reassembly of a packet requires all of the fragments.
The FortiGate unit automatically reassembles fragmented packets before processing them because fragmented packets can evade security measures. This reassembly of packets affects TCP, UDP and IP packets. There can be some variation though in what process does the reassembling. The IPS engine, nTurbo and the kernel all can do defragmentation.
For example, you have configured the FortiGate unit to block access to the example.org web site. Any checks for example.com will fail if a fragmented packet arrives and one fragment contains http://www.exa while the other contains mple.com/. Viruses and malware can be fragmented and avoid detection in the same way. The FortiGate unit will reassemble fragmented packets before examining network data to ensure that inadvertent or deliberate packet fragmentation does not hide threats in network traffic.
Most traffic is sent on a standard port based on the traffic type. The FortiGate unit recognizes most traffic by packet content rather than the TCP/UDP port and uses the proper IPS signatures to examine it. Protocols recognized regardless of port include DHCP, DNP3, FTP, HTTP, IMAP, MS RPC, NNTP, POP3, RSTP, SIP, SMTP, and SSL, as well as the supported IM/P2P application protocols.
In this way, the FortiGate unit will recognize HTTP traffic being sent on port 25 as HTTP rather than SMTP, for example. Because the protocol is correctly identified, the FortiGate unit will examine the traffic for any enabled HTTP signatures.
Telnet and FTP servers and clients support the use of negotiation information to allow the server to report what features it supports. This information has been used to exploit vulnerable servers. To avoid this problem, the FortiGate unit removes negotiation codes before IPS inspection.
Attackers encode HTML links using various formats to evade detection and bypass security measures. For example, the URL www.example.com/cgi.bin could be encoded in a number of ways to avoid detection but still Blocking external probes
work properly, and be interpreted the same, in a web browser.
The FortiGate prevents the obfuscation by converting the URL to ASCII before inspection.
HTTP URL obfuscation types
| Encoding type | Example |
| No encoding | http://www.example.com/cgi.bin/ |
| Decimal encoding | http://www.example.com/cg& #105;.bin/ |
| URL encoding | http://www.example.com/%43%47%49 %2E%42%49%4E%2F |
| ANSI encoding | http://www.example.com/%u0063%u0067% u0069%u002E%u0062%u0069%u006E/ |
| Directory traversal | http://www.example.com/cgi.bin/test/../ |
The headers of HTTP requests or responses can be modified to make the discovery of patterns and attacks more difficult. To prevent this, the FortiGate unit will:
l remove junk header lines l reassemble an HTTP header that’s been folded onto multiple lines l move request parameters to HTTP POST body from the URL
The message is scanned for any enabled HTTP IPS signatures once these problems are corrected.
The body content of HTTP traffic can be hidden in an attempt to circumvent security scanning. HTTP content can be GZipped or deflated to prevent security inspection. The FortiGate unit will uncompress the traffic before inspecting it.
Another way to hide the contents of HTTP traffic is to send the HTTP body in small pieces, splitting signature matches across two separate pieces of the HTTP body. The FortiGate unit reassembles these ‘chunked bodies’ before inspection.
Because of its complexity, the Microsoft Remote Procedure Call protocol suite is subject to a number of known evasion techniques, including:
l SMB-level fragmentation l DCERPC-level fragmentation l DCERPC multi-part fragmentation l DCERPC UDP fragmentation l Multiple DCERPC fragments in one packet
The FortiGate unit reassembles the fragments into their original form before inspection.
When you enable logging on a security policy, the FortiGate unit records the scanning process activity that occurs, as well as whether the FortiGate unit allowed or denied the traffic according to the rules stated in the security policy. This information can provide insight into whether a security policy is working properly, as well as if there needs to be any modifications to the security policy, such as adding traffic shaping for better traffic performance.
Depending on what the FortiGate unit has in the way of resources, there may be advantages in optimizing the amount of logging taking places. This is why in each policy you are given 3 options for the logging:
If you enable Log Allowed Traffic, the following two options are available:
Depending on the model, if the Log all Sessions option is selected there may be 2 additional options. These options are normally available in the GUI on the higher end models such as the FortiGate 600C or larger.
You can also use the CLI to enter the following command to write a log message when a session starts:
config firewall policy edit <policy-index> set logtraffic-start
end
Traffic is logged in the traffic log file and provides detailed information that you may not think you need, but do. For example, the traffic log can have information about an application used (web: HTTP.Image), and whether or not the packet was SNAT or DNAT translated. The following is an example of a traffic log message.
2011-04-13 05:23:47 log_id=4 type=traffic subtype=other pri=notice vd=root status=”start” src=”10.41.101.20″ srcname=”10.41.101.20″ src_port=58115 dst=”172.20.120.100″ dstname=”172.20.120.100″ dst_country=”N/A” dst_port=137 tran_ip=”N/A” tran_port=0 tran_sip=”10.31.101.41″ tran_sport=58115 service=”137/udp” proto=17 app_type=”N/A” duration=0 rule=1 policyid=1 sent=0 rcvd=0 shaper_drop_sent=0 shaper_drop_rcvd=0 perip_drop=0 src_int=”internal” dst_int=”wan1″ SN=97404 app=”N/A” app_cat=”N/A” carrier_ep=”N/A”
If you want to know more about logging, see the Logging and Reporting chapter in the FortiOS Handbook. If you want to know more about traffic log messages, see the FortiGate Log Message Reference.
Endpoint security enforces the use of the FortiClient End Point Security (FortiClient and FortiClient Lite) application on your network. It can also allow or deny endpoints access to the network based on the application installed on them.
By applying endpoint security to a security policy, you can enforce this type of security on your network. FortiClient enforcement can check that the endpoint is running the most recent version of the FortiClient application, that the antivirus signatures are up-to-date, and that the firewall is enabled. An endpoint is usually often a single PC with a single IP address being used to access network services through a FortiGate unit.
With endpoint security enabled on a policy, traffic that attempts to pass through, the FortiGate unit runs compliance checks on the originating host on the source interface. Non-compliant endpoints are blocked. If someone is browsing the web, the endpoints are redirected to a web portal which explains the non-compliance and provides a link to download the FortiClient application installer. The web portal is already installed on the FortiGate unit, as a replacement message, which you can modify if required.
Endpoint Security requires that all hosts using the security policy have the FortiClient Endpoint Security agent installed. Currently, FortiClient Endpoint Security is available for Microsoft Windows 2000 and later only.
For more information about endpoint security, see the Security Profiles chapter in the FortiOS Handbook.
So if you are running a 7060E chassis in your enterprise and you are suddenly experiencing strange behavior relating to session based traffic, disable the TCP-Options setting in config global. This is on by default and enables the the client and server to negotiate MSS, window scaling, selective acknowledgements, timestamps, and NOP. These are completely option settings that specifically help the packet along and improve performance.
If any device on your network suffers an issue though and the packets start showing up differently, this becomes an issue and can cause intermittent network connectivity issues and any traffic that is session based (non UDP) will randomly drop and experience extreme latency.
I will do a video once I finish assessing the Root Cause Analysis on the issue that I just experienced at an enterprise client.