Distributed Denial of Service (DDoS) attacks have been a prevalent method of disrupting service delivery from web sites and other Internet- based services for a long time.
The basic method employed is to flood servers with so many requests or data packets that they can’t cope, and therefore fail to provide a service to any legitimate users. In recent years, more sophisticated attacks that target specific applications or protocols have also emerged. The attacks often use compromised clients and servers on the internet to generate the requests. Increasingly there are also attacks using hijacked Internet of Things (IoT) devices as many of the current wave of IoT devices have very poor security protection.
DDoS attacks can be targeted at several layers of the network stack. The original kind of attack operated at the infrastructure layer, or layers 2 to 4 in OSI network stack terms. These are the traditional flood the network type of attacks that simply overwhelm the servers providing services. There are several types of infrastructure layer attack that flood the network.
|SYN Flood||SYN Flood Uses the TCP handshake protocol to tie up a receiving server until it times out. Attacker sends a SYN command to initiate a TCP connection. Receiver then sends back an ACK to acknowledge it, but attacker doesn’t send the usual 3rd step to confirm the response. The attacked server waits until the session times out. Many of these prevent real requests being serviced.|
|TCP Reset||Fake TCP reset commands are sent to the server, causing it to drop its TCP connection|
|UDP Storm||UDP does not require a handshake like TCP does. This makes it vulnerable to random UDP based requests. When an attacker sends a UDP request for a service on a random UDP port that doesn’t exist on the attacked server it’ll respond with a destination unreachable response. When many unfulfillable UDP requests are sent, the attacked server gets overwhelmed trying to respond.|
|Reflected DNS||This is an attack that uses spoofed IP addresses in requests sent to DNS servers so that the DNS servers return a large amount of data to the attacked server. The DNS responses are reflected to the attacked server rather than the initiator of the request. The same attack type works for time servers on the network but using reflected NTP requests rather than DNS. Both types of reflected attack usually use amplification techniques to inflate the data sent to the attacked server. It’s not uncommon to have amplification of message sizes of 70 times or more. This amount of data overwhelms the attacked servers.|
As protection against infrastructure layer DDoS attacks has matured attackers have developed methods that target the upper layers of the network stack. Especially at the application layer, or Layer 7 in OSI terms. Application Layer attacks are harder to defend against than infrastructure layer attacks, but LoadMaster, as an application delivery controller, load balancer, and security tool, is ideally placed from a logical perspective on the network to guard against them. LoadMaster has built in features that are tailored to extend the DDoS protection to the application layer.
|GET flood||In GET flood attacks the published URLs for applications and services on a server are repeatedly requested over and over. This prevents other legitimate requests from being serviced in acceptable timeframes.|
|POST flood||This attack uses a tool developed for the single purpose of targeting web sites. Only the web service is affected by the attack leaving other services running normally. The tool opens multiple connections and holds them open as long as possible by sending partial HTTP requests that never complete. Eventually the web service runs out of connections and is essentially unavailable.|
In addition to the deployment of Kemp LoadMaster as a core part of any DDoS protection, there are other steps that can be taken. All network devices such as firewalls, routers, and intrusion detection systems should be kept up to date with the latest software releases.
Important services should be distributed across multiple servers, with LoadMaster managing connections to them. If possible, the servers should be distributed over more than one network data center. A good option is to put capacity in a cloud service like Azure or AWS, possibly in a hybrid or a pure cloud deployment. Again, with LoadMaster handling requests and distributing load across the servers irrespective of their location.