Make sure it is an attack
Plenty of outages look like attacks: a full disk, a stuck database, a bad deploy, a provider incident. Check quickly:
- Your access log. A flood shows as far more requests than usual, often to one or a few URLs, from many addresses, often with the same few User-Agents.
- Your server's graphs. CPU, connections and bandwidth jumping at the same minute point to traffic. A slow database with normal traffic points elsewhere.
- Your provider's status page. If the whole network is down, the problem is not yours to fix.
Write down what you see
Two minutes now save hours later. Note when it started, which URLs are hit, roughly how many requests a second, and a few sample log lines. Your protection provider, your host and, if it comes to that, the police will all ask.
Put protection in front
A server cannot filter a Layer 7 flood while it drowns in it. Put a protection service in front that reads every request and stops the flood before it reaches you. With Shieldify that is one DNS record, and protection starts the moment it points to us, also in the middle of an attack: see Point your DNS.
DNS changes reach visitors as their old records expire, from a few minutes to a few hours depending on the record's TTL. A short TTL, set before you need it, makes this faster next time.
Lock down your server
Attackers who already know your server's own address will keep sending the flood straight to it. Close that path: accept ports 80 and 443 only from your protection service in your server's or your provider's firewall (Lock down your server).
If the flood still reaches your server directly after that, it is aimed at the address itself. Ask your hosting provider for a new address, or for upstream filtering on the old one, and keep the new address out of every public record. Eight ways origin addresses leak shows where to look.
Tell people, lighten the load
- Tell your customers on a status page or your social accounts that you know and are on it. Silence costs more trust than downtime.
- Lighten what is expensive. If one heavy page or search is the target, caching it or switching it off for an hour can bring the rest of the website back sooner.
- Keep your logs. Do not let them rotate away: they are your evidence and your best material for later.
Mistakes that make it worse
Blocking countries or networks
Floods come from dozens of countries and the largest home internet providers. Blocking them locks out your customers and barely dents the flood.
Restarting in a loop
A restart drops the queue for a moment and the flood fills it again. It costs you the requests real visitors had in flight.
Posting your server's address
Asking for help in a forum with logs, configs or screenshots that show your server's address hands it to whoever is watching.
Paying a ransom
If the attack comes with a demand, paying marks you as someone who pays. Keep the message, report it to the police, and protect the website instead.
Before the next one
Floods come back: we measured the same tool returning two days later, with half of the same addresses. Once things are calm, write down the timeline, keep the protection in front, make sure your server accepts traffic only through it, and set up alerts so you hear about the next attack before your customers do.