A Practical Protection Plan for DDoS Attack Prevention

DDoS attack prevention requires layered preparation rather than adding a single firewall rule. First, determine whether the traffic is consuming bandwidth, server resources, or a specific application function. Then use the provider’s network-level filtering together with web application rules where necessary and a measurable rollback plan.

Define access and limits before starting a DDoS attack prevention plan

If you use shared hosting, you generally cannot access the operating system firewall or network router; you are limited to the traffic, security, and support options in the control panel. On a managed server, the provider panel, server administrator, and application logs may represent separate layers. On a server you manage yourself, the provider’s DDoS policy is also important, in addition to network statistics, web server logs, and resource-monitoring data.

Before making changes, record the current DNS records, the origin server address, active security rules, and baseline values during a normal traffic period. Back up the relevant configuration if possible. If the origin server’s address was previously exposed directly, adding only a proxy or CDN layer may not automatically conceal the existing address; separately verify with the provider whether the old address remains accessible.

Distinguish the attack type through observable indicators

First, note when the incident began and compare network usage, CPU, memory, connection count, HTTP status codes, and request paths during the same period. If bandwidth or connection capacity is full while application logs show relatively few requests, the traffic is most likely taking effect at the network layer before reaching the server. In that case, increasing application-level rate limiting will not relieve a saturated connection; the provider’s upstream filtering is required.

By contrast, if traffic is concentrated on a particular entry, search, or login address and CPU and database usage are rising, the load may be targeting the application layer. Examine why the requests are expensive in terms of authentication, query cost, or response size. Instead of blindly blocking requests from the same IP address, choose a narrower control, such as rate limiting or caching, that protects the path also used by legitimate users.

Apply protection settings in a safe sequence

1. Check the provider’s protection: In the hosting or server panel, review whether DDoS filtering, traffic scrubbing, network protection, or proxy routing is active. If bandwidth is full during an attack, contact the provider with the incident time, affected origin address, and traffic type; do not treat application logs alone as sufficient evidence. When protection is enabled on the provider side, measure whether network usage and availability return to normal during the new time period.
2. Verify the DNS and origin-server path: Check that the domain is actually routed through the protection layer and whether the origin server is directly exposed to the internet. Some services require a DNS change, while others also require a profile to be enabled in the provider panel. If the origin address is still receiving direct attack traffic, apply the access restriction recommended by the provider; target only web traffic so that you do not accidentally cut off administrative access.
3. Narrow the application layer: If the attack is concentrated on a particular URL or operation, consider a rate limit, request-body limit, caching, or a validation rule offered by the provider for only that operation. Record the previous value you are changing and change only one rule at a time. Do not include paths where legitimate traffic is critical, such as login or payment paths, in a general blocking rule.
4. Verify the same operation with new evidence: After the change, run the same URL or health check that previously failed again. Note the start and end times, then examine the new network graph, application logs, and status codes. For example, seeing 429 instead of a timeout in new records indicates that the rate limit has taken effect; however, if you notice that legitimate users are also being rejected, loosen the limit or narrow the rule to a specific expensive endpoint.
5. Roll back safely if necessary: If the problem began after the latest rule, return only that rule to its previously recorded value and test the same operation again. If the attack continues, do not disable all protection; instead, roll back the application change and continue the provider’s network-level investigation. Share the resulting timestamps and anonymized summaries; do not send passwords, access keys, or session tokens.

Choosing the right layer in a hypothetical scenario

Suppose a product-catalog site suddenly fills its connection capacity while normally using little CPU, and the web logs show no meaningful increase in requests. This observation calls for examining the provider’s network-layer filtering and traffic-scrubbing option before beginning to optimize application queries. If network usage falls after filtering but CPU rises again on a single search address, then, as a second stage, consider rate limiting or caching only for that search operation.

In another outcome, the logs may show many requests directed at the same login path while bandwidth remains normal. In this case, purchasing more network capacity may not solve the problem; examine the cost of the authentication operation, the scope of the rate limit, and whether legitimate users are affected. Remember that if traffic is distributed across different sources, a rule based only on IP addresses may be insufficient, and provider-supported application protection may be more suitable.

How should you assess whether the protection is working?

A successful change is not merely the site becoming available again. Assess together whether the origin server remained reachable during the same period, normal user operations received the expected status codes, resource consumption on the targeted path decreased, and the abnormal pattern became less pronounced in new logs. Measurement screens, log detail, and automatic filtering behavior may vary by provider; therefore, base your assessment on the observable result rather than the protection’s name in the panel.

For the first implementation, record the current settings and the starting time, then change one layer only. Recheck the results using the same operation; if the symptom persists, roll back the latest change and ask the provider for a time-stamped review of the network traffic. When evaluating hosting or server options, you can review the required access level through İyibirNet.