As Mattrogowski says you're not going to be able to do much as the application layer simply because of the overhead of the application. So I can't really help with suggesting an add-on or anything as simple as that. The most I can do is offer a few observations on general mitigation.
Realistically protection against DDOS very much depends on your hosting solution. DDOS attacks in the lower network layers (typically layer 3) really are more the realm of your network kit upstream of your server(s). If you own your own hardware all the way to the router then odds are you already know enough to implement or procure solutions. If you own your own hardware or rent it, and rely on a co-location provider to provide your routing and switching then the most important thing and you are best of discussing DDOS protection with your hosting supplier. It may be all they can do is to blackhole the traffic and shift you to another IP address, but it's worth discussing their options ahead of time.
That leaves you with what you can do on your actual servers themselves. Realistically your only options are:
- either reducing the computation overhead of serving requests, ie increasing your capacity
- or dropping the traffic at the firewall layer.
The latter very much depends on identifying the traffic, a naive attack might only hit a couple of endpoints or might actually not be that distributed and you can identify the IP addresses being used. Hopefully if the DDOS is coming from rented servers you would be able to block entire network ranges to "get ahead" of the attack. However if it's properly distributed and leveraging 1000s of consumer connections it's going to be very hard to not just be reactive. There are various tools like fail2ban and web application firewalls that can help with some of this, some web servers have rate limiting options built into them (Nginx for instance) that might also help manage the traffic and keep the server online. If it's a true DDOS then it'll be hard, however the AI scraping bots which tend to be so poorly written they can overwhelm a server will often be coming out of one IP range and looking up and temporarily blocking the entire block is effective in shutting them down without too much collateral damage.
The most effective way of reducing the overhead for each request is caching the data generated by the backend services (ie XenForo) and then serving that cached data instead of passing the request through to XenForo. There are numerous ways you might do this using either dedicated components or built in caches within the web server software you're using. Of course you may combine layers of caching and utilise the caching options within XenForo itself to help. So personally we use Nginx's caching layer extensively with some of our backend solutions to handle traffic and find that very effective, we also used to use Varnish a lot (less so these days). You might also consider switching a site off and replacing it with a temporary simple page that contains key information (if that were appropriate) until the attack passes since serving a static page is going to be much faster. However of course doing that does to a degree admit defeat.
There are other third party solutions along the lines of Cloudflare aimed at assisting DDOS, either by scrubbing traffic (search for DDOS scrubbing services) or by handling load over more machines and closer to clients - ie a content delivery network (CDN).
Certainly if you're aiming for small attack mitigation, I'd look at what you can do to cache pages for non logged in users and rate limiting connections then have a look at tools like fail2ban to automate some of the blacklisting of IP addresses. I'm not personally that familiar with fail2ban as we use our own in-house equivalent tools over our network to do that job, but it seems very popular and well supported and documented.
![[DBTech] DragonByte Security](/community/data/resource_icons/5/5868.jpg?1592168450){kind=icon}
