Online shop in Cluj-Napoca on Black Friday
An L7 attack on the search page used up every database connection on the busiest sales day. Caching search results and rate limiting per IP cut the load, and bot filtering in the WAF blocked the rest.
Security guide · Romania
What is a DDoS attack and how do I protect my server from it?
A DDoS attack breaks nothing: it fills the link or uses up every resource on the server until real customers can no longer get in. The typical sign is a site that suddenly turns slow or unreachable, with no error in the application.
Short answer
- A DDoS (Distributed Denial of Service) attack is traffic sent from many sources, usually a botnet, to exhaust the bandwidth, connections or CPU of a server.
- Volumetric attacks at layers L3 and L4 can only be stopped in front of your server, at the provider or in a scrubbing service, because a server cannot absorb traffic that saturates its own link.
- Application-layer L7 attacks are reduced with rate limiting, caching, a WAF and bot filtering in front of the application.
- Choose a provider with L3/L4 protection included, add a WAF for L7 and write a response plan.
- What DDoS stands for
- Distributed Denial of Service, traffic from many sources
- Where volumetric attacks are stopped
- Before the server: provider, scrubbing, Anycast
- NIS2 deadline for the early warning
- 24 hours from becoming aware of a significant incident
Volumetric attacks versus application attacks
At layers L3 and L4 the attacker sends raw packets: UDP floods, amplification through open DNS or NTP servers, SYN floods. The aim is to fill the link or the connection table, whatever the server runs. At L7 the attacker sends HTTP requests that look legitimate but hit expensive pages such as search, carts and logins, so modest traffic can occupy every PHP worker or database connection. The two types need different defences.
Why the firewall on the server does not stop a DDoS
A local firewall decides which packets to accept after they have already reached the network card. If the link is saturated, that decision comes too late: legitimate traffic no longer fits, whatever the rules say. Volumetric mitigation happens upstream, in the provider's network or in a scrubbing centre that forwards only clean traffic. Locally you remain responsible for L7: limit requests per IP, serve public pages from cache and block bots.
What Romanian law says
If your company falls under OUG 155/2024, the NIS2 transposition approved by Law 124/2025, a DDoS that interrupts an essential service can count as a significant incident: early warning to the DNSC within 24 hours, notification within 72 hours and a final report within a month. Registering with the DNSC, regulated by Order 1/2025, is the entity's duty, not the hosting provider's. NIS2 aside, a company issuing e-Factura needs access to the ANAF system within the legal deadline, so availability has fiscal consequences.
| Layer | Example attack | What it exhausts | Who mitigates |
|---|---|---|---|
| L3 (network) | ICMP flood, DNS/NTP amplification | Link bandwidth | Hosting provider, scrubbing, Anycast |
| L4 (transport) | SYN flood, UDP flood | Connection table, bandwidth | Hosting provider, upstream filtering |
| L7 (application) | HTTP flood on search or login | CPU, PHP workers, DB connections | WAF, CDN, rate limiting, server-side cache |
Commands and configuration
Nginx: rate limiting on the login page
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
}Nginx: cap on simultaneous connections per IP
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;Practical examples
SaaS company in Iasi with a public API
One customer's faulty script produced thousands of requests per second, with the same effect as an application-layer DDoS. Per-API-key limits and 429 responses fixed it without blocking any of the other customers.
Common mistakes
- Believing the firewall on the server protects you from DDoS, when it cannot absorb traffic that saturates the link.
- Trusting a CDN completely while the real server IP stays exposed in DNS records or in mail headers.
- Never testing the response plan and not knowing whom to call at the provider.
How 4hosting helps
- L3/L4 DDoS filtering is part of the network in front of the servers in Frankfurt, rated at 1.5 Tbps and included in the plans.
- WAF & DDoS Protection covers layer L7: OWASP rules, rate limiting and bot filtering; SIEM & Incident Response picks up abnormal traffic growth.
- The monthly CyberSecurity hours in your plan, 1–8 on VPS and 5–10 on dedicated servers depending on the plan, plus 10 on GPU servers, are requested from the client panel, in the “DevOps Services” section.
Related questions
How can I tell a DDoS from an application problem?
Look at traffic and connections before you look at code. A sudden jump in packets or requests from many IPs, with every service answering slowly, points to a DDoS. An application bug usually leaves error messages in the logs and affects particular pages, not the whole machine.
Does a CDN stop every DDoS attack?
A CDN with protection absorbs the volume and filters L7 for the traffic passing through it. If the origin IP is known, attackers hit it directly and bypass the CDN. Restrict access to the origin to the CDN's IP ranges, and keep L3/L4 protection at the provider anyway.
Do I have to report anything after a DDoS attack?
If you fall under OUG 155/2024 and the attack caused a significant interruption, you notify the DNSC within the legal deadlines. If it was a diversion for access to personal data, GDPR duties towards ANSPDCP apply as well. In every case, document the incident internally.
Request a security review
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.