Back
Botnet attack protection: stop distributed attacks at the edge
A botnet can send abusive traffic from thousands or millions of compromised devices. One address may look harmless. Together, the requests can slow your website, overload an API, test logins or hide automated abuse inside a crowd of ordinary-looking connections.
ADPAL adds application-layer filtering before that traffic reaches your origin. Your host or CDN keeps protecting network capacity. ADPAL focuses on the web, API and business-flow requests that need request-level context.
.SCALE OF THE PROBLEM
A distributed threat, not a “big target” problem
You do not need to be a famous brand. You need a public website, login, API or checkout
that automation can reach. Botnet infrastructure can move between targets and business
functions, so the same distributed traffic source may be used for availability attacks, login abuse, scanning or fraud.
For a small business, the practical question is whether the site can recognise coordinated automation, protect
expensive functions and keep genuine customers moving.
.SNIPPET DEFINITION
What is a botnet attack?
The distinction matters. A botnet describes where the traffic comes from and how it is coordinated. It does not tell you the final business goal. The same infrastructure can carry application-layer DDoS, credential attacks, scanning, spam, proxy traffic or automated commerce abuse.
A botnet attack uses a network of compromised internet-connected devices controlled remotely without their owners’ knowledge. The devices act together to flood a website, probe applications, test passwords or send other automated requests. A botnet is the delivery network; DDoS is only one attack it can deliver.
. HOW ADPAL HELPS
Reduce the automated web routes that can create the first foothold
ADPAL sits in front of your public website and filters risky automated requests before they reach the CMS or application.
Reduce reconnaissance
Systematic probing is filtered before it reaches the origin.
Block high-risk requests
Bot, WAF and rate-control policies stop dangerous traffic earlier.
Protect exposed routes
Login, CMS and application endpoints stay behind the perimeter.
.What it looks like
How a distributed bot attack can hit a
small shop
The example below is illustrative and shows a realistic attack pattern for a small online shop
Saturday, 11:20. An online furniture shop begins to slow during its busiest trading window. Thousands of IP addresses each request a small number of product, search and account pages.
Per-IP limits barely move. The addresses belong to many networks and countries. Some requests resemble browser traffic; others call APIs directly. Search and filtering pages consume the most server time, so page loads stretch from one second to nine.
The team blocks several countries and raises server capacity. The site recovers briefly, then slows again. Later analysis shows two overlapping patterns: an HTTP flood against expensive catalogue functions and distributed login attempts against customer accounts.
The shop was not necessarily breached. Its public application was being forced to do expensive work at scale. The business cost came from slower pages, failed journeys, emergency changes and customers leaving during a high-value trading window.
A botnet wave may also be quieter. Instead of taking the site fully offline, it can increase infrastructure cost,
exhaust one endpoint or reduce conversion through intermittent slowness.
. Symptoms
Signs of a botnet-driven attack
Look for distribution plus repetition. The addresses vary; the intent and request pattern remain similar.
Traffic rises across many IP addresses, networks or countries without a matching campaign, referral source or sales increase.
The same paths, parameters or API calls repeat across unrelated sessions.
A small number of expensive endpoints – search, login, filtering, checkout or API routes – consume most resources.
CPU, memory, database connections or worker queues spike while bandwidth remains moderate.
Bandwidth or packet volume rises before application metrics move, suggesting a network or transport-layer component.
Requests arrive with weak or missing browsing journeys: no product discovery, no normal navigation and no credible conversion path.
Many devices attempt only a few logins each, keeping individual IP and account rates low.
User-agent strings vary, but protocol behaviour or request sequence remains unusually consistent.
Traffic shifts rapidly between networks after blocks or limits are applied.
Your host or CDN reports DDoS activity, origin saturation or unusual cache-miss traffic.
API errors, database latency or checkout failures rise before the homepage appears fully unavailable.
Real customers report intermittent failures from specific regions or networks.
Recognise several signs? It is worth checking
Pattern to remember
One global traffic spike is not enough to diagnose a botnet. Confirm the pattern across edge logs, origin logs, application metrics and business outcomes.
.Business impact
What a botnet attack can cost your business
The visible outage is only one possible cost. Distributed automation can damage availability, infrastructure spend,
operations and customer trust at the same time.
Lost sales and enquiries
Slow pages, failed checkouts and unavailable booking forms push customers towards a competitor. Intermittent failure can be harder to notice than a complete outage.
Cloud and hosting spend
Autoscaling, database capacity, serverless execution and bandwidth can grow in response to abusive requests. Check the billing dimensions before estimating the loss.
Operational disruption
Owners and developers stop normal work to contact providers, change rules, review logs, preserve evidence and answer customers.
Collateral customer friction
Emergency country blocks, blanket CAPTCHA or aggressive limits may reduce attack traffic while also rejecting genuine users.
Origin exposure
If attackers can bypass the CDN and reach the origin directly, edge controls may be avoided and the server can still be exhausted.
Reputation and trust
Repeated downtime or unreliable checkout creates the impression that the business cannot be trusted during the moments customers need it.
Treat denial of service as a resilience problem as well as a security problem. Know which layer owns which defence, prepare the response path before an incident and measure whether genuine customers can still use the service.
.How the attack works
How a botnet attack works
The exact traffic varies, but distributed attacks usually follow the same pattern: obtain many sources, identify valuable work, distribute the requests and adapt when controls respond.
01
What happens
Build or rent botnet capacity
Compromise devices or rent access to an existing botnet through a criminal attack service
What you may see
Requests begin to appear across many unrelated networks and geographies.
02
What happens
Select the target
Map resource-heavy pages, APIs or business functions such as search, login, checkout or account actions.
What you may see
A small set of endpoints attracts disproportionate request volume or server work.
03
What happens
Distribute requests
Spread the workload so each source sends only a modest number of requests.
What you may see
Per-IP limits show little while total application load rises.
04
What happens
Adapt to controls
Change networks, paths, timing or request patterns after blocks, limits or cache changes are introduced.
What you may see
Traffic moves rather than stopping after one tactical rule.
05
What happens
Sustain or mix workloads
Maintain the expensive request pattern or combine availability pressure with login abuse, scanning or other automation.
What you may see
The site may remain slow while repeated business-flow activity continues in parallel.
Common workloads a botnet can carry
Application-layer DDoS
HTTP requests target resource-heavy pages, APIs or actions. Volume can be lower than a network flood but expensive for the origin to process.
Network and transport DDoS
Packets or connections exhaust bandwidth, network devices or transport capacity. This normally requires upstream provider or specialist mitigation.
Distributed credential attacks
Password guessing or stolen-password testing is spread across many sources and accounts to evade simple limits.
Checkout and payment abuse
Distributed traffic can support card testing, scalping, fake account creation or other automated commerce abuse.
Scanning and exploit delivery
Bots probe CMS, plugins, admin routes and APIs for vulnerable versions or exposed functions.
Spam and proxying
Compromised devices can send spam or relay traffic so another attack appears to come from ordinary consumer connections.
Botnet attack vs DDoS
A botnet is infrastructure; DDoS is an availability objective. Layer 3/4 attacks target bandwidth, packets or connections and need upstream capacity. Layer 7 attacks target HTTP pages and APIs, while business-flow abuse targets valid functions such as login or checkout. The same distributed network can deliver any of them.
Credential stuffing protection →
.How ADPAL prevents it
How ADPAL filters distributed application traffic
IP reputation alone is weak against botnets and proxy networks. A compromised residential connection can have no previous bad reputation, while a genuine customer may share an address with many other users.
ADPAL uses Advanced detection to evaluate behaviour, browser characteristics, network context, request sequence and endpoint activity together. The decision does not rely on one IP address or a claimed browser identity.
High-confidence malicious automation can be blocked or limited before it reaches the origin. Most genuine users continue normally. Adaptive CAPTCHA appears only in rare, uncertain cases.
For Layer 7 floods, early filtering can reduce origin CPU, database work and application queue pressure. For distributed login or checkout abuse, it adds request and workflow context that a simple per-IP threshold cannot provide.
No system should rely on one signal or promise perfect separation. Monitoring, allowlists, conservative policy and business-outcome review remain necessary. Keep origin lock-down, caching, upstream DDoS protection, secure application design and incident response in place.
01
Observe the page, API or business flow being requested.
02
Compare behaviour, browser, network and request-sequence context with normal traffic.
03
Connect repeated patterns across requests, networks and protected endpoints.
04
Apply the configured action before high-risk automation triggers expensive origin work.
05
Review outcomes, authorised automation and policy exceptions during monitoring and enforcement.
. DIY vs. perimeter
What you can do yourself – and
where each measure helps
Measure
Helps?
The practical limit
Host / CDN DDoS protection
Essential
Can cover L3/L4 and often L7, depending on the plan. Confirm protected hostnames, APIs, capacity and activation model.
Lock the origin to the edge
Essential
Prevents direct origin bypass. Requires firewall, network or authenticated-origin configuration.
Caching and static delivery
Strong for cacheable traffic
Reduces origin work. Login, search, checkout and personalised APIs still need protection.
Per-route rate limiting
Partly
Stops noisy clients or bursts. A distributed attack can keep each source below a simple threshold.
Multi-dimensional limits
Useful
Combine network, account, endpoint and request-pattern context. Thresholds still need tuning and safe fallbacks.
WAF rules
Important layer
Strong against exploit patterns and policy violations. Valid-looking Layer 7 floods and business-flow abuse need behavioural context.
CAPTCHA / challenge
Selective layer
Can increase attacker cost on suitable web flows. Blanket use can hurt accessibility, conversion and APIs.
Bigger server / autoscaling
Resilience layer
Buys headroom but can increase cost. It does not identify abusive traffic.
Disable expensive features
Temporary response
Reducing optional resource-heavy functions can preserve core service during an incident, but the business impact must be understood.
Perimeter bot filtering
Application layer
Evaluates distributed requests before expensive origin work. It still needs upstream DDoS protection and response planning.
Actionable first step today
Ask your provider: “Which Layer 3, Layer 4 and Layer 7 attacks does my current plan cover, and can the origin be reached without passing through it?” If the attack is active now, contact the upstream provider, preserve edge and origin logs, confirm the origin is locked down and apply narrow temporary controls to the affected routes.
Built for small teams
Built for small teams that need resilience
without a dedicated SOC
Protect the relevant website, API and business-flow endpoints routed through ADPAL. Confirm exact coverage for the deployed architecture.
Evaluate behaviour, browser, network, request sequence and endpoint patterns instead of trusting one IP decision.
Monitor, allow, limit, challenge or block according to confirmed policy options and confidence.
Protect login, search, forms, checkout, APIs and admin paths according to their business value and risk.
Keep legitimate search engines, integrations and internal services working through defined policies and allowlists.
Reject high-risk requests before they trigger expensive application, database or API work.
Pair application filtering with the host, CDN, WAF, upstream DDoS service and secure origin configuration.
Point your DNS at the managed reverse proxy – live in hours, then a short monitoring period before enforcing. CMS-integrated deployment is available through hosting partners.
Privacy at a glance: Cookieless, no cross-site tracking profiles, EU (Frankfurt) data residency. One product can also address scraping, fake accounts, credential attacks and checkout abuse on the same protected environment. Explore Bot Protection →
.Proof
Proof that belongs
on this page
.Learn more
Go deeper on botnets and distributed attacks
Guide
DDoS attacks: how they work and how to mitigate them
Guide
Bot attack symptoms – and what to do
Guide
Application-layer vs network DDoS
.FAQ
Questions about botnet attack protection
What exactly is a botnet?
A botnet is a group of internet-connected devices compromised by malware or another unauthorised mechanism and controlled remotely. Devices can include routers, cameras, computers, servers and other connected equipment.
Is a botnet attack the same as a DDoS attack?
No. A botnet is attack infrastructure. DDoS is one workload that infrastructure can deliver. Botnets can also carry password attacks, scanning, fraud, spam or proxy traffic.
What is the difference between Layer 7 and Layer 3/4 DDoS?
Layer 3 and Layer 4 attacks target network and transport capacity such as packets, bandwidth or connections. Layer 7 attacks target HTTP pages, APIs and application work. Confirm which layers your provider actually covers.
Does my host or CDN already protect me?
Possibly. Many hosts, CDNs and WAF platforms provide strong DDoS protection. Check whether it is always on, which hostnames and APIs are covered, whether the origin can be bypassed and what happens during an active event.
Why are IP blocklists not enough?
A distributed attack can use many addresses, and compromised consumer connections may have no previous bad reputation. Tactical blocking can help during an incident, but IP reputation alone cannot identify coordinated behaviour across many individually quiet sources.
Can a WAF stop a botnet?
A WAF can stop requests that match exploit or policy rules, and some platforms also include bot and DDoS capabilities. A basic rule set may miss valid-looking HTTP floods or distributed business-flow abuse, so compare the actual enabled controls.
Can a small website really be targeted?
Yes. Reusable botnets and attack-for-hire services lower the barrier. A small site is not automatically the preferred target, but public endpoints, weak resilience or easily automated workflows can still create an opportunity.
Will blocking botnet traffic affect real customers?
It can if controls are too broad. Country blocks, aggressive limits and automated classification all carry false-positive risk. Reduce that risk with monitoring, endpoint-specific policy, allowlists, conservative thresholds and fast rollback.
How do I know whether traffic is a botnet or a residential proxy network?
From the target’s perspective, attribution may be uncertain. Both can distribute traffic through consumer networks. Protect the service based on abusive behaviour first; definitive attribution may require provider intelligence or malware evidence.
What should I do if the attack is happening now?
Contact the upstream provider, activate the response plan, preserve logs, lock down the origin and apply narrow temporary controls. Reduce expensive optional functions if needed and monitor login, payment, API and administrative activity.
Can ADPAL replace upstream DDoS protection?
No. Application-layer filtering cannot substitute for network capacity and upstream mitigation against volumetric Layer 3/4 floods. The intended model is layered: upstream protection, ADPAL for supported application and business-flow traffic, and secure origin controls.
How should I measure whether protection worked?
Measure availability, error rate, origin CPU, database latency, cache performance, malicious requests filtered, genuine conversion and time to recovery. Record the attacked layers and endpoints; request volume alone does not show whether customers could still use the service.
Should I use CAPTCHA during a botnet attack?
A selective challenge can raise attacker cost on some browser flows, but it is not suitable for every API and should not be the entire incident response. Blanket CAPTCHA can create accessibility, conversion and support problems. Keep upstream DDoS mitigation, endpoint controls and narrow risk-based policy.
Thousands of sources. One application defence layer.
A botnet wins when every source is judged in isolation. Protection improves when the site can recognise coordinated
behaviour across requests and business flows.
Map your current coverage, find the endpoints doing the expensive work and add application-layer filtering
before the next wave reaches the origin.
No credit card
Cookieless, no cross-site tracking profiles, EU (Frankfurt) data residency