Application/configuration specific attacks: These use design or implementation weaknesses (bugs) in applications, network layers, and other components to deny service. Examples include:
- Using an exploit in the remote console (rcon) service of a game server to crash the server.
- Causing a machine to reboot by exploiting a weakness in an OS service, such as the Windows "server" service.
- Sending specially-crafted traffic at a service that takes advantage of the fact that responding to the traffic will take significant resources, and that the service is not designed properly to limit this. For instance, with SYN packets that overwhelm a TCP stack, or with more server information queries than a game server can effectively respond to.
Flooding attacks generally involve overwhelming network capacity through high throughput rates or high packet rates. If the endpoint has a 10 GE (10000 Mbps) line, for instance, flooding it with 20000 Mbps of traffic will cause heavy packet loss and result in a denial of service. Similarly, if the endpoint machine has a slower network card and can't handle the incoming traffic, it could experience a problem, even if the network itself does not.
Flood attacks can be further split up into these main subcategories:
Direct spoofed attacks: An attacker may lease a dedicated server or VPS from a third-party, less-than-reputable host that allows for the attacker to send spoofed traffic, which pretends to be from an IP address that is not actually under the attacker's control. Such traffic can be more difficult to block than traffic that is not spoofed because the true source can't be identified.
Reflected attacks: These harness third party servers by spoofing (pretending to be) the target IP address when sending a request to another third party service, which then responds back to the target, usually with a much larger (amplified) answer. This type of attack can be particularly large, to the degree that such attacks sometimes even overload backbone connections inside major upstreams. Reflected attacks are discussed in more depth in this KB article.
Direct attacks through compromised devices: The attacker might use known exploits or simply brute-force passwords to obtain access to internet-connected devices -- webhosts, routers, switches, and so on. The attacker then installs a "bot" and turns the device into a "zombie" which responds to his remote commands to generate and send attack traffic directly to the victim. The resulting "botnets" can sometimes generate tens of gigabytes of attack traffic, which might take many different forms. For instance, we might see:
- An ICMP (ping) flood
- A UDP flood against a game server's standard playing port
- A TCP flood against a game server's rcon port
- Fragmented UDP or TCP packets
- A general UDP or TCP attack against a random port or ports
- Small application-specific attacks. Some specially-crafted attacks are small enough that our mitigation system doesn't see them, or they can't be told from regular traffic using standard methods, such that they can't be effectively detected and filtered. In this case, a customer can contact us to have us work with him or her to investigate and explore possible software solutions. Customers with VDSes can use a powerful "Firewall" page in our control panel to test and apply their own filters, including by applying string-based rules, rate limits, whitelists and blacklists.
- Small-to-large attacks that cause a noticeable spike in bandwidth usage but do not exceed our connection capacity. This type of detectable attack is most common. Some of the simplest types of attacks in this category are blocked globally via permanent filters (chargen reflection, for instance). For others, we have specialized automatic mitigation software and hardware that continuously monitor our network; these systems will see the attack and kick in to mitigate most known attack vectors, posting an event to the target customer's control panel at the same time. If an attack isn't automatically detected, we can investigate it manually at a customer's request and either add its properties to the database of known vectors, or tailor a custom firewall rule to try to block it based on the properties of the packets -- the filter might block UDP traffic from a certain port, for instance, or containing a certain string.
- Extremely large attacks that exceed our connection capacity, our router's forwarding capacity, or disrupt an upstream's network. These are relatively rare, since we have large connections to our providers and they have filters that cut down many types of large attacks before they reach us. When an attack reaches this level, it causes problems for all customers at the location and no amount of filtering on our end can prevent that; it has to be blocked upstream. Our automatic monitoring systems null-route the target IP and notify us immediately so that we can take further steps, such as adjusting routing or implementing an upstream ACL. We talk a little more about particularly large attacks in another KB article.
For more background on DoS attacks, Wikipedia also has a decent treatment here: http://en.wikipedia.org/wiki/Denial-of-service_attack