Denial-of-Service Concepts

1. Introduction to Denial-of-Service

A Denial-of-Service (DoS) attack attempts to make a computer
system, application, network or online service unavailable or significantly
less responsive to legitimate users.

The primary security objective affected is usually
availability.

2. Availability and the CIA Triad

The CIA triad consists of confidentiality, integrity and availability.

• Confidentiality: Preventing unauthorized disclosure.
• Integrity: Preventing unauthorized alteration.
• Availability: Ensuring authorized users can access services when needed.

DoS attacks primarily target availability, although an incident may have
secondary effects on confidentiality or integrity.

3. What Is a DoS Attack?

A DoS attack generally uses one source or a limited number of sources to
generate conditions that interfere with legitimate service availability.

The disruption may result from traffic volume, protocol behavior, application
processing or exhaustion of system resources.

4. What Is DDoS?

Distributed Denial-of-Service (DDoS) involves traffic or
requests originating from multiple distributed systems.

The distributed nature can make filtering more difficult because traffic may
come from many source addresses and networks.

5. DoS vs DDoS

6. Volumetric Attacks

A volumetric attack attempts to consume available network bandwidth or other
capacity through a large amount of traffic.

The result can be congestion that prevents legitimate traffic from reaching
the target.

7. Protocol Attacks

Protocol attacks attempt to exhaust resources associated with network
protocol processing or intermediate network devices.

The defensive focus includes appropriate network filtering, device
configuration, capacity planning and upstream protection.

8. Application-Layer Attacks

Application-layer denial-of-service targets the processing behavior of an
application rather than simply overwhelming the network with raw traffic.

For example, an application may consume significant CPU, memory, database
connections or other resources when processing certain requests.

9. Resource Exhaustion

Every service has finite resources.

Examples include:

• CPU
• Memory
• Network bandwidth
• Database connections
• Worker processes
• File descriptors
• Storage
• Application threads

A denial-of-service condition can occur when important resources are consumed
faster than they can be released or replenished.

10. Botnets

A botnet is a collection of compromised or otherwise
controlled devices that can be directed to perform coordinated activity.

Botnets can contribute to distributed attacks because traffic may originate
from many different devices and networks.

Defenders can reduce botnet-related risk through endpoint security, patching,
secure authentication and monitoring.

11. Traffic Amplification

Some network designs or protocols can allow a relatively small request to
produce a much larger response.

Attackers may attempt to abuse such behavior to increase the amount of traffic
directed toward a victim.

From a defensive perspective, organizations should avoid exposing services
in ways that allow unauthorized amplification and should follow secure
configuration guidance.

12. Reflection

In a reflection scenario, traffic is directed through third-party systems so
that responses are sent toward the intended target.

Defensive measures include network filtering, appropriate service
configuration and upstream traffic controls.

13. Application Dependency

A web application may depend on many supporting services, including:

• Web servers
• Application servers
• Databases
• DNS
• Authentication services
• APIs
• Third-party services

An availability incident affecting one dependency can sometimes affect the
whole application.

14. Signs of a Possible DoS or DDoS Event

Possible indicators include:

• Sudden traffic increases
• Unusual request rates
• High CPU utilization
• High memory utilization
• Connection exhaustion
• Increased latency
• Large numbers of failed requests
• Timeouts
• Unexpected geographic traffic patterns
• Service unavailability

These indicators can also occur because of legitimate traffic spikes,
software failures or infrastructure problems, so investigation is required.

15. Baselines

A security baseline describes normal system behavior.

Without a baseline, it can be difficult to determine whether a sudden change
is unusual.

Organizations should understand normal request rates, traffic volumes,
latency and resource usage for important services.

16. Rate Limiting

Rate limiting restricts how frequently a client or other
identifier can perform an operation within a given period.

Rate limiting can protect applications from excessive requests and can also
help reduce accidental overload.

17. Rate Limiting Example

A simple application may track requests within a time window.

The following example is intentionally simplified and operates only on
synthetic request data.

<?php

$requests = array(
	'user-001',
	'user-001',
	'user-001',
	'user-002',
	'user-001',
);

$limit = 3;
$count = array();

foreach ( $requests as $client ) {

	if ( ! isset( $count[ $client ] ) ) {
		$count[ $client ] = 0;
	}

	$count[ $client ]++;
}

foreach ( $count as $client => $total ) {

	if ( $total > $limit ) {

		echo htmlspecialchars(
			$client,
			ENT_QUOTES,
			'UTF-8'
		);

		echo ': rate limit exceeded.<br>';

	} else {

		echo htmlspecialchars(
			$client,
			ENT_QUOTES,
			'UTF-8'
		);

		echo ': within limit.<br>';
	}
}

18. Application-Level Controls

Applications can use several techniques to reduce resource exhaustion.

• Rate limiting
• Request validation
• Connection limits
• Timeouts
• Caching
• Queue management
• Efficient database queries
• Resource quotas

19. Web Application Firewall

A Web Application Firewall (WAF) can inspect HTTP and HTTPS
traffic and apply rules designed to protect web applications.

A WAF can help manage certain application-layer availability threats, but it
is not a complete DDoS solution.

20. Content Delivery Networks

A Content Delivery Network (CDN) distributes content and
traffic handling across multiple locations.

CDNs can improve resilience and may provide traffic filtering and DDoS
protection services.

21. Load Balancing

Load balancing distributes application traffic across multiple servers or
service instances.

This can improve resilience by preventing a single server from handling all
requests.

22. Upstream DDoS Protection

Very large traffic attacks may need to be filtered before reaching the
organization’s own network.

Internet service providers, cloud providers, CDNs and specialized DDoS
protection services may provide upstream filtering.

23. Network Filtering

Firewalls, routers and other network controls can filter traffic according to
configured security rules.

Filtering should be carefully designed because overly broad blocking can also
block legitimate users.

24. Geographic Filtering

Some organizations may restrict access based on geographic or network
characteristics where appropriate.

However, geographic filtering should not be treated as a complete security
solution because attackers can use distributed infrastructure and legitimate
users may connect through different locations.

25. Authentication During Traffic Surges

Authentication systems can become targets during availability attacks.

Strong rate limiting, caching and efficient authentication architecture can
help prevent login services from becoming overwhelmed.

26. Database Protection

Applications that perform database operations should protect database
resources from excessive requests.

Defensive techniques include:

• Connection pooling
• Query optimization
• Timeouts
• Rate limiting
• Caching
• Resource quotas

27. DNS Availability

DNS is an important dependency for many online services.

If DNS becomes unavailable, users may have difficulty reaching the intended
service even if the web server itself is functioning.

28. Monitoring and Alerting

Monitoring systems should track important availability indicators.

Examples include:

• Requests per second
• Bandwidth usage
• CPU usage
• Memory usage
• Connection counts
• Error rates
• Latency
• HTTP response codes

29. HTTP Status Codes

HTTP status codes can provide useful application-level information.

• 200: Successful response.
• 400: Bad request.
• 401: Authentication required.
• 403: Access forbidden.
• 404: Resource not found.
• 429: Too many requests.
• 500: Server error.
• 502: Bad gateway.
• 503: Service unavailable.
• 504: Gateway timeout.

A sudden increase in certain status codes can provide useful investigation
signals.

30. Logging

Logs can help security teams understand an availability incident.

Useful records may include:

• Source IP addresses
• Request paths
• Request methods
• Response codes
• Timestamps
• User agents
• Firewall events
• Load-balancer events
• Application errors

31. False Positives

Not every traffic spike is an attack.

Legitimate causes may include:

• Marketing campaigns
• News coverage
• Software updates
• Popular content
• Business events
• Unexpected user growth

Security teams should compare current activity with historical baselines.

32. Incident Response

A DoS or DDoS incident should be handled using a defined response process.

1. Detect the abnormal condition.
2. Confirm whether the problem is malicious or operational.
3. Assess affected services.
4. Activate the appropriate response team.
5. Apply traffic controls.
6. Coordinate with upstream providers where necessary.
7. Monitor service recovery.
8. Document the incident.
9. Perform a post-incident review.

33. Capacity Planning

Capacity planning estimates how much infrastructure is required to support
expected workloads.

It does not eliminate DDoS risk, but sufficient capacity can improve resilience
against smaller traffic spikes.

34. Redundancy

Redundant systems provide alternatives when one component becomes
unavailable.

Examples include:

• Multiple application servers
• Multiple network links
• Redundant DNS infrastructure
• Multiple availability zones
• Backup communication channels

35. DoS and Cloud Infrastructure

Cloud platforms can provide scalable infrastructure and managed DDoS
protection services.

However, scaling alone does not solve every problem. Application-layer
resource exhaustion and unexpected usage costs can still require defensive
controls.

36. Cost-Based Attacks

In some cloud environments, an attacker may attempt to generate traffic or
requests that cause unusually high resource consumption.

Organizations should monitor usage and configure suitable quotas, limits and
alerts.

37. Safe Security Testing

DoS testing should only be performed against systems where explicit
authorization has been obtained.

Testing should use controlled limits, documented scope and agreed stopping
conditions.

38. Authorized Classroom Exercise

Students can create a safe availability-monitoring exercise using synthetic
data rather than generating attack traffic.

1. Create a fictional web service.
2. Record normal request rates.
3. Create a synthetic traffic-spike dataset.
4. Calculate the average request rate.
5. Identify abnormal periods.
6. Design a rate-limiting policy.
7. Design an alert threshold.
8. Document the response procedure.

39. Example Synthetic Traffic Dataset

$traffic = array(
	'09:00' => 120,
	'09:05' => 135,
	'09:10' => 128,
	'09:15' => 142,
	'09:20' => 890,
	'09:25' => 940,
	'09:30' => 915,
);

$threshold = 500;

foreach ( $traffic as $time => $requests ) {

	if ( $requests > $threshold ) {

		echo $time . ': review required.<br>';

	} else {

		echo $time . ': normal range.<br>';
	}
}

40. Defensive Architecture

A resilient web service may use multiple layers:

• CDN
• DDoS protection
• Load balancer
• WAF
• Application servers
• Database controls
• Monitoring
• Logging
• Alerting

The exact architecture depends on the organization’s requirements and
available resources.

41. DoS Response Checklist

• Confirm the service impact.
• Check whether traffic is actually abnormal.
• Compare activity with normal baselines.
• Identify affected services.
• Review network and application logs.
• Apply approved rate limits or filtering.
• Contact upstream providers if necessary.
• Protect critical dependencies.
• Monitor recovery.
• Document the incident.

42. Review Questions

1. What is a Denial-of-Service attack?
2. What is a Distributed Denial-of-Service attack?
3. What is the main CIA-triad objective affected by DoS?
4. What is a volumetric attack?
5. What is a protocol attack?
6. What is an application-layer availability attack?
7. What is a botnet?
8. What is traffic amplification?
9. What is rate limiting?
10. How can a CDN improve resilience?
11. What is the purpose of a WAF?
12. Why is monitoring important?
13. Why can legitimate traffic spikes resemble an attack?
14. What is the purpose of a security baseline?
15. Why is capacity planning useful?
16. Why should DoS testing be authorized?
17. What should an organization do when it detects an availability incident?

43. Key Takeaways

• DoS attacks primarily target service availability.
• DDoS attacks use distributed sources.
• Availability attacks can target networks, protocols or applications.
• Resource exhaustion is a central concept in denial-of-service incidents.
• Botnets can contribute to distributed attacks.
• Rate limiting can protect applications from excessive requests.
• CDNs and upstream providers can improve resilience.
• WAFs can help with certain application-layer threats but are not a complete DDoS solution.
• Monitoring and baselines help distinguish abnormal behavior from normal traffic.
• Redundancy and capacity planning can improve resilience.
• Cloud systems require both availability controls and cost monitoring.
• DoS testing must only occur within authorized and controlled environments.

44. Conclusion

Denial-of-Service attacks demonstrate that cybersecurity is not only about
protecting information. Organizations must also ensure that legitimate users
can access important services when needed.

Effective availability protection combines monitoring, rate limiting,
secure application design, network controls, redundancy, capacity planning,
CDN or upstream protection and a tested incident-response process.

Security professionals should understand both the technical characteristics
of availability attacks and the business impact that service disruption can
create.

The next lesson will examine:
Insider Threats.