smooth DoS/IPS edges

Author: llpeterson

firewall.rst

@@ -582,20 +582,17 @@ and authorization” although it's less memorable.
       <https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf>`__.
       ;login:, Usenix, 2014.
 
-9.5 Security Appliances
-------------------------------
+9.5. Intrusion Detection and Prevention
+--------------------------------------------
 
 As introduced at the beginning of this chapter, *security appliances*
 are a generalization of firewalls. Such appliances are placed
 throughout the network, watching for and responding to unwanted
 traffic. The main challenge they face is how to distinguish between
-good and bad traffic. This section looks at two examples.
+good and bad traffic. This section looks at two examples: an
+*intrusion detection systems* (IDS), and its sibling *intrusion
+prevention systems* (IPS).
 
-9.5.1 Intrusion Detection and Prevention
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A common example of a security appliance is an *intrusion detection
-system* (IDS), or its sibling *intrusion prevention system* (IPS).
 These systems look for anomalous activity, such as an unusually
 large amount of traffic targeting a particular port number, which
 often signals a malicious attempt to probe for a vulnerability. When
@@ -625,14 +622,6 @@ important. That leads to the same concerns about east-west traffic
 that we discussed above, and thus there are also distributed versions
 of these systems.
 
-For an IDS/IPS that uses packet signatures to be effective, the set of
-potential attacks need to have been spotted in the wild and analyzed
-so that suitable rules can be formulated. Sharing rules among a
-community of users helps to speed up this process, and commercial
-IDS/IPS systems typically come with a subscription to a
-frequently-updated rules database. (See the Snort website referenced
-above for an example set of community rules.)
-
 .. sidebar::  Identifying Unwanted Traffic
 
   *Our overview of security appliances could lead to the conclusion
@@ -656,6 +645,14 @@ above for an example set of community rules.)
   a human, and not an AI bot
   trying to scrape their content, is at other end of every HTTP request.*
 
+For an IDS/IPS that uses packet signatures to be effective, the set of
+potential attacks need to have been spotted in the wild and analyzed
+so that suitable rules can be formulated. Sharing rules among a
+community of users helps to speed up this process, and commercial
+IDS/IPS systems typically come with a subscription to a
+frequently-updated rules database. (See the Snort website referenced
+above for an example set of community rules.)
+
 Another approach to using signatures is to look for
 *anomalies*—patterns in the behavior of traffic that somehow stand out
 from "normal" and can be categorized as a potential attack. Clearly

infra.rst

@@ -970,7 +970,7 @@ for the target function.
 
 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
+concern ourselves with availability. This is true for both 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
@@ -1007,17 +1007,17 @@ 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
+way that avoids vulnerable bottlenecks. The DNS illustrates this perfectly:
+it is 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 boundary router for a service provider (or at a firewall for an enterprise)
+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
@@ -1051,22 +1051,23 @@ 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.
+legitimate clients. An Intrusion Detection System (see the next
+chapter) 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.
+simply consume the system. Defensive programming ventures outside the
+scope of this book, but the referenced OSDI paper is an example of one
+approach.
 
 .. admonition:: Further Reading