From 4d59071ce479c91bd17d0179fdef52bb280b94b8 Mon Sep 17 00:00:00 2001 From: Bruce Davie <3101026+drbruced12@users.noreply.github.com> Date: Fri, 22 Aug 2025 10:05:25 +1000 Subject: [PATCH] move DoS section to infra and update intro to chapter --- firewall.rst | 103 +--------------------------------------- infra.rst | 131 ++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 126 insertions(+), 108 deletions(-) diff --git a/firewall.rst b/firewall.rst index f5fbeee..b0f296e 100644 --- a/firewall.rst +++ b/firewall.rst @@ -516,7 +516,7 @@ example, the systems related to heating and cooling don't need access to the systems where customer credit card details are stored. A default policy of no access can also be established, with explicit configuration then required to create precisely specified allowable -commuincation patterns between specific devices. +communication patterns between specific devices. The VPN example above provides motivation for a different approach to handling users and devices outside of the confines of a traditional @@ -673,104 +673,3 @@ firewall, we might not require an IDS or IPS. However, knowing that firewalls will never block all forms of malicious traffic leads to the conclusion that an IDS/IPS is worth having as a second line of defense. - -9.5.2 DoS Mitigation -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Sometimes unwanted traffic is simply trying to consume resources, -rather than exploit a vulnerability. Such attacks—or as they are -commonly known, *Denial of Service (DoS)* attacks—threaten -availability (as opposed to confidentiality or integrity). They -typically involve an adversary trying to overwhelm "good" resources -(link bandwidth, packet forwarding rates, server response throughput) -with traffic generated by "bad" resources (botnets constructed from a -distributed collection of compromised devices). Firewalls and other -security appliances help protect devices from being compromised in the -first place, but because they are not perfect (a human is often the -weakest link), we also need ways to mitigate the impact of -*Distributed DoS (DDoS)* attacks. - -Keeping in mind that DDoS traffic typically looks legitimate (there's -just too much of it), the DDoS challenge is addressed by two general -countermeasures. Note that the best we can hope for is to mitigate the -impact of such attacks; there is no cure-all. This is easy to -understand at an intuitive level: an appliance defending against DoS -attacks is itself a kind of resource that can be DoSed. - -The first countermeasure is to absorb potential attacks with even -greater resources than the adversary is able to muster. For web -content, this is done using the same mechanism as is used to absorb -flash crowds of legitimate traffic: a *Content Distribution Network -(CDN).* The idea is to replicate content (whether it's a movie or a -critical piece of infrastructure metadata) across many -widely-distributed servers. As long as the aggregate capacity of these -servers is greater than the aggregate capacity of the botnet—and the -CDN does a good job spreading requests across the available -servers—content remains available. This notion of *aggregate* capacity -generalizes beyond web servers responding to HTTP GET requests. A -network is itself a distributed collection of forwarding and -transmission resources, engineered to distribute those resources in a -way that avoids vulnerable bottlenecks. - -The second countermeasure is to filter malicious traffic as early -(close to the source) as possible. If a DoS attack comes from a single -source, then it is easy to "block" traffic from that source at an -ingress to a network you control. This is why DoS attacks are -typically distributed. Dropping (or rate limiting) attack packets at -the boundary router (or firewall) for an enterprise is better than -allowing those packets to flood the local network and reach a victim -server(s), but the more widely distributed the periphery of your -network, the earlier you can filter malicious packets. And drawing on -the first countermeasure, the more widely distributed your network -resources are, the greater your aggregate filtering capacity. Global -overlay networks, as provided by companies like Cloudflare and Fastly, -offer a combination of content distribution and distributed packet -filtering. These are commercial products, with many proprietary -details, but the general principles outlined here explain their -underlying strategy. - -Finally, note that this brief overview of DoS attacks is heavily -slanted towards web content, which is to say, attackers are taking -advantage of the HTTP protocol—significant server resources are -consumed responding to bogus GET requests. In general, all protocols -are vulnerable to insidious combinations of packets. For example, IP -can be attacked with a "Christmas Tree" packet, one that has multiple -options turned on (i.e., is "lit up like a Christmas tree"), where -each option requires IP to execute instructions it would not normally -execute to forward a typical packet. A router with a naive -implementation of IP would be at risk of not being able to forward -packets at line speed if it's busy processing the options. For this -reason, routers typically implement a "fast path" that is able to keep -pace with line speeds and a "slow path" that processes exceptional -packets, and most importantly, they quickly determine which path each -packet should be assigned to. This is a variant of the second -countermeasure—decide early to protect resources. - -Another well-known example is a "SYN Flood" targeting TCP, whereby an -attacker floods a server with SYN requests without any intent to -complete the TCP handshake and actually establish a connection. This -overloads TCP's connection table, potentially denying connections to -legitimate clients. An IDS/IPS can help protect servers since a flood -of SYN packets is anomalous behavior, but individual servers can also -limit the impact by encoding connection state in the sequence number -included in the SYN+ACK they send back to the client—a "SYN cookie" of -sorts—and then allocate connection state locally only after the client -goes to the trouble of correctly ACK'ing that packet. This is a -variant of the first countermeasure in that it forces the attacker to -use additional resources. - -These examples are just two of many illustrating the need to program -defensively. This is especially true for protocols since they are -purposely designed to process messages from remote sources, exposing -them to attempts to crash, hack, or as in the case of DoS attacks, -simply consume the system. This topic ventures outside the scope of -the book, but the following reference explores one approach to -addressing the challenge. - -.. admonition:: Further Reading - - X. Qie, R. Pang, and L. Peterson. `Defensive Programming: Using an Annotation Toolkit to Build - DoS-Resistant Software - `__. - Proceedings of the Fifth Symposium on Operating System Design and Implementation - (OSDI). Usenix. December 2002. diff --git a/infra.rst b/infra.rst index 58b2aed..9d65696 100644 --- a/infra.rst +++ b/infra.rst @@ -12,6 +12,21 @@ systems routinely come under attack. There are efforts underway to make them more resistant to attacks, as we discuss in the following sections. +This following discussion builds on some of the concepts introduced in previous +chapters. Notably, the concept of public key infrastructure (PKI), +which we introduced in Chapter 4 and which underpins the operation of TLS, +plays an important role in securing infrastructure as well. While the +principles of certificates and chains of trust apply in any PKI, the +specifics of how certificates are distributed and what they refer to +are different in each application. We describe the different +approaches to PKI for infrastructure services in the following sections. + +Availability of infrastructure, including resistance to +denial-of-service (DoS) attacks, is clearly important to the operation +of the Internet. Mitigation of such attacks is increasingly handled by +distributed infrastructure like content distribution networks (CDNs), +as we discuss in the final section of this chapter. + 8.1 BGP and Routing Security ---------------------------- @@ -841,8 +856,8 @@ the key used to verify the signature. That's a significant increase in the number of bytes returned for a single query. The mitigation techniques outlined above—source address filtering and DoS prevention—can still be applied. Additionally, there is an advantage -to using crytographic algorithms that use relatively short keys. For -this reason the EDCSA algorithm may be preferred to RSA, since EDCSA +to using cryptographic algorithms that use relatively short keys. For +this reason the ECDSA algorithm may be preferred to RSA, since ECDSA keys are considerably shorter than RSA keys for comparable levels of security. @@ -949,10 +964,114 @@ for the target function. `__. Proc. 2019 Applied Networking Research Workshop, 2019. -.. notes +8.3 DoS Mitigation +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In much of this book we have focused on attacks against the +confidentiality or integrity of information, but we also need to +concern ourselves with availability of both the end systems (such as +web sites) and the infrastructure of the network itself. Commonly +known as *Denial of Service (DoS)* attacks, such attacks typically +involve an adversary trying to overwhelm "good" resources (link +bandwidth, packet forwarding rates, server response throughput) with +traffic generated by "bad" resources (such as botnets constructed from +a distributed collection of compromised devices). Patching of +vulnerabilities and the deployment of security appliances such as +firewalls can help protect devices from being compromised in the first +place, but they are not perfect—new vulnerabilities appear constantly +and a human is often the weakest link. Hence we also need ways to +mitigate the impact of *Distributed DoS (DDoS)* attacks. This is +another example of defense in depth: protect devices against being +compromised, and also protect against the attacks launched by +compromised devices. + +Keeping in mind that DDoS traffic typically looks legitimate (there's +just too much of it), the DDoS challenge is addressed by two general +countermeasures. Note that the best we can hope for is to mitigate the +impact of such attacks; there is no cure-all. This is easy to +understand at an intuitive level: any systems that we deploy to defend against DoS +attacks represent a kind of resource that can itself be DoSed. Thus DoS +mitigation solutions tend to be distributed themselves. + +The first countermeasure is to absorb potential attacks with even +greater resources than the adversary is able to muster. For web +content, this is done using the same mechanism as is used to absorb +flash crowds of legitimate traffic: a *Content Distribution Network +(CDN).* The idea is to replicate content (whether it's a movie or a +critical piece of infrastructure metadata) across many +widely-distributed servers. As long as the aggregate capacity of these +servers is greater than the aggregate capacity of the botnet—and the +CDN does a good job spreading requests across the available +servers—content remains available. This notion of *aggregate* capacity +generalizes beyond web servers responding to HTTP GET requests. A +network is itself a distributed collection of forwarding and +transmission resources, engineered to distribute those resources in a +way that avoids vulnerable bottlenecks. The DNS, for example, is +itself a highly distributed system designed to avoid single points of +failure with redundancy at all levels of the hierarchy. + +The second countermeasure is to filter malicious traffic as early +(close to the source) as possible. If a DoS attack comes from a single +source, then it is easy to "block" traffic from that source at an +ingress to a network you control. This is why DoS attacks are +typically distributed. Dropping (or rate limiting) attack packets at +the boundary router (or firewall) for an enterprise or service +provider is better than allowing those packets to flood the core of +the network and reach a victim server(s), but the more widely +distributed the periphery of your network, the earlier you can filter +malicious packets. And drawing on the first countermeasure, the more +widely distributed your network resources are, the greater your +aggregate filtering capacity. Global overlay networks, as provided by +companies like Cloudflare and Fastly, offer a combination of content +distribution and distributed packet filtering. These are commercial +products, with many proprietary details, but the general principles +outlined here explain their underlying strategy. + +Finally, note that DoS attacks highlight the never-ending nature of +tackling security. Almost any protocol or system can by a target of a +DoS attack. We discussed the role of DNS in amplification of DoS attacks in the +preceding section. When attacks are launched against web sites, +attackers are often taking advantage of the HTTP protocol—significant server +resources are consumed responding to bogus GET requests. As a very +different example, the forwarding of IP packets can be attacked with a +"Christmas Tree" packet, one that has multiple options turned on +(i.e., is "lit up like a Christmas tree"), where each option requires +IP to execute instructions it would not normally execute to forward a +typical packet. A router with a naive implementation of IP would be at +risk of not being able to forward packets at line speed if it's busy +processing the options. For this reason, routers typically implement a +"fast path" that is able to keep pace with line speeds and a "slow +path" that processes exceptional packets, and most importantly, they +quickly determine which path each packet should be assigned to. This +is a variant of the second countermeasure—decide early to protect +resources. + +Another well-known example is a "SYN Flood" targeting TCP, whereby an +attacker floods a server with SYN requests without any intent to +complete the TCP handshake and actually establish a connection. This +overloads TCP's connection table, potentially denying connections to +legitimate clients. An IDS/IPS can help protect servers since a flood +of SYN packets is anomalous behavior, but individual servers can also +limit the impact by encoding connection state in the sequence number +included in the SYN+ACK they send back to the client—a "SYN cookie" of +sorts—and then allocate connection state locally only after the client +goes to the trouble of correctly ACK'ing that packet. This is a +variant of the first countermeasure in that it forces the attacker to +use additional resources. + +These examples are just a few of many illustrating the need to program +defensively. This is especially true for protocols since they are +purposely designed to process messages from remote sources, exposing +them to attempts to crash, hack, or as in the case of DoS attacks, +simply consume the system. This topic ventures outside the scope of +the book, but the following reference explores one approach to +addressing the challenge. - adoption of RPKI vs DNSSEC - the difference between detecting - corrupt info vs. preventing spread of corrupt info +.. admonition:: Further Reading - compare infra mechanisms vs e2e, notably TLS + X. Qie, R. Pang, and L. Peterson. `Defensive Programming: Using an Annotation Toolkit to Build + DoS-Resistant Software + `__. + Proceedings of the Fifth Symposium on Operating System Design and Implementation + (OSDI). Usenix. December 2002.