Difference between revisions of "Ddos attack"

Latest revision as of 19:48, 2 July 2016

A DoS (Denial of Service) attack is an attack that denies a service to a user. There are many types of DoS attacks, but in this article, we will only be looking at the DoS attacks that target a server’s network.

Three Way Handshake and Connect State

Most DoS attacks exploit the three way handshake involved with initiating a TCP Connection. This three way handshake ensures a reliable connection between server and client, and that all traffic sent by one is received by the other. To learn more about the three way handshake, please read the following:

On a lot of servers, there is what's called a Stateful Packet Inspection (SPI for short) firewall. This ensures that unsolicited inbound connections are not established unless the firewall has successfully determined whether or not it's allowed to, and it doesn't match any block rules.

In order to establish state (or a three way handshake for that matter), there is an order in which a connection is established, like so:

Client [SYN] ---------------> Server
Client <----------- [SYN/ACK] Server
Client [ACK] ---------------> Server

When the Client sends the first SYN (Synchronization) packet, it asks the server to negotiate a connection, and open up a bit of memory just for that connection. If the server has memory available, it will send back a SYN/ACK packet back to the client. The Client will then ACK (Acknowledge) the connection reply sent by the Server, establishing a three way handshake, which gives the session "state".

TCP Attacks

Synflood

Abuse of the above mentioned three way handshake is more commonly known as a Synflood. A Synflood exploits this by sending a flood of SYN packets to a server, but ignoring the SYN/ACK that come back in response. When this happens, the connection goes into SYN_RCVD state on the server, which is held open until it receives an ACK reply from the Client. If an ACK reply is never received, then it will go into TIME_WAIT state on the server, causing it to be held open even longer. Imagine if a Client sent several hundred (or even thousands) of SYN packets, only to ignore the SYN/ACK reply. Generally, this form of attack targets a particular service to exploit the built in connection limits built into most services. This type of attack will not generally cause a server to go out of memory, but will make the service being targeted, usually Apache, go unresponsive.

Spoofed Synflood

There is a more advanced style of attack known as a Spoofed Synflood, which either randomizes or fakes the Source IP address. This is done so when the Server sends back the SYN/ACK reply, it goes nowhere and is never responded to, keeping that connection held open until it times out. This makes the Source IP address untraceable. Most firewall rulesets prevent any traffic from obviously bogus Reserved Addresses (RFC1918) such as:

• 192.168.0.0/16
• 10.0.0.0/8
• 172.16.0.0/12

This is not the case if the IP has been explicitly allowed in the server's firewall.

Dealing with Synfloods

What some firewalls do to prevent this is rate-limits the amount of new connections (SYN) any 1 IP can create per amount of pre-determined interval. This limits that IP to only creating so much memory allocation on the server to serve that IP's requests. The software firewalls such as CSF and APF can only do so much to limit these attacks. Certain Cisco firewalls can mitigate Synfloods.

Advanced Attacks

These more advanced attacks utilize the advanced features of the TCP stack.

Optimistic ACK Floods

The Optimistic ACK Flood requires that the following be set.

 ECE - ECN-Echo (ECN -> Explicit Congestion Notification)

If this bit is set, this indicates that:

• If the SYN flag is set, that the TCP peer is ECN capable.
• If the SYN flag is clear, that a packet with Congestion Experienced flag in IP header set is received during normal transmission

 CWR - Congestion Window Reduced

• Set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism

 RTT

 Window

• The size of the receive window, which specifies the number of bytes (beyond the sequence number in the ACK field) that the receiver is currently willing to receive

The way this attack works:

Because TCP congestion window growth is a function of RTT, the Client can fake shorter RTTs by ACKing packets it has not received yet, thus forcing the sender to increase the Window. If the sender gets ACKs for packets not sent, it ignores the packet completely. This allowing the receiver to be arbitrarily aggressive, concealing losses and leading the sender to overwhelm the network.

Duplicate ACK Spoofing

The Duplicate ACK Spoofing attack works by doing exactly what it's called, spoofing ACK requests that have already been sent. It works by exploiting the follow:

 SMSS - SENDER MAXIMUM SEGMENT SIZE

This is the size of the largest segment that the sender can transmit.

 Fast Retransmit & Fast Recovery

TCP Slow Start and Congestion Avoidance lower the data throughput drastically when segment loss is detected. Fast Retransmit and Fast Recovery have been designed to speed up the recovery of the connection, without compromising its congestion avoidance characteristics. Fast Retransmit and Recovery detect a segment loss via duplicate acknowledgements. When a segment is lost, TCP at the receiver will keep sending ack segments indicating the next expected sequence number. This sequence number would correspond to the lost segment. If only one segment is lost, TCP will keep generating acks for the following segments. This will result in the transmitter getting duplicate acks (i.e. acks with the same ack sequence number).

The way this attack works:

This allows TCP Windows to be incremented by SMSS whenever the receiver receives duplicate ACKs (sender enters fast recovery), artificially inflating Window. The sender cannot distinguish valid from spoofed ACKs.

UDP Attacks

UDP attacks are quite effective, as UDP is a state-less protocol. UDP just sends the traffic without the initial overhead of the three way handshake in TCP. In addition to no initial overhead, UDP also has no verification that the packet was received. Normally, when you send a UDP packet with the "DNS Query" bit set to port 53 of a nameserver, it will reply with DNS results if the nameserver is active. However, if you send a UDP packet to a port that doesn't have a service listening on it, the remote host will send back an ICMP Destination Unreachable packet. It does this for EACH and EVERY UDP packet sent. As floods go, you can imagine sending a whole bunch of UDP packets would generate quite lot of return traffic, now that you don't need state.

Note that a UDP flood does not have to target DNS, although DNS is the common target of such attacks. UDP floods can also be used to saturate a server's network connection.

The Source IP on the UDP packets are often spoofed. Now that ICMP Destination Unreachable packet is going to go wherever you set the Source IP to. If the source IP on the packets are spoofed to be the localhost (127.0.0.1) or the network's broadcast ip (the IP in the range ending in .255), this would cause the effects of the attack to be doubled.

Dealing with UDP floods

Proper firewalls are configured to DROP (not send ICMP Destination Unreachable) unsolicited UDP packets to ports not explicitly open, so this doesn't happen.

ICMP Attacks

ICMP based attacks use the ICMP packets more commonly associated with Ping requests. Most networks have technology in place to prevent these sorts of attacks.

ICMP Smurf

This is where an attacker sends forged ICMP echo (PING) packets to vulnerable networks' broadcast address (.255). All the systems on those networks send ICMP-echo-replies to the victim, consuming the target system's available bandwidth and creating a denial of service (DoS) to legitimate traffic.

ICMP Redirect

This is where an attacker uses either the ICMP "Time exceeded" or "Destination unreachable" messages. Both of these ICMP messages can cause a host to immediately drop a connection. An attacker can make use of this by simply forging one of these ICMP messages, and sending it to one or both of the communicating hosts. Their connection will then be broken. The ICMP "Redirect" message is commonly used by gateways when a host has mistakenly assumed the destination is not on the local network. If an attacker forges an ICMP "Redirect" message, it can cause another host to send packets for certain connections through the attacker's host.