A DoS (Denial of Service) attack involves denying access to a computer resource. There are many ways to do this, but the two basic types are:

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.

More general traffic flood attacks: These aim to simply exhaust resources on a target machine or network. Unlike the above type of DoS, simply reconfiguring software or using a firewall cannot defend against these; hardware/connection upgrades are needed.

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

There are three sizes of attack traffic that we deal with.

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.

We have put a tremendous amount of time (thousands of hours) and money (hundreds of thousands of dollars) just into dealing with DoS attacks and we continue to fight them as best we can on behalf of our customers. While we do not market our company as a (D)DoS mitigation provider, our systems are actually better than nearly all such specialist hosts.

Usually DDoS attacks on our customers occur following an in-game confrontation between a disruptive player and an admin, leading to a ban. The player, either by using the resources of a large attack network or a DRDoS system, then retaliates by denying service.

Often, an attack will then continue as long as the individual launching the attack is being given further attention.

In order to reduce attacks, we strongly recommend avoiding confrontations with troublemakers. Instead, be polite and direct; if you need to ban them, let them know why in simple terms, then do it. It is important to completely ignore them after this -- if they try to initiate a chat, don't respond, and if they try to post on a forum, delete the post and ban the user there. Ensure that everyone associated with your server ignores them in the same way; if someone refuses to, that person will need to also be banned.

We now have a "Firewall" page for all game servers and VDSes that can be used to examine the traffic hitting an IP and to apply filters. For Linux servers and VDSes, these filters include string-matching and length-based rules, allowing for a powerful way to stop most (D)DoS attacks that are small enough not to overwhelm the 1 Gbps physical network adapter on the machine.

This complements our router-based filters and the automated DDoS mitigation system available at most locations. Our automated DDoS mitigation system catches and filters most of the common attacks.