Table of Contents
- DDoS / DoS Terminology
- Where’s the DoS / DDoS concern stemming from? The media mostly.
- What’s a probable DoS or DDoS Attack?
- It’s all about the OSI Model Baby
- Network vs Application
- What are the types of DoS Attacks that I should worry about?
- How can you protect your site from DoR resource attacks?
Content Error or Suggest an Edit
This article was spawned out of a question asked on Facebook!
The term DDoS really spans so many different areas that it can encapsulate pretty much anything.
You’re really trying to protect yourself from a denial of service, which can be triggered simply by reloading a page every 5 seconds to increase the load on a server or application, which might slow down said server or application by 5 seconds or even 30 seconds.
The effort of a DoS can also vary, for instance, it might take one request every minute to cause a service to stop functioning. It also might require multiple systems or servers to render a service to stop functioning also known as a distributed denial-of-service attack aka a DDoS.
When you hear about DDoS attacks in the news, it’s mostly at level 3/4 and it entails filling up networking equipment and bandwidth with a ton of traffic. We’re talking from 500Gbps to 3.47Tbps worth of traffic.
These are extremely rare events, we only really care about what’s probable when it comes to security. You may or may not be a target for large DDoS attacks, it really depends on a multitude of variables. Which is outside of this article.
When speaking about the majority of businesses, it’s not uncommon to receive a small DoS attack and rare to receive a DDoS attack directly. It’s possible another customer or your hosting provider is attacked, of which you have no control.
Even then, when there is a network-based DoS attack, a majority of providers have filtering in-place that is automatic and will detect and filter these attacks. Sometimes they’re so small nothing is done, and you might not notice any issues.
So what should you be concerned about when it comes to DoS and DDoS attacks?
A DoS can happen on any part of the OSI Layer. What’s the OSI layer? It’s a model to describe the different layers of a networking stack.
The OSI Model (Open Systems Interconnection Model) is a conceptual framework used to describe the functions of a networking system. The OSI model characterizes computing functions into a universal set of rules and requirements in order to support interoperability between different products and software.
You can be attacked pretty much on all layers of the OSI model. But we’re going to focus on the commonly used layers in DoS / DDoS attacks. The Network, and Application layers, also known as Layer 3, and Layer 7
To quote Cloudflare.
Layer 3 DDoS attacks target layer 3 (L3) in the OSI model. Like all DDoS attacks, the goal of a layer 3 attack is to slow down or crash a program, service, computer, or network, or to fill up capacity so that no one else can receive service. L3 DDoS attacks typically accomplish this by targeting network equipment and infrastructure.How do layer 3 DDoS attacks work? | L3 DDoS
This is where DDoS attacks are most common, as the goal is to fill up capacity. To do so you need quite a few attackers.
I’m going to be lazy and quote Cloudflare again.
Application layer attacks or layer 7 (L7) DDoS attacks refer to a type of malicious behavior designed to target the “top” layer in the OSI model where common internet requests such as HTTP GET and HTTP POST occur. These layer 7 attacks, in contrast to network layer attacks such as DNS Amplification, are particularly effective due to their consumption of server resources in addition to network resources.What is an Application Layer DDoS attack?
As pointed out by Cloudflare, you can actually commit a Layer 3 and Layer 7 DDoS attack at the same time. But again, less common and requires more resources by the attacker. When an attacker decides to attack, it’s an investment and so it needs to net a profit or complete a goal. The profit is someone paying to have a service taken down for a specific amount of time, the goal is to disrupt service and cause some sort of loss or hide another attack.
Typically a DDoS attack will use nodes and those devices are either a part of a botnet due to being hacked and infected with malware, or a device that is acting incorrectly. During the time these devices are being used to contribute to a DDoS attack, they can drop off due to being detected by the owner as infected with malware or their configuration changed so they can no longer be used in a DDoS attack unknowingly.
The term DDoS is used frequently as these attacks usually will net the most damage and take businesses offline long enough to cause financial damage or media coverage.
However, DoS attacks aren’t used as frequently due to the fact that they’re simply annoyances that can be addressed rather easily and the damage is minimal.
Layer 4 attacks are still easily completed by a single actor with a single device. But they’re easily mitigated by not only Cloudflare but also with any operating systems firewall such as Linux’s iptable’s.
The most common attack is a syn flood attack. Going back to Cloudflare’s own site.
A SYN flood (half-open attack) is a type of denial-of-service (DDoS) attack which aims to make a server unavailable to legitimate traffic by consuming all available server resources. By repeatedly sending initial connection request (SYN) packets, the attacker is able to overwhelm all available ports on a targeted server machine, causing the targeted device to respond to legitimate traffic sluggishly or not at all.What is a SYN flood attack?
I will say, this attack does crop up from time to time, but it’s easy to mitigate.
There are many, and they can be mitigated quite easily. A major of the attacks are aimed at slowing down Layer 7 which is the application layer.
You might think, WordPress is Layer 7 and you’re correct. But a server’s webserver Nginx/Apache/Litespeed and PHP also fall under Layer 7. They can all be attacked and result in a denial of service.
A DoR attack is a term I’ve just coined, feel free to use it. Whenever a request causes a spike in resources, but not enough to cause a denial of service attack. Why is this considered an attack? The requests and traffic are not legitimate and are increasing resources which can relate directly to slowing down requests or requiring more resources to deliver a specific service level.
The greatest example is the xmlrpc.php attack, which is a brute force attack. This attack not only can result in a brute force login attack to steal weak credentials, but it can also use up your service’s resources and cause a slow down of your sites.
Another example is a resource attack, similar to xmlrpc.php but instead, the attacker will visit multiple pages that trigger PHP to run.
A common choice is to visit pages that don’t exist. This triggers the WordPress loop and causes PHP to execute and run. If done on enough sites this can cause an unexpected load on the server. This can also be done with the WordPress search function, triggering multiple random searches.
Sometimes search crawlers can end up sending 100’s of connections to your site. Some common crawlers are Google, Bing or Semrush. You can block these user agents or IP’s using your webserver or Cloudflare.
As mentioned above, these can cause slowdowns on your server to the point of no requests being served a response. You can mitigate these using Cloudflare or configuring iptables to limit requests.
There are some simple changes you can make to ensure that you’re protecting from DoR attacks.
- Block xmlrpc.php
- Throttle any PHP resource heavy requests or enable caching for these resources.
- Enable Bot Fight mode in Cloudflare or your WAF
- Enable Rate Limiting in Cloudflare or your WAF
You might not have heard of Cloudflare rate limiting, but it will allow you to limit how often a client requests data from your site. This is a great idea in practice, but just make sure to exclude your /wp-admin URL’s as you might find you’re being blocked when trying to open 5 products in new tabs so you can edit them.
- 03/17/2022 corrected xml-rpc.php to xmlrpc.php as per Scott 🙂
- 03/18/2022 Updated grammar by Thomas from wewatchyourwebsite.com