Denial of service attacks make a website, application, network, or online service unavailable by exhausting resources or exploiting a weakness. The disruption may affect bandwidth, connection capacity, processor time, memory, or an application function.
For website owners, the practical goal is resilience: detect abnormal behavior quickly, keep the origin protected, absorb or filter hostile traffic upstream, and follow a prepared response plan. A firewall on one server cannot stop every large distributed attack.
A DoS attack disrupts a service from one source or technique; a distributed denial-of-service attack uses many systems, often a botnet. Defenses include upstream DDoS protection, a CDN or reverse proxy, rate limiting, a web application firewall, reduced origin exposure, monitoring, redundancy, and a tested provider escalation plan.
NIST defines denial of service as an action that prevents or impairs authorized use of networks, systems, or applications. A DoS event can exhaust bandwidth, connection tables, CPU, memory, storage, or other limited resources.
Not every outage is an attack. A popular launch, broken deployment, database problem, DNS failure, or hosting incident can create similar symptoms. Confirm the cause using traffic, application, infrastructure, and provider data before making public claims.
DoS vs. DDoS: What Is the Difference?
A traditional DoS attack may originate from one system or a narrow set of sources. A DDoS attack distributes traffic across numerous hosts, which makes simple IP blocking less effective and can overwhelm the target’s internet connection before traffic reaches its server.
NIST’s DDoS glossary describes it as a denial-of-service technique using numerous hosts. Those hosts may be compromised computers, servers, routers, cameras, or other connected devices.
Common Types of Denial of Service Attacks
- Volumetric attacks attempt to consume available bandwidth with extremely large traffic volumes.
- Protocol or state-exhaustion attacks abuse network behavior or connection handling. A SYN flood, for example, creates many incomplete connection attempts.
- Application-layer attacks send requests that appear closer to legitimate web or API traffic but consume expensive application resources.
- Reflection and amplification attacks spoof the target’s address and cause third-party services to send larger responses toward the victim.
CISA’s UDP amplification guidance explains why exposed UDP services can become reflectors. Defenders should not assume that every source address in attack logs belongs to the attacker.
Warning Signs of a Possible DoS or DDoS Attack
- A sharp traffic increase that does not match a campaign or normal pattern.
- High latency, timeouts, connection errors, or intermittent availability.
- Unexpected CPU, memory, bandwidth, or connection-table saturation.
- Large numbers of requests targeting one URL, API action, protocol, region, or user-agent pattern.
- Provider alerts, health-check failures, or a sudden rise in error responses.
One signal is rarely enough. Correlate availability tests with edge, firewall, load balancer, server, and application logs. Preserve useful timestamps and samples without collecting more personal data than the investigation requires.
A DDoS attack can be used as a distraction while another intrusion is attempted. Continue monitoring authentication, endpoint, cloud, and application alerts while restoring availability.
How to Protect a Website from Denial of Service Attacks
- Use upstream protection. Choose a hosting, CDN, DNS, or cloud provider with appropriate always-on or on-demand DDoS mitigation.
- Hide and restrict the origin. Where the architecture allows it, accept public web traffic through the approved proxy or load balancer rather than exposing the origin directly.
- Apply rate limits carefully. Limit abusive request patterns at the edge while avoiding rules that block legitimate shared networks or accessibility tools.
- Use caching and a CDN. Cached responses reduce repeated origin work and distribute delivery.
- Protect the application layer. Use a WAF, efficient authentication controls, request-size limits, queues, and timeouts appropriate to the application.
- Reduce the attack surface. Remove unused services, patch exposed systems, and restrict administrative interfaces.
- Plan capacity and failover. Scaling helps with some attacks, but uncontrolled scaling can create large costs; define limits and escalation rules.
Reduce exposure and improve security on the network you control.
What to Do During an Active Attack
- Confirm which services, regions, addresses, and customer journeys are affected.
- Contact the hosting, CDN, DNS, cloud, or internet provider through the prearranged emergency channel.
- Enable or tune the provider’s mitigation controls using observed traffic, preferably testing rules before broad enforcement when time permits.
- Preserve logs, alerts, traffic summaries, timelines, and configuration changes for later analysis.
- Keep watching other systems for signs that the disruption is covering a second attack.
- Communicate service status through a channel that does not depend on the affected infrastructure.
- After recovery, review what worked, revert temporary rules safely, and update the response plan.
CISA’s DDoS response guidance emphasizes working with providers, understanding the traffic, deploying mitigations, and continuing to monitor other assets.
What Individual Website Visitors Can Do
A visitor cannot repair a DDoS attack against somebody else’s service. Avoid repeatedly refreshing the page, because that can add load. Check the organization’s official status page or verified support channel and try again later.
If your own device may be participating in a botnet, update its operating system and firmware, remove unsupported software, change compromised credentials from a clean device, and scan with trusted security tools. Endpoint protection helps reduce device compromise, but antivirus alone is not DDoS protection for a public website.
Strengthen a Windows endpoint against compromise and unauthorized access.
Frequently Asked Questions
Can a firewall stop a DDoS attack?
A firewall can filter some traffic, but a large attack may saturate the connection before traffic reaches it. Effective defense often requires upstream provider or edge-network mitigation.
Is a slow website proof of a DoS attack?
No. Slow performance can result from legitimate demand, bad code, database problems, DNS issues, or hosting failures. Confirm the cause with monitoring and provider evidence.
Does a VPN protect a website from DDoS attacks?
A personal VPN does not protect a public website. Website protection depends on its hosting, DNS, network edge, application architecture, and mitigation services.
Should every attacking IP address be blocked?
Not automatically. Distributed and reflected attacks can involve many compromised devices or spoofed addresses. Broad blocking can harm legitimate users, so use provider intelligence and tested rules.
Are denial of service attacks illegal?
Launching an attack without authorization can violate criminal and computer-misuse laws. Exact consequences depend on the jurisdiction and facts; consult qualified legal counsel for a specific incident.
Final DDoS Readiness Checklist
- Know the provider’s DDoS coverage, limits, cost model, and emergency contact route.
- Keep the origin protected and minimize exposed services.
- Monitor normal traffic baselines, availability, errors, and resource usage.
- Prepare rate limits and WAF rules before an emergency.
- Maintain redundant DNS, status communication, and recovery procedures where appropriate.
- Assign decision owners and test the incident plan.
Denial of service attacks cannot always be prevented, but layered architecture and practiced coordination can reduce downtime and help legitimate users regain access faster.
