DDoS attacks: signs and protection

What are the characteristics of DDoS attacks?

A distributed denial-of-service attack consumes network, protocol or application resources until legitimate users can no longer complete a business action. It does not always make the whole site disappear. Early symptoms may be rising latency, unstable sessions, HTTP errors, API queues, DNS failures or abnormal cloud cost around one expensive endpoint. Triage therefore has to correlate carrier traffic, DNS/CDN data, WAF events, server metrics and application telemetry against a known baseline.

How DDoS works and why the source address does not identify the attacker

DDoS attacks have been known since the 1990s, but today's attacks are highly distributed. Instead of one source, a company may see traffic from thousands of devices across countries, providers and IoT networks. The goal is service disruption: overloading a server, application, DNS service, link or online business process. Because traffic may come from botnets, compromised devices, cloud resources or exposed services, a local firewall rule is rarely enough. Protection must coordinate the provider, DNS, CDN, WAF, firewall, monitoring and communications plan.

• The attack may hit the store, API, VPN, login form, customer panel, DNS or cloud-hosted service.
• The sources of traffic include computers, IoT devices, proxy servers and infected botnet resources.
• Symptoms may include unavailability, delays, high cloud costs or overload of only one endpoint.
• Therefore, the response must include carrier, DNS/CDN, WAF, hosting, application, and customer communications.

DDoS patterns and tooling defenders should recognise

Examples associated with DDoS belong to different categories: LOIC, HOIC and hping3 can generate traffic; R.U.D.Y. describes a slow HTTP resource-exhaustion pattern; and Mirai is a malware family used to build IoT botnets. For defenders, the specific name matters less than identifying the layer, volume, protocol, target and duration, then activating the correct filtering path quickly.

Attackers also use botnets, poorly secured IoT devices, reflection attacks, open resolvers and rented attack services. Telemetry on the attack pattern and repetition helps bring network operators, hosting providers and security providers into a coordinated response more quickly.

DDoS attacks – how to protect yourself against them?

Protection against DDoS involves prior preparation of traffic filtering, contacts with suppliers, monitoring and degraded operation mode. Small companies without an extensive IT department should also have a basic plan: who makes decisions, where the logs are, who contacts the operator and when stricter protection rules are activated.

• Agree with your operator, hosting, DNS/CDN and WAF provider what mechanisms can be enabled during an attack.
• Build traffic baselines and alerts for HTTP errors, latencies, link load, CPU, queues and cloud costs.
• Introduce rate limiting, cache, challenge, form protection and limits for expensive endpoints.
• After an incident, save logs, decisions, costs and corrections to the response procedure.

What should be ready before the first major incident

During an attack there is no time to discover who controls DNS, which carrier can filter traffic or who may enable a stricter WAF rule. The company should identify critical public services, protection providers, alert thresholds, decision authority, communication channels and a safe degraded mode before the first serious event.

• List critical services, domains, IP addresses, DNS providers, hosting, CDN and line operators.
• Set alert thresholds for traffic, HTTP errors, response time, CPU load, queues and cloud cost.
• Define who may enable filtering, rate limiting, challenges, routing changes and customer communication.
• Keep a short response procedure with contacts, escalation order, evidence to preserve and incident-closure criteria.

Weak points that only emerge under pressure

The weakest point is often not the busiest link but the slowest dependency: a DNS service, login endpoint, database query, queue or manual provider escalation. A readiness review should expose missing telemetry, stale DNS records, capacity limits, untested application behaviour and privileges that prevent the response team from acting safely under pressure.

How to build protection in layers

Start with the inventory of public services and their normal traffic, then combine upstream filtering, resilient DNS/CDN, WAF and rate limits, application safeguards, monitoring and an incident decision path. Each layer needs an owner, a test method and a known side effect so the response team can act without creating a second outage.

• Prioritise the online services and transactions with the greatest revenue or customer-service impact.
• Enable synthetic monitoring, application metrics and alerts for traffic and error anomalies.
• Confirm protection options with the carrier, hosting, DNS, CDN, WAF and cloud providers.
• Exercise escalation, evidence capture, status communication and return to the normal protection profile.

What to do first

Start with one service that matters most to your business, such as the online shop or customer service system. Review its protection with the person who administers it. Do not postpone urgent fixes until the entire review is complete; prioritise the remaining work by the impact of an outage.

• Confirm who manages the domain, hosting and connection, and how to report an ongoing attack outside office hours.
• Check that monitoring detects outages from a customer's perspective, not just whether the server is running.
• Agree available filtering and its limitations with the provider. Test changes in an agreed window without disrupting services.
• Walk through an outage scenario with the team. Everyone should know whom to notify and who can change the configuration.

What information to give your provider during an attack

Timestamps and comparable telemetry distinguish an attack from an application fault, carrier problem or legitimate demand spike. Preserve evidence from every layer together with the decisions made, because this shortens provider escalation and makes the post-incident review actionable.

• Traffic volume, HTTP status, response time, link utilisation, CPU, application queues and cloud cost.
• WAF, CDN, DNS, firewall, web-server and application logs with synchronised time and time zone.
• A decision record showing when filtering, rate limits, provider escalation and customer communication began.
• A post-incident summary covering downtime, business impact, costs, residual risks and response procedure changes.

Related Virtline services

DDoS is about availability, network security, application security and incident response. It is best to consider it together with monitoring and SOC procedures.

Decide what the service must preserve during an attack

DDoS readiness is a business-continuity decision as well as a network task. For each public service, management and the technical owner should agree which transactions must remain available, what degraded mode is acceptable, which threshold authorises protective changes and which residual risk can be accepted. This turns traffic filtering into an operating model that can be tested and reported.

• Rank customer journeys, APIs, remote access and administrative paths by business impact.
• Define trigger thresholds, change authority and the safe limits of stricter filtering or challenges.
• Record provider responsibilities, escalation contacts and evidence required for post-incident review.
• Review the response procedure after architecture, supplier or traffic-profile changes and after every material event.