DDoS protection for a VPS: capacity, application rules and recovery

A flooded network path, exhausted connection table and expensive application query require different controls. Collect network counters, request rates and response timing. The first symptom is evidence to investigate, not proof of a single attack type.

Server port speed, period transfer allowance and mitigation capacity are different specifications. The prepared catalogue’s mitigation values range from 10 to 400 Gbps by plan. None changes the CPU time needed to answer a costly request.

Umbra 1 lists a 1 Gbps server port, 1 TB monthly transfer and a 10 Gbps mitigation specification. The first describes the connection, the second a period allowance and the third a proposed filtering envelope. None means the application can answer 10 Gbps of useful requests. Filtering behaviour and permitted traffic need validation on the launch network.

The prepared design detects traffic anomalies, diverts attacks into filtering and returns permitted traffic. Its intended activation target is under 60 seconds, but live routing and upstream controls must be tested before that becomes a promise. Ask what happens beyond the included envelope and how legitimate traffic is restored.

Cache suitable responses, rate-limit expensive paths and secure administrative access. A WAF or reverse proxy must be configured and maintained as a separate layer. Restrict origin web access to trusted proxy sources if that is part of the design, without closing the recovery route.

Assign who can change rules, what evidence belongs in a ticket and how users learn the status. Test alert delivery and the replacement route. A working backup and a sober incident record are useful even when the event turns out to be an application fault.

L3/L4 incidents can involve UDP amplification through DNS, NTP or memcached, or TCP SYN floods that pressure connection state. L7 incidents target application work, such as repeated searches or login attempts. Compare bits per second, packets per second and requests per second separately. An edge filter, a connection control and an application rule solve different parts of the problem.

• Close or restrict unnecessary public UDP services and keep origin access deliberate.
• A geographically distributed anycast design needs route withdrawal, state handling and failover tests; it is not established by a mitigation capacity figure.

A challenge, CAPTCHA or proof-of-work gate can add friction to suspicious requests. It can also affect legitimate visitors, automated clients and accessibility, so apply it to suitable endpoints and measure the result. A slow response or tarpit occupies resources too; test the cost before assuming it is cheaper than rejecting the request.

• Keep an accessible recovery or support route when a challenge prevents entry.
• Request limits, caching and application fixes remain useful even when a challenge is enabled.