In a Denial of Service (DoS) or Distributed Denial of Service (DDos) attack, malicious actors forcefully eat up resources on a victim network service to the point that access to the service becomes impossible. Motivations for DoS attacks range from political, to criminal, to just shouts for attention. For instance, the political hacktivist group Anonymous took down the car maker Nissan’s global websites in protest to Japanese whaling. Criminals also leverage them to hide or distract from network intrusion, as described by Kaspersky in a DDoS report last year. Other times, attention seeking groups like Lizard Squad launch them for the “lulz”, like in their 2014 Christmas Day DDoS attack against the Xbox Live and PlayStation Network gaming services.
Attackers most commonly carry out DoS attacks on the network and transport layers via SYN Floods. If you are unfamiliar with the TCP handshake process, this short article by InetDaemon is an excellent primer. During a SYN Flood, the attacker sends TCP SYN messages to open connections on the victim server without sending any ACK messages to confirm the connection. This ties up server resources until no new connections can be made, thus denying further access. In a distributed (DDoS) attack, the source of the malicious traffic is spread out across multiple clients, allowing attackers to use proportionately fewer resources on each client compared to those used on the victim server.
You can mitigate network layer DoS attacks by using network firewalls to recognize and throttle flood attacks. We pre-configure our WatchGuard Firebox Default Packet Handling rules to block sources that attempt flood attacks and throttle traffic in the event of a DDoS attack against the protected network.
Attackers continue to change their methods as protection against network layer DoS attacks improve. One increasingly common trick is a shift to application layer attacks. In an application layer DoS attack, malicious clients send traffic either to a listening UDP socket or through a completed TCP connection, using up both network bandwidth and resources on the victim network service. A common form of application layer DoS is a reflective DNS amplification attack. During a reflective DNS amplification attack, a malicious client sends a DNS query to an open DNS resolver with a spoofed source IP matching the victim server. The DNS resolver then sends (reflects) a response, often several times larger than the query, to the victim server due to the spoofed address. This type of attack is distributed across multiple clients using multiple DNS resolvers to increase the amount of bandwidth used up by the responses sent to the server.
In a blog post last week, Imperva described another type of application layer DDoS attack that one of their clients experienced. In this attack, a botnet infected with a variant of the Nitol malware randomly generated large files and then uploaded them to the victim server via HTTP POST requests. By using the application layer, the malicious traffic was only identified after the TCP handshake completed. This meant that the victim service already received the bandwidth hogging application traffic through the network before it was identified as malicious. Furthermore, the attack forced the victim service to waste processing resources on handling the ultimately bad traffic.
Protecting against an application layer DoS attack is much more difficult than protecting against a network layer DoS attack. You can easily mitigate Network layer attacks upstream from your network perimeter using flood detection. However, since an application layer attack goes so far as to complete a TCP connection first, it’s typically allowed to reach your perimeter before it’s identified as malicious. Usually mitigation comes down to simply having a larger network pipe than the attacker can fill.
At the network perimeter, you can use a stateful firewall to at least prevent reflected traffic from entering your network. A stateful firewall keeps record of sessions from clients on your network. If a response to a spoofed packet comes in, it will not match any record in the stateful firewall’s session table, so the firewall drops the packet. While this kind of protections stops malicious packets from entering your protected network, it doesn’t prevent the data from using up your external network bandwidth. For the best protection, Internet Service Providers need to adopt BCP 38 which describes filtering spoofed traffic before it even enters the internet backbone (which is another function firewalls like WatchGuard’s Fireboxes provide). — Marc Laliberte
Reference Section:
- Anonymous takes down Nissan’s website – IB Times
- Kaspersky special report on DDoS – Kaspersky
- Lizard Squad ruins Christmas – Ars Technica
- POST flood DDoS attack trouble – Imperva
- Network Ingress Filtering BCP 38 Document – IETF
Leave a Reply