The website suddenly will not load, the online order system freezes, the VPN will not connect, and the first thought is usually "the line is down again". A distributed denial-of-service (DDoS) attack creates exactly that situation on purpose: the attacker typically coordinates a large number of compromised computers (a botnet) to send traffic or requests to the target at the same time, exhausting bandwidth or system resources so legitimate users cannot reach the service[1]. Taiwan's Administration for Cyber Security (ACS) under the Ministry of Digital Affairs (moda) notes that once such an attack hits critical business functions it does direct damage to operations, such as lost sales and orders when online transactions stop, and internal processes grinding to a halt[2].

This guide is for the IT staff who run internet-facing services and the managers who have to make the calls during an attack. It explains how the three types of DDoS differ and where each one has to be stopped, why treating DDoS as "just a website outage" underestimates it, and then covers what to prepare beforehand, what to do during an attack, and what to review afterwards.

Three types of DDoS: different targets, different places to stop them

The joint guide from CISA, the FBI and MS-ISAC sorts denial-of-service attacks into volumetric, protocol and application-layer attacks, and notes that the categories are not mutually exclusive: attackers often combine them, and their methods keep evolving[1]. Knowing the type tells you which layer the defence has to sit at and whom to call for help.

Volumetric: filling the pipe

Volumetric attacks use sheer traffic volume to consume the target's available bandwidth, saturating the network so legitimate requests cannot get through[1]. MITRE ATT&CK gives a plain example: send 10Gbps of traffic to a server whose network has a 1Gbps connection to the internet, and the bandwidth is gone[3]. Attackers also often spoof the source IP address, making the traffic harder to trace or enabling reflection attacks, which reduces or eliminates the value of filtering by source address[3]; CISA likewise points out that reflection attacks typically originate from legitimate public servers[1], so blanket blocking can cause collateral damage.

Once the flood exceeds the capacity of your internet link, filtering at your own firewall is too late; the traffic usually has to be intercepted upstream, by your ISP, a CDN or a specialist DDoS mitigation provider[3]. The UK's National Cyber Security Centre (NCSC) is blunt about it: a determined attacker will nearly always be able to send more traffic than most organisations could cope with unaided[4]. Simply buying more bandwidth only gets you so far.

Protocol: exhausting connection resources

Protocol attacks exploit weaknesses in network protocols or their implementations, typically targeting Layers 3 (network) and 4 (transport) of the OSI model, to degrade the target's performance or make it malfunction[1]. The classic example is the SYN flood: the attacker opens TCP connections in bulk but never completes the three-way handshake, leaving the server's connections tied up so legitimate users cannot connect[5]. What falls over is not necessarily the website: DNS servers, firewalls and other network infrastructure can also be targets[1].

Countermeasures include enabling SYN cookies on servers, filtering at the boundary by source address, port or protocol[6], and asking your ISP to apply simple filtering rules upstream so your own firewalls are not overwhelmed by inbound connection requests[4].

Application layer (L7): looking like real users

Application-layer attacks target specific applications or services at OSI Layer 7; instead of flooding the network, they exhaust the application's processing capacity or make it malfunction[1]. MITRE ATT&CK classifies attacks that make a service unavailable by exhausting the host rather than saturating the network as Endpoint Denial of Service, covering the operating system, web servers, DNS servers, databases, and the web applications that sit on top of them[6].

These requests are usually ordinary-looking HTTPS connections. Your ISP does not understand the nuances of your application, and encryption further limits what it can detect[4]. The more effective place to defend is the CDN or the front of the website: for example, rate limiting particular URLs so a flood of search queries cannot overload the backend database[4], and adding a CAPTCHA where needed to tell humans from bots[1].

Why it is more than "the website is down"

Smokescreens: the real target may be elsewhere

CISA warns that many attackers use DoS or DDoS attacks to deflect attention from their intended target and use the opportunity to launch secondary attacks on other services in the network, so responders should not lose sight of other hosts and services[5]. MITRE ATT&CK likewise records adversaries using denial of service for political purposes and to support other malicious activity, including distraction, hacktivism and extortion[3]. In practice, keep one person watching VPN sign-ins, account anomalies and endpoint alerts during an attack rather than sending everyone to rescue the website; if you find signs of intrusion, switch to the first 24 hours after a suspected breach.

Ransom DDoS: the Taiwan brokerage precedent

In February 2017, several Taiwanese securities brokers received English-language extortion emails demanding bitcoin and threatening further attacks if they did not pay; the letter announced a 15-minute attack on one of the firm's IP addresses to prove the threat was not a hoax[7]. In the first wave, 10 brokers were hit and just 800Mbps of traffic was enough to take down their online trading systems; the second wave peaked at 2Gbps, which the Financial Supervisory Commission (FSC) described as a very small "warning" attack, and the FSC assessed the attacker as a copycat using the Armada Collective name and picking targets more or less at random[8]. The FSC told firms under attack to ask their telecom providers for traffic scrubbing and to block the attacking IPs[7], and Chunghwa Telecom and Taiwan Mobile provided scrubbing to their brokerage customers[8].

Two lessons follow. It does not take an enormous flood to knock over a system that has no upstream protection, and the attack date in a ransom note is your deadline for confirming that protection is in place.

Hacktivism: following the political news

During the 2015 high-school curriculum controversy, the hacker group "Anonymous Asia" called on Facebook for attacks on the Ministry of Education and Presidential Office websites from the early hours of 1 August; traffic to the Ministry of Education site surged abnormally, the site could not operate reliably, and the ministry reported a level-2 security incident through the official procedure, while the Ministry of National Defense and the Ministry of Economic Affairs were also briefly hit by similar attacks[9]. In September 2024, the ACS confirmed that international hacker groups including NoName057 and RipperSec had launched DDoS attacks on some public- and private-sector websites in Taiwan[10]. A moda press release on 14 September said that the ACS had counted 45 attacks since 10 September, against targets including local tax agencies, regional airports, the Directorate-General of Budget, Accounting and Statistics, finance-related agencies and some telecom operators[11]. The victims are not limited to government but include private-sector sites and telecom operators, so when a major political event or controversy is in the news, companies should likewise check their defences and on-call arrangements ahead of time.

Before an attack: what to have ready

Inventory internet-facing services, their upstreams and owners

The ACS recommends starting from core business functions, inventorying the related information, software, hardware and network assets, and assessing the business impact including on availability[2]. For DDoS, that means listing every internet-facing service (website, e-commerce or order system, APIs, VPN, email, DNS) with where it is hosted, which ISP or cloud provider sits upstream, whether it is behind a CDN, and who owns it. Taking idle web pages offline is also one of the long-term defensive measures moda recommends[11].

Find out what your upstream providers can do

The NCSC recommends understanding which DDoS mitigations your ISP already has in place on your account and which others are available, looking into third-party DDoS mitigation services, and considering a CDN for web services[4]. CISA also recommends considering a DDoS mitigation provider that can filter malicious traffic before it reaches your network[1]. Get clear answers on the contract[4]:

  • Will the provider apply mitigations automatically, and will it tell you when it does? Will it throttle your bandwidth beyond a certain limit?
  • How long does it take to turn on additional mitigations, and how do you request them?
  • Will you be billed for excess traffic or resource usage?
  • Does the provider reserve the right to terminate your service or sinkhole your traffic to protect its other customers, and will it contact you before acting?
  • How quickly can your service be re-enabled if it is shut down?

Put the 24-hour contact points, contract numbers and activation steps for your ISP and hosting provider into the runbook, so nobody is reading contracts in the middle of an attack.

Keep the origin server hidden

Even with a CDN in place, an attacker may bypass it and hit the origin server directly. The NCSC recommends making sure the CDN masks or "cloaks" your site so attackers cannot discover the true origin, and considering ISP-level IP allow listing so that all requests must come through the CDN[4]. After moving behind a CDN, also change any origin IP address that was previously public, and check whether mail, test or other subdomains still point to the same host. Bear in mind that the CDN hosts your users' HTTPS sessions and holds your private keys or a certificate trusted as if it were yours, so choose a provider whose security you trust[4].

Prepare rate limits and a degraded mode in advance

CISA recommends configuring firewalls to filter suspicious traffic, keeping the rules up to date, and considering rate limiting[1]. The NCSC recommends planning for graceful degradation: during an attack, prioritise access by source (for example, domestic IP addresses only), disable compute-intensive dynamic features such as site search, or restrict dynamic content to authenticated users[12]. moda also advises preparing static web pages and traffic scrubbing arrangements in advance[11].

Keep a management path, and do not depend on DNS that will be hit

You still need to be able to log in and change settings during an attack. The NCSC recommends providing management access via a different network or subnet restricted to an allow list of trusted locations, and taking care not to rely on public DNS zones that are also likely to be targeted[12]. For the rest of the hardening work on management interfaces, see the edge device hardening checklist.

Write the runbook and decide in advance who makes the call

The ACS recommends setting up a reporting and response team in advance with clearly assigned roles for the decision-maker, technical responders and internal and external liaisons, and lists DDoS among the high-risk scenarios that need a defined response and regular drills; the response plan should also be reviewed and approved by management[2]. Its suggested internal timings are an initial internal report within 15 minutes of noticing an anomaly and escalation to management within one hour, but it states that these are management targets each company can adjust based on its business impact analysis, not legal requirements[2]. CISA recommends regularly analysing traffic to establish a baseline of normal patterns, so that significant deviations stand out during an attack[1].

The decisions in a DDoS runbook that most need advance authorisation are: turning on paid scrubbing, moving DNS to a CDN or scrubbing centre, blocking foreign IP addresses, switching off features, and posting a notice to customers.

During an attack: confirm first, then call upstream

  1. Confirm it is DDoS: denial-of-service symptoms look a lot like ordinary network faults or maintenance. CISA recommends first checking with your network administrator whether the outage is due to maintenance or an in-house network issue, and asking your ISP whether the outage is on their end, or whether their network is the target and you are an indirect victim[5]. Warning signs include a sudden surge in traffic, large numbers of requests from specific IP addresses or aimed at a specific URL, sustained high CPU and memory usage, and other services such as DNS or firewalls also becoming unreachable[1].
  2. Start the runbook and notify upstream: activate the incident response plan and contact your ISP, hosting provider or DDoS protection provider[1]. The ACS recommends asking the ISP or hosting provider to help analyse the type of attack traffic (for example UDP flood or HTTP GET flood) and assessing whether to switch to a backup IP, a CDN or a traffic scrubbing service[2]. CISA also recommends giving the attacking IP addresses to your ISP and asking it to filter by port and packet size[1].
  3. Keep minimum operations running: if core systems go down, the ACS recommends switching immediately to manual or paper processes or backup systems and estimating the cost of the outage as you go[2]. When the brokers were attacked in 2017, it was mainly the online trading websites that were affected, while mobile apps, voice and phone orders kept working[7], which is exactly why alternative channels matter.
  4. What not to do: the ACS warns against simply shutting down or force-rebooting servers, which can widen the business disruption and wipe data in memory and log evidence, and against passively waiting for the traffic to subside[2].
  5. Preserve evidence: record timestamps, source IP addresses, packet captures, and the logs and alerts generated by network devices[1]; keep any ransom emails in full.
  6. Expect another wave: it is not uncommon for DoS attacks to come in waves, with attackers changing tactics once they have worked out your protections; avoid exhausting all your staff on the first wave[12].
  7. Report and communicate: the channels the ACS lists are an online report to TWCERT/CC, reporting to the competent industry regulator as sector rules require, notifying the commissioning agency as the contract requires when you perform outsourced work, reporting to the police where a crime is involved, and, for listed companies, publishing a material information announcement when the incident causes material damage or impact[2]. For details of each channel, see the first 24 hours after a suspected breach, Taiwan's Cyber Security Management Act and security incidents and material information disclosure. CISA also recommends keeping employees, customers and partners regularly updated on progress and expected timelines for resolution[1].

After an attack: review and strengthen

The traffic subsiding does not mean it is over. CISA recommends assessing the impact on systems, networks and services, including any data loss or compromised systems; then running a post-incident analysis of the attack vectors and weaknesses it exposed, remediating them, reviewing firewall and DDoS mitigation settings, updating the incident response plan, and strengthening network monitoring[1]. Where the attack was severe or involved criminal activity, CISA also recommends engaging law enforcement and providing the evidence[1].

moda's recommended long-term measures include taking idle web pages offline, planning to distribute load through a CDN, and running protection drills[11]. The NCSC reminds organisations to test the response plan periodically, like any backup or continuity arrangement[12]; the ACS recommends at least one business continuity exercise a year, for example simulating the loss of the company's core network connection to the outside world[2].

Action checklist

  • List every internet-facing service (website, e-commerce or order system, APIs, VPN, email, DNS) with its hosting location, upstream provider, whether it sits behind a CDN and its owner; take idle pages offline.
  • Confirm with your ISP and hosting provider what DDoS protection is on your account, how scrubbing is activated and how long it takes, and their policies on excess-usage billing and blackholing; put the 24-hour contact points into the runbook.
  • Put public websites and APIs behind a CDN, make the origin accept connections only via the CDN, and check that old IP addresses and other DNS records do not reveal the origin.
  • Set rate limits on resource-heavy URLs such as search, login and queries, and prepare a static notice page.
  • Run management access over a separate network restricted by source, and do not rely on public DNS that is likely to be attacked as well.
  • Decide in advance who can turn on paid scrubbing, switch DNS, block foreign IPs, disable features and post public notices, and prepare alternative channels for orders and customer service.
  • Establish a normal traffic baseline with alerts; during an attack, assign someone to watch VPN, account and endpoint alerts in case the DDoS is a smokescreen.
  • Rehearse a "public services knocked offline" scenario at least once a year and update the runbook using real cases from DDoS advisories on this site; if you need outside help, contact us.