[bArray]

From my personal low-end server perspective (which has stood up to simple attacks from Russian IPs), I have the following:

1. Static page caching (in RAM ideally) - dynamically generated content will kill you quicker than anything else, especially calls to a database. WordPress is very easy to kill in it's default state.

2. Kill high frequency requests from the same location as quickly as possible (make sure your response is less than the data they send you - ultimately you want their systems to be busier than yours). You want to free the port up as quickly as possible.

3. Move anybody you can identify as a legitimate user (credentials, low frequency requests) out to another server if possible.

Firewall wise, my system sits on the cloud, so usually high frequency traffic is the only issue I have to deal with. Interested to hear any advice of other people here.

[bo1024]

For #2 -- how do you "kill" high frequency requests? By ignoring them?

[colanderman]

Yep. Add the source address (or some more specific yet easily computed identifier) to a table that is checked early in the network path (in hardware if possible).

Or, if you want to be fancy, "tarpit" them (complete TCP handshake and then ignore, forcing attacker to actually commit resources), but apparently that's of questionable value these days. [1]

[1] https://en.wikipedia.org/wiki/Tarpit_(networking)

[bo1024]

Interesting, thanks.

[bArray]

In addition to @colanderman's suggestion I also do this on an application level - although not everyone will be able to do this.

[jmngomes]

Or by banning the source, especially repeat offenders.

I find that using a combination of nginx's limit_req and fail2ban over nginx logs is an easy measure that already goes a long way in handling basic types of DoS, like clients producing an abnormally high volume of requests.