A customer rings your service desk to report that a website, hosted application or VoIP service is suddenly unavailable. The network graph may show a bandwidth surge, but the same symptom can come from an exhausted connection table, a slow application request, or a compromised device network generating traffic elsewhere. Treating every outage as the same event leads to the wrong controls and slower decisions.

Distributed denial-of-service attacks, or DDoS attacks, are coordinated attempts to disrupt the availability of an online service. They can consume bandwidth, protocol state, server capacity or application resources. Classification matters because the indicator, responsible team and effective mitigation differ between attack types. The National Cyber Security Centre's DoS guidance treats DDoS as a core attack vector organisations should prepare to detect, mitigate and recover from, while its technical note sets out detection, identification, mitigation and tracing as the response stages.

This guide explains eight types of DDoS attacks, organised by the resources they consume. DDoS mitigation identifies and filters hostile traffic. Dark web monitoring addresses a different warning signal, compromised email addresses, exposed passwords and breached domains that criminals may use before an attack or alongside it. GoSafe is a fully white-label Dark Web Monitoring tool that service providers can sell under their own brand, alongside IT support, hosting, cloud, connectivity or web services through a simple monthly subscription. It can also sit within a wider plan for disaster recovery for cloud systems.

1. Volumetric Attacks

A service can remain healthy while its upstream circuit fills with hostile traffic. Volumetric attacks consume bandwidth first, directing enough data towards a service, edge router, hosting environment or transit link to congest the route before legitimate requests reach the application. UDP and ICMP floods are common examples. Amplification attacks add traffic through third-party services, turning a smaller request into a larger response directed at the victim.

UK-focused reporting shows why providers need controls beyond a local firewall. The 2024 UK threat report recorded 115,193 DDoS attacks in one year. DNS amplification accounted for 41,608 attacks, followed by TCP SYN, TCP ACK, TCP RST and DNS-layer attacks in the report's breakdown (SOCRadar UK Threat Landscape Report 2024). For service providers, that distribution supports prioritising upstream capacity and filtering.

What to watch and prioritise

Check for a sudden bandwidth rise, saturated transit links, unusual packet rates and traffic from many unrelated networks. Compare the event with a normal baseline so a product launch or broadcast is not mistaken for an attack. Flow records and packet captures can help identify UDP, ICMP or a reflection service as the source of the pressure.

Filtering should happen as far from the customer environment as possible. Confirm whether the ISP or DDoS provider offers scrubbing capacity, source validation, traffic diversion and anycast distribution across data centres. Local rate limiting can protect routers and servers, but it cannot reopen a transit link that is already full.

Practical rule: If the circuit is saturated, a server rule is too late. Escalate upstream first, then tune local and application controls.

The GoSafe DDoS protection guide explains the service-provider distinction between filtering hostile traffic and protecting the service behind it. GoSafe's role is complementary. Its continuous dark web scanning can alert a business when credentials or domain data are exposed, giving the account team a reason to address access security before an outage or intrusion. That signal supports DDoS planning, but it does not replace traffic detection, scrubbing or upstream capacity.

2. Protocol Attacks

Protocol attacks exhaust the state and processing capacity required to manage network conversations. A SYN flood sends connection requests that make a server or firewall reserve resources before the handshake is completed. ACK and RST floods target other stages of TCP handling, while malformed or fragmented packets can strain inspection devices and systems with protocol weaknesses.

Common examples include SYN, ICMP and UDP floods, along with malformed-packet attacks. The response should separate detection, identification, mitigation and tracing. A high packet rate alone does not show whether the failure is at the edge device, protocol stack or application. For service providers, that distinction determines whether to tune connection controls, divert traffic or investigate a wider service outage.

Indicators in the connection layer

Monitor connection-state tables, half-open sessions, retransmissions, unusual TCP flags and the ratio between inbound requests and completed sessions. A financial service, VPN gateway or VoIP platform may become unavailable while bandwidth remains below the level associated with a pure volumetric flood. Here, concurrent protocol state is the resource under pressure.

Mitigation starts at the network edge. SYN cookies reduce the need to retain state for incomplete handshakes. Stateful inspection can reject packets that do not belong to an established conversation, while per-source or per-destination limits can slow abusive patterns. Tune these controls against normal customer behaviour. Restrictive thresholds may block legitimate users behind carrier-grade NAT or busy office gateways.

• Use SYN cookies: Protect TCP handshakes without retaining every incomplete session in the same way.
• Inspect protocol validity: Drop malformed or unexpected packets at an appropriate network boundary.
• Patch exposed devices: Firmware and operating-system updates reduce exposure to protocol-handling weaknesses.
• Watch service-specific state: VPN, firewall, load-balancer and VoIP session tables can fail at different thresholds.

A protocol attack may form one part of a broader campaign. Reducing SYN traffic does not close the incident if the web service remains slow or abnormal traffic continues to reach the upstream connection. The incident owner should verify recovery at the affected layer, then check dependent services before declaring availability.

Dark web monitoring supports the prevention and response plan from a different angle. White-label monitoring can alert a provider or its customer when credentials or domain data appear in exposed sources, prompting access-security work before attackers combine account compromise with traffic disruption. It does not replace protocol detection, scrubbing or upstream capacity.

3. Application Layer Attacks

Application-layer attacks consume processing capacity inside a service, rather than filling the network connection. Requests can resemble normal HTTP traffic, API calls or searches, while triggering database queries, authentication checks, template rendering or expensive file operations. A relatively modest request rate can cause an outage when it repeatedly targets an inefficient endpoint.

The first warning is often degraded customer experience. Users report slow pages, failed logins, timeouts or intermittent errors even though bandwidth remains broadly normal. Compare request volume, response times, error rates, connection-pool use, CPU, memory and database activity. Higher HTTP 429 or 503 responses can support the diagnosis, but neither status code proves malicious intent.

Why standard network filtering misses the point

A firewall focused on IP addresses and ports may see valid traffic. Blocking countries or wide address ranges can reduce pressure, but may also exclude legitimate customers without stopping a distributed campaign. Identify the URLs, API methods, accounts and workflows consuming disproportionate resources, then set controls around those patterns.

A WAF can inspect HTTP behaviour and enforce rules nearer to the application. Apply rate limits by account, token, IP or endpoint where the business process allows it. Shield expensive operations with queues, caching, authentication controls and throttling. CAPTCHA and behavioural challenges can help during an incident, but selective use matters because accessibility and conversion may suffer.

Application-layer protection works best when the application team and network team share logs, thresholds and decision rights.

Before an incident, document service dependencies and available defensive capacity, as recommended in the NCSC denial-of-service guidance. For an MSP, map customer systems that rely on the same identity provider, DNS service, API gateway or database. One overloaded dependency can make several apparently unrelated services fail.

Dark web monitoring complements these controls by exposing leaked credentials, API keys or domain information that could help attackers combine account abuse with traffic disruption. A white-label service can give providers a customer-facing alert and remediation workflow, but it does not replace WAF rules, application telemetry or upstream DDoS capacity.

4. Botnet-Based DDoS Attacks

A botnet can turn an ordinary customer device into part of a distributed attack force. Compromised routers, cameras, NAS devices, servers, computers and other connected equipment receive instructions to send traffic together. Because the sources are spread across networks and countries, blocking individual addresses rarely resolves the event.

Service providers must investigate two possible exposures. A customer may be the victim of a botnet attack, or their exposed router or server may be generating outbound traffic, prompting an ISP complaint and reputational harm. An attack against a hosted service can also originate from the provider's own estate, so incident handling should examine both the target and customer assets.

Build an asset inventory that records ownership, firmware, internet exposure, administrative access and expected outbound behaviour. DNS logs, egress-flow data and command-and-control indicators can reveal infected devices before they become a wider operational problem. Network segmentation limits movement, while patching and removing unnecessary public access reduces the number of devices attackers can recruit.

The response depends on the botnet's role. For an infected customer device, isolate it, preserve evidence, reset credentials and check for persistence. For an attack against your service, combine upstream scrubbing with reputation signals and traffic analysis. A single IP blocklist is poorly suited to a globally distributed event.

• Inventory IoT and edge equipment: Include routers, cameras, NAS devices and appliances that endpoint tools may not cover.
• Restrict administration: Remove public management access where it is unnecessary and enforce strong, unique credentials.
• Segment vulnerable devices: Keep smart devices and operational equipment separate from critical business systems.
• Review outbound traffic: Unexpected scanning, unusual DNS activity or sustained UDP traffic warrants investigation.

Dark web monitoring addresses a separate route into the estate. GoSafe continuously scans for compromised email addresses, exposed passwords and breached domains, then sends alerts that business users can understand. These alerts do not identify botnet traffic, but they can prompt credential resets and customer discussions before stolen access reaches a device or management account. For providers, a white-label service can package that warning and remediation process for customers, while DDoS controls still handle traffic detection, filtering and capacity.

5. DNS Amplification and Reflection Attacks

A customer may report that its website is unreachable while its web servers remain healthy. The immediate cause can sit upstream: an attacker sends a small DNS query with the victim's address forged as the source, then causes a resolver to return a larger response to that victim. This combines spoofing with amplification. The resolver might be misconfigured, abused without its operator's knowledge, or selected because it generates a useful response.

Analysts repeatedly identify DNS reflection and amplification as a dominant volumetric technique in the UK. NETSCOUT's UK-focused analysis also describes roughly 20 UDP-based vectors and identifies CLDAP reflection and amplification as prominent methods. For service providers, the operational decision is to harden resolvers and arrange upstream filtering, rather than relying on additional local connection capacity.

Service teams can define spoofing in cybersecurity before documenting the attack path. The victim's logs may show the resolver, not the originating system, so blocking the apparent source rarely stops a reflection event.

Decisions for provider operations

Internet-facing DNS servers should not offer unrestricted recursive resolution. Restrict recursion to authorised users and networks, apply response-rate limiting, and use DNS firewall rules. Monitoring should cover unusual query types, source patterns and response sizes. Source address validation, commonly associated with BCP 38 and RFC 2827, reduces forged-origin traffic, although enforcement depends on networks outside your control.

Prioritise the response according to the service dependency:

• Harden recursive resolvers: Close open recursion and review public-facing configurations.
• Control responses: Rate-limit replies and investigate patterns associated with amplification.
• Coordinate upstream: Confirm available filtering, scrubbing and null-routing options with the ISP or mitigation provider.
• Protect authoritative DNS: Maintain resilient arrangements and document who can change records during an incident.

Test DNS separately from web infrastructure. The incident plan should name the DNS provider, registrar and internal owner, with clear escalation routes if records or delegation require changes.

DDoS protection identifies and filters hostile traffic. White-label dark web monitoring complements that control by alerting providers to exposed domain credentials that could enable unauthorised DNS or registrar access. It does not replace authoritative DNS resilience or traffic mitigation, but it gives service teams a separate warning signal for account exposure and a practical customer conversation.

6. NTP Amplification Attacks

Network Time Protocol supports clock synchronisation, but poorly configured public NTP services can become reflectors. In the classic form of this attack, the operator sends a request with a forged source address to an exposed NTP server. That server responds to the victim, potentially sending much more data than the attacker transmitted.

The best defence is configuration hygiene, not just a larger firewall. Disable deprecated monitoring commands such as monlist, update the NTP daemon, restrict queries to authorised clients and avoid exposing a public NTP service unless the business has a clear reason to do so. Rate limiting responses adds another layer, while central monitoring can identify unusual query volumes or sources.

Practical checks for MSP estates

NTP is easy to overlook because it usually runs in the background. Include it in infrastructure reviews, especially for older appliances, hosting environments and customer networks with internet-facing management interfaces. Verify that internal time sources are reachable by approved systems, then confirm that external systems can't use them as open reflectors.

A service that doesn't need to answer the public internet shouldn't be configured as a public service.

This vector is a useful example of why attack classification must lead to an ownership decision. Network teams handle filtering and source validation. Infrastructure teams close the exposed service. Account teams explain the business impact and document the customer's responsibility for third-party appliances.

VoIP providers should also consider how UDP-based services behave under pressure. A practical explanation of UDP roles in VoIP services helps non-specialists understand why connectionless traffic can be efficient for real-time communications but harder to distinguish from a flood. The mitigation plan should cover signalling, media paths, DNS, authentication and upstream connectivity rather than treating “the phone system” as one component.

If compromised credentials appear during the same period, treat that as a separate risk track. GoSafe's white-label Dark Web Monitoring can continuously scan email addresses, passwords and breached domains, giving a provider a simple customer-facing alert service without pretending it is NTP or DDoS protection.

7. HTTP Flood and Slowloris Attacks

A web service can appear healthy at the network edge while its application workers are already saturated. HTTP floods and Slowloris attacks both consume web capacity, but they leave different operational clues. An HTTP flood sends many apparently valid requests, often targeting pages or functions that require substantial processing. Slowloris holds connections open by delivering request data slowly, using connection slots and server resources without generating high bandwidth.

Treating both incidents as “the website is down” can send the response in the wrong direction. For an HTTP flood, review requested paths, accounts, user agents, referrers, cache status and response codes. For Slowloris, inspect open connections, incomplete headers, idle duration and web-server worker utilisation. Correlate application, reverse-proxy and operating-system logs so the provider can distinguish expensive requests from connection exhaustion.

Controls that preserve legitimate access

Start with controls that limit resource consumption without blocking genuine customers. Set connection and header timeouts, cap header sizes, and use a reverse proxy or load balancer to manage concurrent connections. Apply WAF rules with endpoint-aware rate limits. Per-user or per-account controls can be fairer than blanket IP limits where legitimate customers share addresses.

Protect the paths that cost the most to serve. Search, login, upload and API functions may need different thresholds based on processing cost and normal demand. Caching, request throttling and application optimisation should remain active during mitigation, because a challenge page alone does not reduce every form of backend work.

CAPTCHA and behavioural challenges can help separate automation from people, but they may frustrate users, create accessibility barriers and fail against advanced automation. Reserve them for sensitive or expensive operations, and monitor their effect on conversion and support volumes.

Operational checks should include:

• Tune timeouts: Close connections that make no reasonable progress.
• Protect expensive paths: Rate-limit functions according to their actual cost.
• Inspect request behaviour: Compare repeated paths, unusual headers and cache-bypassing requests.
• Preserve evidence: Retain timing, endpoint and response data for later tracing.

Public websites remain routine targets. The Office for National Statistics disclosed 15 attempted DDoS attacks in 2024 and 1 in 2025 against its website, figures that do not identify a specific HTTP technique. They still support a practical conclusion: providers need an owned detection and response process, with dark web monitoring used separately to identify exposed credentials or attack planning that DDoS controls cannot see.

8. Zero-Day DDoS Exploits and Novel Attack Vectors

A provider can see a service slow down immediately after a vendor advisory or configuration change, while familiar dashboards show no recognised DDoS signature. That pattern may indicate a zero-day DDoS exploit, although attackers often combine a new weakness with established floods, botnet traffic or application abuse.

These vectors can consume different resources. A network device may exhaust connection state, a protocol implementation may behave unexpectedly, or an exposed dependency may consume application capacity. The first task is to establish what is failing. Check traffic shape, protocol behaviour, error patterns, connection state, CPU, memory, queue depth and upstream bandwidth. Compare the change with recent patches, rules and supplier notifications.

Build resilience before the signature exists

Defence in depth reduces dependence on a detection rule arriving in time. Keep supplier contacts current, subscribe to relevant threat intelligence, maintain emergency patching procedures and give the incident team permission to alter filtering or isolate a service quickly. Application owners should document which features can be disabled temporarily without taking the wider platform offline.

Detection and response exercises should include unfamiliar traffic, incomplete indicators and pressure to protect availability before attribution. Controlled simulations can test whether staff can identify the constrained resource, apply a safe mitigation, preserve evidence and restore normal service. The NCSC response model prioritises practical actions over a perfect label at the outset, as explained in its NCSC DDoS technical note. Teams can protect the service before they know the attacker's preferred name.

Recent UK reporting also shows that campaigns can concentrate on specific endpoints. A January 2026 analysis recorded 1,812 attack entries, with 85.2% aimed at UK targets and 70.3% hitting port 443, according to one threat blog's account of a NoName057(16) campaign (UK DDoS threat intelligence analysis). Treat those figures as contextual reporting rather than a universal measure of threat. The operational response remains clear: monitor encrypted web-service exposure, confirm who owns mitigation, and prepare controls for attacks that change target or method quickly.

Dark web monitoring complements, rather than replaces, DDoS protection. It will not identify a novel packet pattern, but it can expose compromised email addresses, passwords or breached domains that increase the risk of account misuse during a wider campaign. For service providers, white-label monitoring can give customers a separate view of identity and exposure while network controls handle availability.

Comparison of 8 DDoS Attack Types

Turn DDoS Awareness Into Customer Value

DDoS protection starts with an operational distinction. Volumetric attacks consume bandwidth. Protocol attacks exhaust connection state or network-device processing. Application-layer attacks consume web, API, database or session capacity. Botnets provide distributed delivery, while DNS and NTP amplification abuse third-party services to multiply traffic. Novel vectors challenge assumptions and signatures, so response plans need enough flexibility to act before every detail is known.

Service providers can turn that distinction into a practical customer conversation. Baseline normal traffic and connection behaviour, confirm where upstream scrubbing sits, test application controls, review DNS and other shared dependencies, and document who owns each decision during an incident. A cyber risk services discussion can then connect availability controls with wider identity, endpoint and recovery responsibilities.

The UK threat environment supports a proactive approach. The NCSC reported 204 nationally significant cyber attacks against the UK in the 12 months to August 2025, compared with 89 in the previous year (NCSC denial-of-service guidance collection). The same guidance treats DDoS as a core attack vector organisations should prepare to detect, mitigate and recover from. The ICO also recorded that DDoS represented 25% of hacking incidents reported to the Financial Conduct Authority in the first half of 2022, up from 4% in 2021, while 15% of businesses in the latest UK government cyber breach survey said they had experienced a denial-of-service attack in the preceding year (SOCRadar UK Threat Landscape Report 2024).

Those figures shouldn't turn every outage into a sales pitch. They should make the service discussion more complete. Ask customers whether they know which email addresses and domains have appeared in breaches, whether exposed passwords have been reset, and who receives the alert when a credential is found. Compromised credentials can create a path into admin panels, cloud accounts, DNS providers or customer portals, even though credential exposure isn't itself a DDoS attack.

Add a service customers can understand

GoSafe is a fully white-label Dark Web Monitoring tool, not a replacement for DDoS mitigation. It continuously scans for compromised email addresses, exposed passwords and breached domains, then delivers clear, understandable alerts by email and through a simple dashboard. Its breach monitoring, risk scoring, domain monitoring, phone-number monitoring, instant breach search, redacted breach previews, breach breakdown reports and phishing simulations help providers start a practical security conversation without handing customers a complex cybersecurity suite.

For MSPs, IT support companies, telecom and VoIP providers, hosting firms, web agencies, cyber consultants and technology resellers, the commercial model is straightforward. Partners can brand the platform as their own service, sell dark web monitoring under their own brand and offer it as a monthly subscription alongside IT support, cloud services, hosting, connectivity, telecom systems or web services. GoSafe requires minimal management, no security team and no need to build security tools internally. The partner keeps the customer relationship and can add a recurring revenue security service that strengthens retention and creates proactive value.

GoSafe is designed with UK businesses in mind, is Cyber Essentials accredited and is used by organisations globally. Its alerts are intended for business users who need to know what was exposed and what to do next, not analysts who want another complicated dashboard. That makes white label dark web monitoring, dark web monitoring for MSPs and reseller dark web monitoring practical additions to an existing service portfolio.

Start by reviewing one customer segment, such as hosted businesses, SaaS users or telecom customers. Confirm which DDoS controls you already provide, identify the gaps in alert ownership, and then offer a clear credential-exposure conversation. Book a demo of GoSafe's white-label dark web monitoring and see how a dark web monitoring service for businesses can sit beside the controls you already manage.

GoSafe Dark Web Monitoring continuously scans for compromised email addresses, exposed passwords and breached domains, giving customers clear alerts that complement DDoS response planning. Visit GoSafe Dark Web monitoring to explore a simple, fully white-label service you can offer under your own brand as a monthly subscription.