Itnetic Technologies| Step | Goal | Typical time |
|---|---|---|
| 1. Confirm the attack | Rule out outages and traffic spikes | Minutes |
| 2. Enable edge filtering | Drop attack traffic before your origin | 5–30 min (DNS) |
| 3. Lock down the origin | Prevent direct-to-IP bypass | Same day |
| 4. Cut request cost | Cache, rate-limit, simplify pages | Same day |
| 5. Document & keep protection on | Be ready before the next wave | Ongoing |
Step 1 — Confirm it is actually a DDoS
Not every outage is an attack. Check monitoring before reacting: a traffic spike with normal request diversity may be a marketing win or a bot crawl. Signs it is an attack: request volume far above baseline concentrated on a few endpoints, traffic from unusual networks or countries, origin CPU/connections saturated while a deploy or infrastructure change is ruled out. Your hosting provider's dashboard and server logs answer this in minutes.
Step 2 — Get filtering in front of your origin
You cannot win a resource war on your own server — you need attack traffic dropped before it reaches you. The fastest path is a reverse-proxy protection service enabled through DNS: point your domain's records at the protection layer and traffic starts flowing through its scrubbing edge. With Itnetic this is two DNS record changes, and most domains are protected within about five minutes as DNS propagates.
If you are mid-attack and already behind a protection service, enable its strictest mode ("under attack" / challenge everything) first, then relax it once the wave passes.
Step 3 — Hide and lock down your origin
Once traffic flows through a protection edge, attackers will try to hit your server's IP address directly, bypassing the filter. Close that door:
- Firewall your origin so it only accepts traffic from the protection network.
- If your origin IP was public before (DNS history is easy to look up), ask your host for a new IP after enabling protection.
- Remove the origin IP from any DNS records that remain unproxied (mail records are a common leak).
An exposed origin is the most common reason protection appears to be working while the site stays down, so it is worth doing thoroughly — the full walkthrough, including the leaks most people miss, is in how to hide your origin IP address.
Step 4 — Reduce the cost of every request
Layer 7 attacks win by making you do expensive work. Make it cheap:
- Cache aggressively at the edge so repeated requests never touch your origin — this is where a CDN doubles as attack armor.
- Rate-limit expensive endpoints: login, search, checkout, password reset.
- Serve a static or simplified version of critical pages during an incident.
On a CMS the expensive paths are the same on every install, so the fixes are specific rather than general — see how to protect WordPress from DDoS attacks if that is what you run.
Step 5 — Document and prepare for the next one
Attacks recur. Capture logs of what was blocked, note which endpoints were targeted, and keep protection permanently enabled rather than toggling it on during incidents — the first minutes of an attack are exactly when ad-hoc setup is hardest. Review what DDoS attacks look like and how Layer 7 attacks differ, so your team recognizes the pattern early.
If the attack arrived with an extortion email attached — pay by a deadline or this continues — do not negotiate and do not pay; the response is covered in ransom DDoS: what to do about an extortion email.