لخّصلي

Defenses against denial-of-service Attacks
There are a number of steps that can be taken both to limit the consequences of
being the target of a DoS attack and to limit the chance of your systems being compromised and then used to launch DoS attacks. It is important to recognize that
these attacks cannot be prevented entirely. In particular, if an attacker can direct a
large enough volume of legitimate traffic to your system, then there is a high chance
this will overwhelm your system’s network connection, and thus limit legitimate
traffic requests from other users. Indeed, this sometimes occurs by accident as a
result of high publicity about a specific site. Classically, a posting to the well-known
Slashdot news aggregation site often results in overload of the referenced server
system. Similarly, when popular sporting events like the Olympics or Soccer World
Cup matches occur, sites reporting on them experience very high traffic levels. This
has led to the terms slashdotted, flash crowd, or flash event being used to describe
such occurrences. There is very little that can be done to prevent this type of either
260 Chapter 7 / Denial-of-Service Attacks
accidental or deliberate overload without also compromising network performance.
The provision of significant excess network bandwidth and replicated distributed
servers is the usual response, particularly when the overload is anticipated. This is
regularly done for popular sporting sites. However, this response does have a significant implementation cost.
In general, there are four lines of defense against DDoS attacks [PENG07,
CHAN02]:
• Attack prevention and preemption (before the attack): These mechanisms
enable the victim to endure attack attempts without denying service to legitimate clients. Techniques include enforcing policies for resource consumption
and providing backup resources available on demand. In addition, prevention mechanisms modify systems and protocols on the Internet to reduce the
possibility of DDoS attacks.
• Attack detection and filtering (during the attack): These mechanisms attempt
to detect the attack as it begins and respond immediately. This minimizes the
impact of the attack on the target. Detection involves looking for suspicious
patterns of behavior. Response involves filtering out packets likely to be part
of the attack.
• Attack source traceback and identification (during and after the attack): This
is an attempt to identify the source of the attack as a first step in preventing
future attacks. However, this method typically does not yield results fast
enough, if at all, to mitigate an ongoing attack.
• Attack reaction (after the attack): This is an attempt to eliminate or curtail the
effects of an attack.
We discuss the first of these lines of defense in this section and consider the
remaining three in Section 7.7.
A critical component of many DoS attacks is the use of spoofed source
addresses. These either obscure the originating system of direct and distributed DoS
attacks or are used to direct reflected or amplified traffic to the target system. Hence
one of the fundamental, and longest standing, recommendations for defense against
these attacks is to limit the ability of systems to send packets with spoofed source
addresses. RFC 2827, Network Ingress Filtering: Defeating Denial-of-service attacks
which employ IP Source Address Spoofing,
8
directly makes this recommendation, as
do SANS, CERT, and many other organizations concerned with network security.
This filtering needs to be done as close to the source as possible, by routers
or gateways knowing the valid address ranges of incoming packets. Typically this is
the ISP providing the network connection for an organization or home user. An ISP
knows which addresses are allocated to all its customers and hence is best placed to
ensure that valid source addresses are used in all packets from its customers. This
type of filtering can be implemented using explicit access control rules in a router to
ensure that the source address on any customer packet is one allocated to the ISP.
8
Note that while the title uses the term Ingress Filtering, the RFC actually describes Egress Filtering, with
the behavior we discuss. True ingress filtering rejects outside packets using source addresses that belong
to the local network. This provides protection against only a small number of attacks.
7.6 / Defenses against denial-of-service Attacks 261
Alternatively, filters may be used to ensure that the path back to the claimed source
address is the one being used by the current packet. For example, this may be done
on Cisco routers using the “ip verify unicast reverse-path” command. This latter
approach may not be possible for some ISPs that use a complex, redundant routing infrastructure. Implementing some form of such a filter ensures that the ISP’s
customers cannot be the source of spoofed packets. Regrettably, despite this being
a well-known recommendation, many ISPs still do not perform this type of filtering.
In particular, those with large numbers of broadband-connected home users are of
major concern. Such systems are often targeted for attack as they are often less well
secured than corporate systems. Once compromised, they are then used as intermediaries in other attacks, such as DoS attacks. By not implementing antispoofing
filters, ISPs are clearly contributing to this problem. One argument often advanced
for not doing so is the performance impact on their routers. While filtering does
incur a small penalty, so does having to process volumes of attack traffic. Given
the high prevalence of DoS attacks, there is simply no justification for any ISP or
organization not to implement such a basic security recommendation.
Any defenses against flooding attacks need to be located back in the Internet
cloud, not at a target organization’s boundary router, since this is usually located
after the resource being attacked. The filters must be applied to traffic before it
leaves the ISP’s network, or even at the point of entry to their network. While it is
not possible, in general, to identify packets with spoofed source addresses, the use
of a reverse path filter can help identify some such packets where the path from
the ISP to the spoofed address differs to that used by the packet to reach the ISP.
Also, attacks using particular packet types, such as ICMP floods or UDP floods to
diagnostic services, can be throttled by imposing limits on the rate at which these
packets will be accepted. In normal network operation, these should comprise a
relatively small fraction of the overall volume of network traffic. Many routers,
particularly the high-end routers used by ISPs, have the ability to limit packet rates.
Setting appropriate rate limits on these types of packets can help mitigate the effect
of packet floods using them, allowing other types of traffic to flow to the targeted
organization even should an attack occur.
It is possible to specifically defend against the SYN spoofing attack by using a
modified version of the TCP connection handling code. Instead of saving the connection details on the server, critical information about the requested connection
is cryptographically encoded in a cookie that is sent as the server’s initial sequence
number. This is sent in the SYN-ACK packet from the server back to the client.
When a legitimate client responds with an ACK packet containing the incremented
sequence number cookie, the server is then able to reconstruct the information
about the connection that it normally would have saved in the known TCP connections table. Typically this technique is only used when the table overflows. It
has the advantage of not consuming any memory resources on the server until the
three-way TCP connection handshake is completed. The server then has greater
confidence that the source address does indeed correspond with a real client that is
interacting with the server.
There are some disadvantages of this technique. It does take computation
resources on the server to calculate the cookie. It also blocks the use of certain TCP
extensions, such as large windows. The request for such an extension is normally
262 Chapter 7 / Denial-of-Service Attacks
saved by the server, along with other details of the requested connection. However,
this connection information cannot be encoded in the cookie as there is not enough
room to do so. Since the alternative is for the server to reject the connection entirely
as it has no resources left to manage the request, this is still an improvement in
the system’s ability to handle high connection-request loads. This approach was
independently invented by a number of people. The best-known variant is SYN
Cookies, whose principal originator is Daniel Bernstein. It is available in recent
FreeBSD and Linux systems, though it is not enabled by default. A variant of this
technique is also included in Windows 2000, XP, and later. This is used whenever
their TCP connections table overflows.
Alternatively, the system’s TCP/IP network code can be modified to selectively drop an entry for an incomplete connection from the TCP connections table
when it overflows, allowing a new connection attempt to proceed. This is known as
selective drop or random drop. On the assumption that the majority of the entries in
an overflowing table result from the attack, it is more likely that the dropped entry
will correspond to an attack packet. Hence its removal will have no consequence. If
not, then a legitimate connection attempt will fail, and will have to retry. However,
this approach does give new connection attempts a chance of succeeding rather than
being dropped immediately when the table overflows.
Another defense against SYN spoofing attacks includes modifying parameters
used in a system’s TCP/IP network code. These include the size of the TCP connections table and the timeout period used to remove entries from this table when
no response is received. These can be combined with suitable rate limits on the
organization’s network link to manage the maximum allowable rate of connection
requests. None of these changes can prevent these attacks, though they do make the
attacker’s task harder.
The best defense against broadcast amplification attacks is to block the use of
IP-directed broadcasts. This can be done either by the ISP or by any organization
whose systems could be used as an intermediary. As we noted earlier in this chapter, this and antispoofing filters are long-standing security recommendations that
all organizations should implement. More generally, limiting or blocking traffic to
suspicious services, or combinations of source and destination ports, can restrict the
types of reflection attacks that can be used against an organization.
Defending against attacks on application resources generally requires
modification to the applications targeted, such as Web servers. Defenses may
involve attempts to identify legitimate, generally human initiated, interactions from
automated DoS attacks. These often take the form of a graphical puzzle, a captcha,
which is easy for most humans to solve but difficult to automate. This approach
is used by many of the large portal sites like Hotmail and Yahoo. Alternatively,
applications may limit the rate of some types of interactions in order to continue to
provide some form of service. Some of these alternatives are explored in [KAND05].
Beyond these direct defenses against DoS attack mechanisms, overall good
system security practices should be maintained. The aim is to ensure that your
systems are not compromised and used as zombie systems. Suitable configuration
and monitoring of high performance, well-connected servers is also needed to help
ensure that they do not contribute to the problem as potential intermediary servers.
Lastly, if an organization is dependent on network services, it should consider
mirroring and replicating these servers over multiple sites with multiple network
7.7 / Responding to a denial-of-service Attack 263
connections. This is good general practice for high-performance servers, and
provides greater levels of reliability and fault tolerance in general and not just a
response to these types of attack