Mitigation is already on for every service and works without you asking: RedHosting's protection works in two layers — the GC network, which absorbs volumetric attacks with up to 20 Tbps of capacity before traffic reaches our infrastructure, and an A10 appliance at the edge, which filters what isn't volumetric and would get past a volume-only inspection.
This guide is about the other half: your part. Recognizing that it's an attack, deciding what to do, and not making it worse by reflex.
1. Is it really an attack?
Not every outage is an attack, and treating ordinary overload as an attack sends the diagnosis the wrong way. The signs that tell them apart:
| Sign | Attack | Ordinary overload |
|---|
| Onset | Sudden, within seconds | Gradual, following usage |
| Traffic origin | Many IPs with no audience pattern | The usual ones |
| Link to an event | None, or right after a public feud | Promotion, launch, peak hours |
| Connection content | Repetitive, never completing anything | Normal requests, just many of them |
| CPU and memory | Normal, but the network saturates | Rise along with traffic |
The last point is the most telling: in real overload the machine is working; in a volumetric attack it's idle and what's saturated is the path to it.
2. What to do, in order
- Note the time. Write down when it started, to the approximate minute. Without that, finding the event in the log later becomes a treasure hunt.
- Don't keep rebooting. Rebooting doesn't stop an attack, and the machine spends more time booting than serving.
- Open a ticket early, with IP, time and what you observed. The sooner the team looks at live traffic, the easier it is to tune the filter to that specific attack's pattern.
- Keep whatever you can from the application log and the output of
ss -tn state established or equivalent. That material is what lets the rule be tuned afterwards.
- Let your community know if it's a game server. Silence during an outage does more damage to your reputation than the outage itself.
⚠️What doesn't work: Blocking IPs by hand. In a distributed botnet the sources change constantly, and the list grows faster than you can maintain it. Rules based on traffic patterns are what hold up; IP by IP is bailing water.
3. Decisions that tend to come up
| Situation | Recommended decision | Risk of ignoring it |
|---|
| Connection spike right after an event | Raise the limit temporarily and watch the origin | Blocking a legitimate player or customer |
| Many short connections that never complete | Filter by signature and cadence, not by IP | Exhausting the firewall's state table |
| Abnormal queries on an auxiliary service | Isolate the port and reduce exposure | Partial outage of the whole ecosystem |
| Attack always returns at the same time | Take the pattern to support for a permanent rule | Repeating manual mitigation every week |
💡Tip: During a real incident, ask in the ticket for a report with the time, peak traffic and type of filter applied. That history is what lets the rule be tuned before the next event, instead of reacting from scratch again.
4. Reduce the attack surface before the next one
Half the work is done when there's no attack at all.
A review worth doing every quarter
✓Inventory of exposed ports. Every open port nobody uses is free surface for the other side.
✓Auxiliary services closed to the public — database, admin panel, internal API. They don't need the open internet.
✓External monitoring, outside our network, to confirm availability from an independent point of view.
✓An incident runbook with ready-made messages for your community. Writing an announcement during an outage goes badly.
✓Review of plugins and modules: every one you don't use is exposed code for no reason.
✓Server IP kept out of public view when there's a layer in front — publishing the origin IP bypasses the protection.
5. What's already ours, and you don't need to configure
- Two-layer mitigation on every product — Minecraft, Hytale, VPS, dedicated servers, websites and bots —, included in the price.
- Absorption of volumetric attacks in the network, before they consume your server's bandwidth.
- Proactive 24/7 monitoring.
- Customizable firewall and access restricted to authorized players, on game servers.
The figures and how the two layers work are at redhosting.com.br/protecao.
During an incident
WhatsApp +55 11 98833-3902 is the fastest channel, 24 hours a day, in Portuguese, English, Spanish and German. Tickets at financeiro.redhosting.com.br. Ongoing maintenance and incidents appear at redhosting.com.br/status.