A way to prevent non distributed, network-level DoS attacks?

A DoS is different from the other concerns you mention.

With MiTM, zero is the only acceptable number of successful attacks. Zero is the only acceptable number of successful SQL injections. Zero is the only acceptable number of brute forced passwords- and why even subject yourself to password brute forcing, disallow passwords altogether and whitelist IPs.

With DoS...if you are infrastructure supporting commercial customers, then, sure, transient request lossage directly costs money. That's a metric that one can care about.

If the service is best effort, there is probably a level of "successful" DoS that you can ignore. There is a gradation of acceptability for the risk.

To have some insurance, you can apply per-IP rate limits at the network level, e.g. https://making.pusher.com/per-ip-rate-limiting-with-iptables/, and you can apply per-IP rate limits at the application level in nginx, e.g. https://www.nginx.com/blog/rate-limiting-nginx/ or with any rate limit plugin for Wordpress.

But because it's amorphous, distill the concern into a metric that accurately expresses the distinction between caring and not caring for you. This measurement may just be a report from a web ping service giving you an availability score.


There is no reason to believe DDoS won't happen & only DoS would. A single attacker, possessing a botnet is enough. Or search engines such as Shodan will help a single infuriated attacker compromise remote machines to launch DDoS.

If you aren't clear about this, Google "DDoS using Memcached servers". You will perhaps get to read about Massive DDoS attacks happened some weeks ago on websites such as Github.

Coming to the solution:

  • As it is already suggested, imposing a per IP limit is a must. For example, if you perform numerous Google Searches in a short period of time, Google will ask to solve the ReCaptcha challenge.

  • I am not sure how Cloudflare DDoS protection works. But oftentimes I have seen it redirecting to site after 5 seconds. It might be possible to prevent DDoS by terminating connections which send arbitrarily large amounts of data. [like in the case of Memcached servers].

  • Assessing your protection measures with all available tools. At least with open source tools such as OWASP ZAP, w3af etc., sometimes a non-distributed simple DoS script such as hulk.py (there is also a modified version on Sourceforge) may be able to break comprehensive security measures.

However, I think while setting a per-IP limit is inevitable to avoid script kiddies etc., it alone can't provide sufficient protection since IP address spoofing is not a very big job, and the probability of DDoS can't be neglected.


First of all, user9600383 is right: DDoS is cheap and easy to perform, and you are wrong to discount it.

By network-level attack, I assume you mean an attack at Layer 3 or lower rather than something that targets your site/application directly.

If it is from a single IP address that does not saturate your network path, you could setup Fail2Ban and rate limits. Fail2Ban will take care of protocol abuse (like excessive SSL attempts, which can waste bandwidth and CPU), and rate limits will reduce raw IP traffic.

However, you have a much bigger problem if the attacker is capable of saturating your network connection. The only way to provide reliable service is to have your network provider block the packets on their end.

There is no standard solution for this, and you would have to work with your network provider to determine if an automated solution is even possible. The answer is often "No" based on my experience, but perhaps they offer better support these days. It's been a few years since I worked directly with them.

For a competent DoS/DDoS attacker, most sites are easy targets. The inability of a typical web host to respond meaningfully at the network level gives them a very simple and reliable method of attack.

CloudFlare exists because they can automatically detect an attack and execute countermeasures that are not available to the administrator of a single server. Their bread-and-butter is something that you simply cannot duplicate.

I suggest Fail2Ban and/or rate limits as your best standalone solutions, but they will be inadequate against any halfway decent attacker.