Network defense
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:
- Changes in credit and insurance ratings l Overtime payment to employees l Hiring new employees in increase IT staff l PR expenses to restore a company’s reputation l Upgrading infrastructure and software l Customer compensation
The following topics are included in this section:
- Monitoring l Blocking external probes l Defending against DoS attacks
Monitoring
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.
Blocking external probes
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.
Address sweeps
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.
Port scans
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.
Probes using IP traffic options
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.
Configure packet replay and TCP sequence checking
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:
- disable — No anti-replay protection.
- loose — Perform packet sequence checking and ICMP anti-replay checking with the following criteria:
- The SYN, FIN, and RST bit can not appear in the same packet.
- The FortiGate unit does not allow more than one ICMP error packet through before it receives a normal TCP or UDP packet.
- If the FortiGate unit receives an RST packet, and check-reset-range is set to strict, the FortiGate unit checks to determine if its sequence number in the RST is within the un-ACKed data and drops the packet if the sequence number is incorrect.
- strict — Performs all of the loose checking but for each new session also checks to determine of the TCP sequence number in a SYN packet has been calculated correctly and started from the correct value for each new session. Strict anti-replay checking can also help prevent SYN flooding.
If any packet fails a check it is dropped.
Configure ICMP error message verification
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
- disable — the FortiGate unit does not validate ICMP error messages.
- strict — enable ICMP error message checking.
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.
Protocol header checking
Select the level of checking performed on protocol headers.
config system global check-protocol-header {loose | strict}
end
- loose — the FortiGate unit performs basic header checking to verify that a packet is part of a session and should be processed. Basic header checking includes verifying that the layer-4 protocol header length, the IP header length, the IP version, the IP checksum, IP options are correct, etc.
Blocking external probes
- strict — the FortiGate unit does the same checking as above plus it verifies that ESP packets have the correct sequence number, SPI, and data length.
If the packet fails header checking it is dropped by the FortiGate unit.
Evasion techniques
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.
Packet fragmentation
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.
Non-standard ports
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.
Negotiation codes
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.
HTTP URL obfuscation
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/../ |
HTTP header obfuscation
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.
HTTP body obfuscation
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.
Microsoft RPC evasion
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.
