IdeaWazaWiki

DDoS protection

DDoS protection is the set of methods that keep a website or network reachable while many machines try to overload it. DDoS stands for distributed denial of service. This page covers defense only and is general education, not professional security advice.

What a DDoS attack is

A denial of service attack tries to make a service unavailable by overloading it.[1] In a distributed attack the traffic comes from many sources, often a botnet of hijacked devices.[2] That makes attackers hard to tell from real visitors.[1]

A useful mental model is that every service has three limits: bandwidth, state, and work. Bandwidth is the pipe into the server. State is the memory that tracks open connections. Work is the processor and database time needed to build a page. An attack tries to fill one of them. Think of a shop with a crowd in the doorway. Nothing is broken, but customers cannot get in.

Main types

AWS documentation sorts attacks into three classes that match these limits.[3]

  • Volumetric. Sheer traffic fills bandwidth.
  • Protocol or state exhaustion. A SYN flood starts many connections and never finishes them, so real ones find no room.[4]
  • Application layer. An HTTP flood sends requests that look valid, such as searches, and work runs out first.[3]
  • Reflection and amplification. The sender forges the victim address on a small request to a third party server, such as DNS or NTP. That server sends a larger reply to the victim.[5]

A worked example

These numbers are made up for illustration. A small wiki has a 100 Mbit per second link. Its server builds 20 uncached pages per second. Normal traffic is 2 requests per second.

A flood of 200 search requests per second uses little bandwidth, yet it needs ten times the server capacity. A cache that answers 95 percent of repeats leaves only 10 requests per second for the database. The wiki survives.

Now the flood grows to 1 Gbit per second. The link is full ten times over, and no server cache can help. Only an upstream layer can stop it.

How protection works in layers

  • Overprovisioning. Spare capacity helps but costs money.
  • Anycast and scrubbing centers. With anycast, one address is announced from many places.[6] A scrubbing center filters diverted traffic and passes on the clean part.[5]
  • Rate limiting. A server caps requests per client. HTTP status 429 means too many requests.[7]
  • Caching and CDNs. Copies answer repeat requests.
  • Web application firewalls. Rules block harmful requests.
  • Challenge pages. A visitor passes a check first.
  • SYN cookies. The server encodes connection details in its reply and keeps no state until the client answers.[4]
  • Blackholing and BGP flowspec. Blackholing drops all traffic to the attacked address. That ends service there, but it protects the rest of the network.[8] Flowspec shares finer filter rules between routers.[9]
  • Upstream ISP filtering. Your provider can filter before traffic reaches your link.[2]
  • Autoscaling and cost. More instances absorb load, but the bill grows. AWS Shield Advanced offers cost protection for scaling charges caused by attacks.[10]

What protection cannot do

CISA states that no one can completely avoid becoming a target.[2] A big flood can beat any single link. Strict filters can block real visitors, and challenge pages can block people who turn off JavaScript.[11] A flash crowd from a popular link can look like an attack.[12] A proxy also sees your traffic.

A checklist for small site and wiki owners

  1. Cache first. MediaWiki has an optional file cache for rendered pages.[13]
  2. Put a CDN or proxy in front. Cloudflare, Akamai, and AWS are example providers. Cloudflare acts mainly as a reverse proxy.[14]
  3. Hide the origin address. Accept web traffic only from the proxy.
  4. Set rate limits in nginx or a similar server. MediaWiki also has $wgRateLimits for edit floods.[15]
  5. Use a fail2ban style tool. Keep software patched.
  6. Keep a mirror. Export dumps and publish a static copy, as in Local-first wiki and Git mirrors.
  7. Monitor traffic and write an incident plan. NCSC advises understanding your service and defenses, creating a response plan, and testing it.[1]
  8. Ask your host what it filters, and whom to call.

Open source tools and open standards

  • nginx. The limit_req module caps request rates per key, such as an address.[16]
  • fail2ban. It watches log files and bans addresses that behave badly.[17]
  • CrowdSec. This open source engine blocks bad addresses found in logs.[18]
  • ModSecurity and Coraza. ModSecurity is an OWASP firewall engine under the Apache 2.0 license.[19] Coraza is an OWASP project that works with the OWASP Core Rule Set.[20]
  • Anubis. This MIT licensed tool adds a proof of work challenge, though determined bots can solve it.[11]
  • Vinyl Cache. This BSD licensed caching proxy was formerly called Varnish Cache.[21]
  • Linux SYN cookies. The kernel setting tcp_syncookies is a fallback.[22]
  • BCP 38. This IETF best practice asks networks to filter packets with forged source addresses.[23] It does nothing against floods from valid addresses.[23]

Decentralized and permanent copies

A static mirror keeps pages readable when the live site is down. IPFS names files by content,[24] and data stays available only while a node pins it.[25] Arweave describes itself as permanent storage.[26] See Permaweb Basics.

The limits are real. A copy does not stop an attack on the main site. Readers must know where it lives, and gateways can be overloaded too. Editing still needs the live wiki. The History of decentralized wikis shows the risk of single hosts.

Responsible use

This page is for defenders and gives no instructions for launching attacks. Many jurisdictions treat such attacks as illegal.[5] Test only systems you own, or with written permission.

Discussion questions

  • Which limit fails first on a small wiki, and why?
  • When is it right to block a region to stay online?

Essay ideas

  • Argue whether a free wiki should depend on one proxy provider.

AI prompt ideas

  • Explain the difference between a SYN flood and an HTTP flood, then quiz me with five questions.
  • Help me write an incident plan for a small wiki, and ask me about my host.

Readings from Wikipedia

See also

References

  1. ↑ 1.0 1.1 1.2 Denial of Service (DoS) guidance, NCSC
  2. ↑ 2.0 2.1 2.2 Understanding Denial-of-Service Attacks, CISA
  3. ↑ 3.0 3.1 How AWS Shield and Shield Advanced work, AWS documentation
  4. ↑ 4.0 4.1 RFC 4987: TCP SYN Flooding Attacks and Common Mitigations, IETF
  5. ↑ 5.0 5.1 5.2 Denial-of-service attack, Wikipedia
  6. ↑ RFC 4786: Operation of Anycast Services, IETF
  7. ↑ RFC 6585: Additional HTTP Status Codes, IETF
  8. ↑ RFC 3882: Configuring BGP to Block Denial-of-Service Attacks, IETF
  9. ↑ RFC 8955: Dissemination of Flow Specification Rules, IETF
  10. ↑ AWS Shield features, AWS
  11. ↑ 11.0 11.1 Anubis (software), Wikipedia
  12. ↑ Slashdot effect, Wikipedia
  13. ↑ Manual:File cache, MediaWiki
  14. ↑ Cloudflare, Wikipedia
  15. ↑ Manual:$wgRateLimits, MediaWiki
  16. ↑ ngx_http_limit_req_module, nginx documentation
  17. ↑ Fail2ban, Wikipedia
  18. ↑ CrowdSec documentation
  19. ↑ OWASP ModSecurity, OWASP
  20. ↑ OWASP Coraza
  21. ↑ Vinyl Cache, Wikipedia
  22. ↑ IP Sysctl, Linux kernel documentation
  23. ↑ 23.0 23.1 RFC 2827: Network Ingress Filtering, IETF
  24. ↑ What is IPFS, IPFS documentation
  25. ↑ Persistence, permanence, and pinning, IPFS documentation
  26. ↑ Arweave
Retrieved from "https://ideawaza.com/index.php?title=DDoS_protection&oldid=92169"