Server rentals :: NFOservers.com

A DoS 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 gigE (1000 Mbps) line, for instance, flooding it with 2000 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.

Mostly, when you hear of an attack here at NFO (such as via an "Events log" notice in the control panel), it is in reference to a flood-based attack, and more specifically to a Distributed Denial of Service (DDoS) flood-based attack. The "distributed" part means that we see malicious traffic come from many different sources -- often dozens or hundreds of them. Typically, these sources are compromised end-user machines or websites. Often, the sources are also sending us spoofed traffic, which means that the IP address in each of the packets is forged, and we can't tell the true source.

There are many subtypes of DDoS floods. 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
* A UDP reflection attack coming from the query port of a 3rd party server
* Fragmented UDP or TCP packets
* A general UDP or TCP attack against a random port or ports

When we see a DDoS flood attack, it normally only causes damage to customers other than the target if it surpasses that machine's capacity. If it exceeds the location's capacity, it will also affect other customers at that location. For example, if a location has a 10 GE connection (as most do), the flood has to be larger than 10000 Mbps to affect most customers at that location. When an attack does this, we have monitoring systems that notify us immediately.

Most floods are less than our 10GE and 20GE connections. When they are, we can usually take advantage of the advanced firewall on our routers to block the attack based on the properties of the packets -- the filter might block UDP traffic from a certain port, for instance, or containing a certain string. We have automated systems that help us to do this quickly, and we can also step in manually to look at historical traffic data on the router to find new patterns and attacks.

If a flood is larger than our connection to InterNAP (our upstream provider at all locations), we have to respond by working with the InterNAP NOC to have the attack blocked on their end, so that it can't reach us (if we block it on our side, it continues to flood out our connection). InterNAP can respond in one of two ways:

1. By putting up an Access Control List (ACL) that tries to block the attack specifically, such as by denying access from certain external IPs. This works best if the attack is simple, with an obvious source or other characteristic that allows it to be filtered.

2. By "null routing" the destination IP. With this solution, no traffic at all is allowed to the destination IP on our side (the customer being attacked). Blocking traffic to the IP could also be done with an ACL, but the advantage to a "null route" is that InterNAP's upstreams also block the traffic on their networks, making it especially useful for extremely large attacks. A null route also may be necessary when an attack has multiple or changing vectors.

For attacks that are small enough that we don't immediately see them, and for application-specific attacks, we will do our best to work with the single affected customer (after he or she contacts us with a concern) by attempting to capture traffic to profile the attack and then applying internal and external firewall rules. For VDSes and Linux servers, these can include string-matching rules and length-based rules. We will also suggest other methods to clients for mitigating the attack on their end, when applicable.

The unpredictable nature of DDoS attacks, and risk of blocking legitimate traffic with filters, means that it is not usually possible to block these ahead of time. Instead, it is necessary to react when the attack occurs to take care of it right then. With flooding attacks that overwhelm a location's overall capacity, manual intervention is always required unless the attacker stop it from his/her end. We always respond as quickly as possible whenever we see an obvious DDoS, and we use high-capacity connections at all our locations to ensure that only the largest attacks cause our customers trouble.

Wikipedia also covers DoS attacks fairly decently here: http://en.wikipedia.org/wiki/Denial-of-service_attack

One of the most common attacks that we see is a variant of DDoS that uses Quake3-based games as reflectors. We talk more about that type of attack here: viewtopic.php?f=25&t=4960

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.