{"id":10269,"date":"2026-07-23T05:03:43","date_gmt":"2026-07-23T05:03:43","guid":{"rendered":"https:\/\/www.neelnetworks.com\/blog\/?p=10269"},"modified":"2026-07-23T05:55:49","modified_gmt":"2026-07-23T05:55:49","slug":"protect-business-website-from-ddos-attacks","status":"publish","type":"post","link":"https:\/\/www.neelnetworks.com\/blog\/protect-business-website-from-ddos-attacks\/","title":{"rendered":"How to Protect Your Business Website from DDoS Attacks"},"content":{"rendered":"
\n

DDoS attacks sit in an odd spot in the business website security conversation \u2014 talked about constantly by security vendors trying to sell enterprise protection, dismissed as “not a real concern for small businesses” by general business content that doesn’t want to seem alarmist, and rarely covered honestly by anyone with no incentive either way. The honest picture is somewhere in between: DDoS attacks against small business websites do happen more often than most owners realise, they can produce real damage when they occur, and \u2014 importantly \u2014 most of the protection any business site actually needs is available free through tools like Cloudflare that a lot of businesses already have partial access to but don’t fully configure. Enterprise-tier DDoS protection exists and is genuinely necessary for specific high-value targets, but for the majority of business websites, it’s overprovisioning for a threat model that free tools already handle well.<\/p>\n

This guide is the honest version of DDoS protection \u2014 not the “you’ll be attacked any minute so buy our enterprise plan” version, but also not the “small businesses don’t need to worry about this” version that misses the reality of what actually happens. We build websites for businesses across the spectrum from small service providers to complex platforms, and the DDoS protection reality is largely consistent across the range. If you want the broader context of how DDoS protection sits within ongoing website care alongside monitoring, backups and maintenance, our complete website maintenance guide<\/strong><\/a> is the wider reference. For the broader picture of website security beyond just DDoS, our complete website security and SSL\/HTTPS guide<\/strong> covers the wider security context. This article focuses tightly on DDoS specifically \u2014 what the threat actually is, how to protect against it appropriately (which is often free), and what to do if an attack happens.<\/p>\n

\"DDoS<\/p>\n

What a DDoS attack actually is, in plain English<\/h2>\n

A DDoS attack (Distributed Denial of Service) is what happens when an attacker sends far more traffic to your website than it can handle, from many different sources at once, with the goal of making the site unavailable to legitimate visitors. The “distributed” part is what makes it different from a simple overload \u2014 the attack comes from thousands or millions of different sources rather than one, which makes it harder to just block the attacker’s IP address because there isn’t one attacker’s IP address to block.<\/p>\n

The real-world analogy that captures it well: imagine a physical shop with one door. A DDoS attack is the equivalent of thousands of people showing up simultaneously and crowding into the doorway, not actually buying anything, but blocking real customers from getting in. The shop is technically still open, but functionally closed for business. Kicking out one person doesn’t help because there are thousands more behind them. The only real defence is either a bigger doorway (more capacity than the crowd can consume) or a bouncer that can distinguish real customers from the crowd (filtering).<\/p>\n

DDoS attacks come in three main technical categories that matter for understanding defence. Volume-based attacks try to saturate your internet connection with sheer bandwidth \u2014 UDP floods, ICMP floods, amplification attacks. Protocol attacks exploit weaknesses in how servers handle network protocols \u2014 SYN floods, Ping of Death, fragmented packet attacks. Application-layer attacks target the specific applications running on your server \u2014 HTTP floods, slowloris attacks, form submission floods that look like legitimate requests but are designed to consume application resources. Each type requires slightly different defence strategies, though modern DDoS protection tools handle all three categories reasonably well as a package.<\/p>\n

How common are DDoS attacks against business websites?<\/h2>\n

Being honest about the actual threat frequency matters because both the “you’ll definitely be attacked” scare narrative and the “small businesses don’t need to worry” dismissal miss the reality.<\/p>\n

DDoS attacks against small and mid-sized business websites happen more frequently than most owners assume. The rise of “DDoS-for-hire” services (called “booter” or “stresser” services) has made basic DDoS attacks available to anyone with $10-50 and a grievance \u2014 competitors, disgruntled former employees, extortionists, or just teenagers with a grudge. Industry reports consistently show that businesses across all sizes experience DDoS attempts, though most small business attacks are relatively small (a few thousand requests per second sustained for minutes to hours rather than the massive multi-terabit attacks that make news headlines).<\/p>\n

The specific motivations vary. Competitive sabotage is more common than businesses realise \u2014 a competitor paying $20 to a booter service to take your site down during your promotional launch is a real thing that happens. Extortion attempts follow a pattern of small demonstration attacks followed by “pay us or we’ll do it worse” demands. Ideological or political motivations produce attacks against businesses whose positioning offends someone. Sometimes attacks are purely opportunistic \u2014 automated scans identify vulnerable sites and attack them for practice or bot herding.<\/p>\n

The good news is that the majority of attacks against small business sites are relatively unsophisticated \u2014 often just paid booter service traffic rather than genuinely sophisticated attacks \u2014 and these attacks are precisely what free DDoS protection handles well. Sophisticated persistent attacks against high-value targets are a different threat category that warrants enterprise protection, but this category is much smaller than security marketing suggests.<\/p>\n

What a DDoS attack looks like from your perspective<\/h2>\n

Recognising an attack in progress matters because response depends on knowing what’s actually happening. The signature of DDoS varies but usually includes several of these signals.<\/p>\n

The site becomes slow or unreachable for legitimate visitors. What was loading normally an hour ago now takes 30 seconds or times out entirely. Your monitoring alerts fire (if you have monitoring \u2014 many businesses don’t). Server load metrics spike dramatically \u2014 CPU pegged at 100%, RAM exhausted, database connections maxed out. Your hosting provider may automatically null-route the traffic to protect their other customers, which effectively takes your site offline as a defensive measure. Log files show a massive spike in requests, often from patterns that look automated \u2014 the same URL requested thousands of times per second, unusual user-agent strings, geographic distribution that doesn’t match your normal traffic.<\/p>\n

Duration varies enormously. Small paid booter attacks typically last minutes to a few hours \u2014 the attacker’s money runs out or the attack tool’s timer expires. Sophisticated attacks can last days with attackers adapting to defensive measures. Sustained persistent attacks against high-value targets sometimes go on for weeks with escalating intensity, though these are rare against typical business sites.<\/p>\n

Recovery isn’t always immediate. Even after the attack traffic stops, your server may need time to work through queued requests, restart services, and return to normal operation. If your hosting provider null-routed the site, restoring service requires their intervention and can take hours. If Google noticed the outage during the attack, temporary ranking effects may persist for days as the algorithm processes the availability signal.<\/p>\n

The three main types of DDoS attacks explained<\/h2>\n

Understanding the three main attack categories helps because different defences work against different types. Modern DDoS protection tools handle all three as a package, but knowing what they’re actually blocking helps you evaluate whether your protection is genuinely comprehensive.<\/p>\n

\"Three<\/p>\n\n\n\n\n\n\n\n
Attack type<\/th>\nWhat it targets<\/th>\nExamples<\/th>\nPrimary defence<\/th>\n<\/tr>\n<\/thead>\n
Volume-based<\/td>\nYour bandwidth capacity<\/td>\nUDP floods, ICMP floods, DNS amplification<\/td>\nCDN absorption and filtering<\/td>\n<\/tr>\n
Protocol attacks<\/td>\nServer networking resources<\/td>\nSYN floods, Ping of Death, fragmented packets<\/td>\nNetwork firewall and protocol filtering<\/td>\n<\/tr>\n
Application-layer<\/td>\nWeb application resources<\/td>\nHTTP floods, slowloris, form submission floods<\/td>\nWeb Application Firewall and rate limiting<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Application-layer attacks are the most sophisticated category and the hardest to defend against because the traffic looks legitimate \u2014 it’s just HTTP requests to real URLs, indistinguishable at the packet level from real user visits. Effective application-layer defence requires understanding the specific application being defended and configuring intelligent rules that distinguish attack patterns from normal usage. Volume and protocol attacks are more easily blocked by generic infrastructure because the traffic patterns are obviously abnormal.<\/p>\n

How much does a DDoS attack actually cost your business?<\/h2>\n

Being specific about the business cost matters because it determines how much investment in prevention is warranted. The costs come in several categories.<\/p>\n

Direct revenue lost during downtime.<\/strong> If your site is unreachable for 6 hours during a DDoS attack, you lose the revenue that would have happened during those 6 hours plus a portion of the visitors who tried to reach you and gave up. For a business generating $10,000 monthly revenue with even distribution, 6 hours of downtime is roughly $80 in direct lost revenue plus indirect losses from customers who don’t return. For higher-revenue eCommerce during promotional periods or peak hours, the direct cost scales substantially.<\/p>\n

Reputation and trust damage.<\/strong> Customers who experience your site being down interpret it as a reliability signal \u2014 even when they intellectually understand DDoS attacks aren’t your fault. Repeat visits from those customers may decline permanently. B2B customers evaluating you as a vendor may reconsider if downtime becomes visible during their evaluation. The compound effect over time is real but hard to quantify.<\/p>\n

SEO impact.<\/strong> Google’s crawlers notice when your site is unreachable and adjust rankings based on availability signals over time. Extended outages produce measurable ranking losses that take weeks to recover from. If the attack happens during a period when Google is actively crawling changes to your site, the timing can be particularly bad for search visibility.<\/p>\n

Recovery costs.<\/strong> Post-attack analysis, log review, security consultant engagement, potential hosting escalation to premium tiers, and infrastructure hardening all cost money. Small business recovery costs typically run $500-5,000 depending on the attack severity and what needs to be strengthened. Larger enterprises can spend $10,000-100,000+ on comprehensive incident response and mitigation.<\/p>\n

Insurance and compliance implications.<\/strong> Some cyber insurance policies require documented DDoS protection as a coverage condition. Regulated industries may have compliance frameworks that require specific incident response documentation after attacks. These aren’t always visible until you need them.<\/p>\n

For a typical small business site, the total cost of a modest DDoS attack often runs $1,000-10,000 across all these dimensions combined. The good news is that most of this cost is preventable with free DDoS protection that takes an hour to set up.<\/p>\n

The good news: 95% of protection is free and takes an hour to set up<\/h2>\n

Here is the specific claim most security vendor content avoids: for the vast majority of business websites, the DDoS protection needed is available free through Cloudflare (or equivalent services like Bunny.net or Fastly’s free tier), and setting it up takes about an hour of work. This isn’t a low-quality free option that’s marginal compared to paid alternatives \u2014 Cloudflare’s free DDoS protection is genuinely excellent and blocks the vast majority of attacks that small and mid-sized business sites actually experience.<\/p>\n

What Cloudflare’s free tier actually provides.<\/strong> Unmetered DDoS protection at the network layer \u2014 Cloudflare absorbs volume-based attacks by using their global network capacity, which is measured in terabits per second. Basic Web Application Firewall (WAF) that filters common attack patterns. Global CDN that improves performance as a bonus effect. Free SSL certificates that eliminate one attack vector. Basic rate limiting through Cloudflare’s automatic protection. DNS-level protection that hides your origin server IP address, meaning attackers can’t bypass Cloudflare by attacking your server directly.<\/p>\n

How it works technically.<\/strong> When you sign up for Cloudflare and change your domain’s nameservers to point at Cloudflare, all traffic to your site flows through Cloudflare’s network before reaching your origin server. Cloudflare filters attack traffic at their edge, absorbs volume-based attacks in their massive network capacity, and forwards only legitimate traffic to your origin. Your origin server never sees the attack traffic because Cloudflare handles it before the traffic reaches you.<\/p>\n

What it doesn’t include (in the free tier).<\/strong> Advanced WAF rules and custom rate limiting (available in Pro tier at $20\/month). Detailed analytics on attack patterns (Pro+ tiers). Advanced bot management (Business\/Enterprise tiers). SLA guarantees and priority support (Enterprise). For most small business sites, none of these limitations affect the core DDoS protection quality \u2014 the free tier’s DDoS mitigation is essentially the same as the Enterprise tier’s mitigation for standard attacks.<\/p>\n

Why every business site should have Cloudflare (or equivalent).<\/strong> The cost is $0. The setup time is roughly an hour. The protection blocks the majority of attacks that small business sites actually face. The performance benefits (CDN, caching) are meaningful side effects. There is genuinely no downside to configuring this properly, and yet a significant portion of small business sites don’t have it set up. If you take one action from this article, this is it.<\/p>\n

\n The single highest-impact free step for DDoS protection:<\/strong> put your site behind Cloudflare’s free tier. It takes about an hour to set up (mostly waiting for DNS propagation), costs $0, and provides genuine DDoS protection at network scales that would cost thousands of dollars per month to build yourself. If your site is not currently behind Cloudflare or equivalent CDN with DDoS protection, this is the first thing to fix regardless of any other security investment you’re considering. Every serious business site should have this configured as baseline infrastructure, not as premium protection.\n <\/div>\n

The seven-step DDoS protection framework<\/h2>\n

Comprehensive DDoS protection layers multiple defences that work together. The framework below covers the practical layers most business sites should implement, in the order to build them.<\/p>\n

    \n
  1. \n
    \n Set up Cloudflare (or equivalent CDN with DDoS protection)<\/strong>
    \n Sign up for Cloudflare’s free tier and change your domain’s nameservers to point at Cloudflare. Configure the SSL\/TLS mode to Full (Strict) if you have SSL on your origin server, or install Cloudflare’s Origin Certificate on your server. Enable Always Use HTTPS to redirect all traffic to encrypted connections. This one step provides the majority of DDoS protection most business sites need and takes an hour to complete. If you don’t do anything else on this list, do this.\n <\/div>\n<\/li>\n
  2. \n
    \n Enable rate limiting on critical endpoints<\/strong>
    \n Rate limiting prevents attackers from hammering specific endpoints \u2014 login pages, contact forms, checkout pages, API endpoints \u2014 with request volumes that overwhelm your application even when the total site traffic looks manageable. Cloudflare’s free tier includes basic rate limiting rules. Configure rules for your login page (limit to 5 attempts per minute per IP), contact form (limit to 10 submissions per hour per IP), and any API endpoints that could be abused. These rules prevent application-layer attacks that CDN-level protection alone doesn’t fully address.\n <\/div>\n<\/li>\n
  3. \n
    \n Configure a Web Application Firewall (WAF)<\/strong>
    \n A WAF filters traffic based on rules that identify common attack patterns \u2014 SQL injection attempts, cross-site scripting, known malicious user agents, requests targeting known vulnerabilities in specific software. Cloudflare’s free tier includes basic WAF rules; Pro tier at $20\/month adds much more sophisticated rules that make a real difference against application-layer attacks. Alternatively, plugin-based WAFs for WordPress (Wordfence, Sucuri) provide origin-level WAF that complements Cloudflare’s network-level filtering. Layered WAF at both the network and application levels is meaningfully stronger than either alone.\n <\/div>\n<\/li>\n
  4. \n
    \n Harden your hosting-level security<\/strong>
    \n Regardless of CDN protection, the hosting itself needs to be reasonably secure so that if attackers do bypass your primary defences, damage is minimised. Modern PHP versions (8.2+), current WordPress core if you’re on WordPress, updated plugins and themes, restricted file permissions, and disabled unused services all matter. The specific hosting tier you’re on also matters \u2014 cheap shared hosting struggles more under attack conditions than quality VPS. For the specific relationship between hosting quality and site resilience, our piece on why your website is slow and it’s probably your hosting<\/strong><\/a> covers the fundamentals.\n <\/div>\n<\/li>\n
  5. \n
    \n Set up monitoring and alerts<\/strong>
    \n You need to know when your site is under attack, ideally before customers notice. Set up uptime monitoring (UptimeRobot free tier, Pingdom, or hosting-provided monitoring) that alerts you when the site is unreachable. Enable Cloudflare’s email alerts for unusual traffic patterns. Configure Google Search Console to notify you of crawl errors that might indicate availability problems. The specific configuration matters less than having some form of monitoring that surfaces attacks quickly enough to respond.\n <\/div>\n<\/li>\n
  6. \n
    \n Prepare an incident response plan<\/strong>
    \n Before an attack happens, know what you’ll do when one does. Document the steps: who has access to which defensive systems, what the escalation procedure is, how you’ll communicate with users during downtime, what emergency Cloudflare settings you’ll enable (Under Attack Mode is one click). The specific steps matter less than having them documented so you’re not making decisions under pressure during an actual attack. A 30-minute planning session prevents hours of panic later.\n <\/div>\n<\/li>\n
  7. \n
    \n Test your defences periodically<\/strong>
    \n Once a year, review your defensive posture. Are the WAF rules still appropriate? Are the rate limits still calibrated correctly? Are the monitoring alerts still routed to someone who checks them? Are the emergency response procedures still documented in a place you can find during a crisis? Defensive infrastructure decays without attention, and the annual review catches drift before it matters. For businesses running under structured     website maintenance services<\/strong><\/a>, this review happens as part of ongoing care rather than as a discrete annual event.\n <\/div>\n<\/li>\n<\/ol>\n
    \n

    Want Help Setting up Proper DDoS Protection for Your Business Site?<\/strong><\/p>\n

    If you would rather have an experienced team configure Cloudflare, set up rate limiting, harden your hosting security, and document your incident response plan \u2014 including the ongoing monitoring that catches attacks early \u2014 we handle this end-to-end as part of website security engagements. Most sites reach genuinely strong DDoS protection through a combination of free tools and a few hours of professional configuration.<\/p>\n

    \n Request a security audit<\/a> Message on WhatsApp<\/a>\n <\/div>\n<\/p><\/div>\n

    Cloudflare vs enterprise DDoS protection: when do you need more?<\/h2>\n

    The step up from free\/Pro Cloudflare to enterprise DDoS protection is meaningful in cost and capability. Understanding when each is warranted prevents both overprovisioning at small business scale and underprovisioning at enterprise scale.<\/p>\n

    Cloudflare Free tier ($0\/month).<\/strong> Unmetered DDoS protection, basic WAF, SSL, CDN, DNS management. This is genuinely all the DDoS protection most small business websites need. If your site isn’t specifically targeted by sophisticated attackers, free tier handles what you’ll actually face.<\/p>\n

    Cloudflare Pro tier ($20\/month per domain).<\/strong> Enhanced WAF with more rules, image optimisation, mobile optimisation, priority support for issues. The DDoS protection quality is essentially the same as free tier for standard attacks; you’re paying for the better WAF and additional features. For business sites that want stronger application-layer protection, Pro is a reasonable upgrade.<\/p>\n

    Cloudflare Business tier ($200\/month per domain).<\/strong> Bot management, prioritised routing, custom WAF rules, PCI compliance features, image polishing. This tier makes sense for higher-value business sites that need more sophisticated protection but don’t yet require enterprise features.<\/p>\n

    Cloudflare Enterprise (starts around $2,000-5,000\/month).<\/strong> Custom pricing based on requirements, dedicated support, SLA guarantees, advanced bot management, real-time analytics, comprehensive DDoS mitigation with L3\/L4\/L7 protection, custom rules and rate limiting. This is where “enterprise DDoS protection” typically starts.<\/p>\n

    Alternative enterprise providers.<\/strong> AWS Shield Advanced ($3,000\/month plus data transfer), Google Cloud Armor (usage-based), Akamai (custom enterprise pricing typically $5,000-50,000+ per month), Imperva (similar enterprise pricing). These serve high-value targets with sophisticated attack profiles and typically require enterprise-scale infrastructure to justify.<\/p>\n

    When enterprise protection is warranted.<\/strong> Very high-value targets where attacks are frequent and sophisticated \u2014 major eCommerce, financial services, healthcare platforms, gaming platforms, popular publishers. Businesses with regulatory requirements that mandate specific DDoS protection standards. Sites with revenue high enough that even brief outages represent significant financial impact. Situations where you’ve already experienced sophisticated attacks that free tier didn’t handle adequately. For businesses that aren’t in these categories, enterprise DDoS protection is genuine overprovisioning that doesn’t produce proportional benefit.<\/p>\n

    Hosting-level DDoS mitigation: what your host actually provides<\/h2>\n

    Beyond CDN-based protection, your hosting provider has some level of DDoS response capability \u2014 but understanding what they actually do (and don’t do) matters because it’s rarely a substitute for proper CDN protection.<\/p>\n

    Shared hosting DDoS response.<\/strong> Cheap shared hosts typically respond to DDoS attacks by null-routing the affected customer’s traffic \u2014 effectively taking your site offline as a defensive measure to protect their other customers on the same infrastructure. This is defensive for them, catastrophic for you. Your site is unreachable for however long it takes them to determine the attack has stopped, which can be hours or days depending on the host. This is one of the many hidden costs of cheap hosting that most businesses don’t discover until they need real protection.<\/p>\n

    VPS providers with DDoS protection.<\/strong> Better VPS providers (OVH, Hetzner, some DigitalOcean tiers) include DDoS protection as a feature \u2014 typically absorbing attacks up to specific bandwidth thresholds before escalating. The protection quality varies by provider and price tier, but it’s meaningfully better than no protection. However, it’s still not a substitute for CDN-level protection because the attack traffic still has to reach the provider’s network.<\/p>\n

    Managed WordPress hosting DDoS features.<\/strong> WP Engine, Kinsta, Flywheel, and similar premium managed hosts typically include Cloudflare Enterprise-level DDoS protection as part of the hosting fee. This is one of the specific value propositions of premium managed hosting \u2014 you’re paying for infrastructure that includes sophisticated protection you’d otherwise need to source separately.<\/p>\n

    Why hosting alone usually isn’t sufficient.<\/strong> Even with hosting-level DDoS protection, the attack traffic reaches your hosting provider’s network before being filtered, which means the initial bandwidth impact and any latency from attack detection affects your site. CDN-level protection (like Cloudflare in front of your host) filters attack traffic at the edge before it ever reaches your hosting infrastructure, which produces meaningfully better protection outcomes. The combination of CDN-level protection plus hosting-level protection is stronger than either alone, which is why layered defence is the recommended architecture.<\/p>\n

    \n The DDoS protection mistake most businesses make:<\/strong> assuming their hosting provider will handle DDoS attacks for them. Cheap hosting will typically null-route you to protect their infrastructure, which achieves their goal but leaves your site offline. Even quality hosting with DDoS features rarely provides protection equivalent to CDN-level filtering. If your DDoS protection strategy is “our host will handle it”, your protection is meaningfully worse than it needs to be. Cloudflare in front of any hosting is the standard architecture for good reason \u2014 it’s genuinely better than any hosting-only approach, it’s usually free at the tier most businesses need, and it takes an hour to set up.\n <\/div>\n

    WordPress-specific DDoS considerations<\/h2>\n

    WordPress powers a large portion of business websites and has some specific attack surfaces that generic DDoS advice doesn’t fully address. Understanding these matters for the roughly 40% of business sites running on WordPress.<\/p>\n

    XML-RPC exploitation.<\/strong> WordPress’s XML-RPC endpoint (xmlrpc.php) has been a common DDoS target because it can be used for pingback amplification attacks \u2014 small requests that trigger disproportionately large operations on the server. If you’re not using XML-RPC (most sites aren’t for anything critical), disable it entirely through a plugin or in .htaccess. This closes one significant attack vector completely.<\/p>\n

    WordPress admin brute force attacks.<\/strong> The \/wp-admin and \/wp-login.php endpoints are constant targets for automated brute force login attempts that combine with DDoS techniques. Rate limiting these endpoints aggressively (5 attempts per minute per IP is reasonable), enforcing strong passwords, enabling two-factor authentication, and considering changing the login URL through a security plugin all reduce this specific vulnerability. Proper WordPress development<\/strong><\/a> should include these protections as standard rather than as security upgrades.<\/p>\n

    REST API abuse.<\/strong> WordPress’s REST API endpoints can be abused for content scraping, user enumeration, and DDoS amplification. Restricting REST API access to authenticated users (or specific IP ranges) where possible reduces the attack surface. Rate limiting the REST API prevents abuse while allowing legitimate application access.<\/p>\n

    Comment spam floods.<\/strong> WordPress comment forms are common targets for automated spam floods that can consume server resources even without being classic DDoS attacks. Enabling Akismet or similar anti-spam, requiring authentication for commenting, or disabling comments entirely (if appropriate for your site) all mitigate this.<\/p>\n

    Specific plugin recommendations.<\/strong> Wordfence Security includes application-layer DDoS protection, rate limiting, WAF rules, and login security. Sucuri Security provides similar protection with different strengths. Both plugins are worth installing on any serious WordPress business site alongside Cloudflare or equivalent CDN \u2014 plugin-level protection complements network-level protection rather than replacing it.<\/p>\n

    What to do DURING an active DDoS attack<\/h2>\n

    Recognising an attack in progress and responding effectively matters, and the specific steps below cover what to actually do rather than what to panic about.<\/p>\n

    Don’t panic \u2014 first confirm it’s actually a DDoS attack.<\/strong> Not every traffic spike is a DDoS attack. A legitimate spike from press coverage, viral social media, or a marketing campaign looks similar in some ways but has different response requirements. Check your traffic sources \u2014 legitimate spikes come from diverse organic sources with normal user-agent patterns and reasonable request patterns. DDoS traffic comes from unusual geographic distributions, has repetitive patterns, uses suspicious user agents, and targets specific endpoints repeatedly. The confirmation takes 5 minutes and prevents wrong-response actions.<\/p>\n

    Enable emergency protection settings.<\/strong> If you’re on Cloudflare, enable Under Attack Mode (one click in the security settings dashboard). This shows a brief JavaScript challenge to visitors, which stops most bot-driven attacks immediately while allowing real users to continue accessing the site with a few seconds of delay. This is often enough to end the attack because most attackers move to easier targets when their attack traffic stops working. If you’re not on Cloudflare, enable equivalent emergency protection features in your existing WAF or CDN.<\/p>\n

    Contact your hosting and CDN support.<\/strong> Alert your hosting provider that you’re under attack \u2014 even if their standard response is unlikely to help significantly, they need to know so they don’t null-route you unnecessarily. If you’re on Cloudflare Pro or higher, contact their support to escalate the issue. Enterprise CDN customers have dedicated response teams that can provide real-time assistance.<\/p>\n

    Communicate with users if the attack is significant.<\/strong> If the attack is causing extended downtime that customers are noticing, post a brief message on social media acknowledging technical difficulties. Transparency during downtime maintains trust better than silence. Don’t necessarily identify it as a DDoS attack publicly \u2014 “technical difficulties” is usually more appropriate \u2014 but let customers know you’re aware and working on it.<\/p>\n

    Preserve logs for post-attack analysis.<\/strong> The specific patterns of the attack \u2014 IP sources, targeted URLs, request patterns \u2014 are useful for strengthening defences after the attack ends. If your server is logging normally, preserve those logs. If your CDN provides attack analytics, capture them. This information informs the post-attack response plan.<\/p>\n

    \"Active<\/p>\n

    What to do AFTER a DDoS attack<\/h2>\n

    The response after the attack is often more important than the response during \u2014 the after-work is what prevents the next attack from being similarly successful.<\/p>\n

    Post-mortem analysis.<\/strong> Once the attack has ended and the site is stable, analyse what happened. What type of attack was it? What patterns did it use? What defences held up and which didn’t? Which of your endpoints were targeted? The specifics inform whether your current defences need strengthening.<\/p>\n

    Strengthen defences based on attack patterns.<\/strong> If the attack targeted specific endpoints, add more aggressive rate limiting to those endpoints. If it used specific attack signatures, add WAF rules to block those signatures. If it exposed hosting-level weaknesses, address those. The post-attack strengthening is where the incident becomes useful \u2014 you now know what you specifically need to defend against.<\/p>\n

    Update your incident response plan.<\/strong> Document what worked and what didn’t during the response. Update contact information if any escalation paths didn’t work as expected. Note any tools or processes that would have helped but weren’t in place. The response plan improves with each real incident.<\/p>\n

    Consider whether to report to authorities.<\/strong> Small-scale attacks against small businesses typically don’t warrant law enforcement engagement, but sustained sophisticated attacks or attacks that appear to be extortion attempts may. Some jurisdictions have cybercrime reporting mechanisms specifically for DDoS attacks. The decision depends on attack severity, whether you have information about the attackers, and your local legal framework.<\/p>\n

    Communicate with affected users if appropriate.<\/strong> If the attack caused visible customer impact \u2014 abandoned checkouts, failed transactions, missed deadlines \u2014 consider proactive communication acknowledging the incident. Transparent post-incident communication builds trust better than pretending nothing happened.<\/p>\n

    Backup verification.<\/strong> Confirm your backups are still working and current. DDoS attacks sometimes coincide with other attack vectors, and having verified recent backups is defensive coverage against any data manipulation that might have accompanied the DDoS. The broader picture of backup discipline as recovery infrastructure is covered in our piece on the 3-2-1 backup strategy<\/strong><\/a>, which becomes particularly important in the aftermath of any security incident.<\/p>\n

    The seven most common DDoS protection mistakes<\/h2>\n

    Being aware of the common mistakes prevents making them proactively rather than learning them through attack experience.<\/p>\n

    \n The DDoS protection mistakes businesses make repeatedly:<\/strong><\/p>\n