[iwar] [fc:Quality.of.Service.for.Denial.of.Service.Attack.Prevention]

From: Fred Cohen (fc@all.net)
Date: 2001-12-29 18:46:04


Return-Path: <sentto-279987-4153-1009680322-fc=all.net@returns.groups.yahoo.com>
Delivered-To: fc@all.net
Received: from 204.181.12.215 [204.181.12.215] by localhost with POP3 (fetchmail-5.7.4) for fc@localhost (single-drop); Sat, 29 Dec 2001 18:48:08 -0800 (PST)
Received: (qmail 7038 invoked by uid 510); 30 Dec 2001 02:45:41 -0000
Received: from n15.groups.yahoo.com (216.115.96.65) by all.net with SMTP; 30 Dec 2001 02:45:41 -0000
X-eGroups-Return: sentto-279987-4153-1009680322-fc=all.net@returns.groups.yahoo.com
Received: from [216.115.97.191] by n15.groups.yahoo.com with NNFMP; 30 Dec 2001 02:44:56 -0000
X-Sender: fc@red.all.net
X-Apparently-To: iwar@onelist.com
Received: (EGP: mail-8_0_1_3); 30 Dec 2001 02:45:22 -0000
Received: (qmail 15373 invoked from network); 30 Dec 2001 02:45:22 -0000
Received: from unknown (216.115.97.172) by m5.grp.snv.yahoo.com with QMQP; 30 Dec 2001 02:45:22 -0000
Received: from unknown (HELO red.all.net) (12.232.125.69) by mta2.grp.snv.yahoo.com with SMTP; 30 Dec 2001 02:45:21 -0000
Received: (from fc@localhost) by red.all.net (8.11.2/8.11.2) id fBU2k4V19485 for iwar@onelist.com; Sat, 29 Dec 2001 18:46:04 -0800
Message-Id: <200112300246.fBU2k4V19485@red.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
X-Mailer: don't even ask
X-Mailer: ELM [version 2.5 PL3]
From: Fred Cohen <fc@all.net>
X-Yahoo-Profile: fcallnet
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Delivered-To: mailing list iwar@yahoogroups.com
Precedence: bulk
List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com>
Date: Sat, 29 Dec 2001 18:46:04 -0800 (PST)
Subject: [iwar] [fc:Quality.of.Service.for.Denial.of.Service.Attack.Prevention]
Reply-To: iwar@yahoogroups.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

Quality of Service for Denial of Service Attack Prevention 
Steve Kohalmi, Randy Charland, TISC Insight, 12/28/2001
No URL available.

Introduction

Denial of Service (DOS) attacks work by overwhelming network or system resources 
with traffic that forces them to devote CPU, memory and transmission resources to 
the attack packets, that would otherwise be available for normal business traffic.

Unscrupulous hackers can bring enterprise network services to their knees by bombarding 
them with malicious traffic in the guise of
ordinary  pings, fragmented packets requiring reassembly, and various
control  messages. The effects of DOS attacks can be devastating. In
addition  to the time and energy spent trying to troubleshoot and
restore network  connectivity, DOS attacks also reduce productivity as
users wait for  their network connections to come back up. The lost
revenue problem for  e-commerce is even worse - every minute lost to a
DOS attack is measured  in transactions that are not completed.
Furthermore, impatient shoppers  may visit a site not under attack and
shop elsewhere.

In case of attack, Customer Premises Equipment (CPE) firewalls may automatically 
engage local DOS protection. This is a good start. But an IT department should coordinate 
countermeasures with its service provider as soon as it is aware its enterprise is 
under attack, and ask for help filtering the unwanted traffic. By this time, however, 
the damage has already begun, and the recovery task can be tremendous. 
The value of intelligent packet filtering at the network edge is apparent. Less 
apparent, perhaps, is how packet-filtering technology can be effectively augmented 
by Quality of Service (QOS) mechanisms. Local DOS protection is of limited value 
if the Wide Area Network (WAN) link remains clogged. DOS attacks inundate networked 
systems using bandwidth as a weapon; as such, bandwidth management and QOS tools 
can provide a strong defence. This article focuses on how service providers can use 
QOS capabilities proactively at the network edge, to help their customers avoid the 
effects of DOS attacks.

Denial of Service Attacks

DOS attacks can be perpetrated in many ways. In the most common cases, volumes of 
malicious traffic either squeeze out legitimate traffic or create such a workload 
on resources that they are prevented from their intended functioning. In a typical 
DOS attack scenario, an assailantís computer either transmits the rogue traffic directly 
to the target systems or prompts an intermediary system (often referred to as a "zombie") 
to unwittingly generate the overwhelming traffic. In the latter case, an attacker 
with an insignificant network connection will co-opt a zombie possessing adequate 
resources to generate the volume of traffic required to bring down the target network 
or server. Distributed Denial of Service (DDOS) attacks take this method a step further 
by enlisting a large number of zombies in a coordinated attack.

In defending against the various types of DOS attacks, network
operators  can provide invaluable collateral support by determining
acceptable  traffic patterns and tuning their service edge systemsí QOS
controls to  keep the network within those bounds. It may be possible to
isolate and  restrain excessive, potentially harmful traffic with
advanced traffic  classification and QOS techniques.

The Quality of Service Toolbox

The primary function network administrators expect from any QOS system is traffic 
separation. Separating traffic flows from one another is a fundamental building block 
of an effective QOS system, and absolutely necessary when using a switch or router 
for DOS protection.

Classification -------------- To separate data flows one must first be
able to distinctly identify  them. This process of traffic
classification can be as simple as  identifying traffic flows by the
input port, or as complicated as  statefully distinguishing dynamically
allocated flows. Stateful traffic  classification is especially
important for traffic types where control  protocols dynamically set up
data flows, e.g. VOIP. The only way the  classification engine can
identify and assign correct polices to these  data flows is by
monitoring their control protocols to determine their  state.

Traffic Policing ---------------- A service edge system may police
ingress traffic to determine whether it  is within the bounds of a
customerís subscribed bandwidth parameters.  Typically this traffic is
measured against two parameters: the Committed  Information Rate (CIR)
and the Peak Information Rate (PIR). Traffic  flows exceeding these
prescribed rates might be discarded, marked or  demoted (for increased
discard probability). Advanced policing  mechanisms use a dual-token
bucket algorithm with a marking scheme, such  as the Internet
Engineering Task Forceís (IETFís) two-rate three-color  marker (trTCM).

A color-aware, dual token bucket policing scheme maintains a CIR, a
PIR,  and an associated maximum burst size on all incoming traffic for
each  traffic class. The rates and the burst sizes are adjustable so
that  services can be created with various bandwidth capacities and
burst  tolerances. Each packet is conceptually painted with one of
three  colors upon exiting the metering process: green is for traffic
within  the CIR profile, yellow is for traffic over the CIR but within
the PIR  profile, and red is for traffic over the PIR profile. The color
marker  may then be used to affect the egress QOS traffic handling
applied to a  packet, or to apply a rule that explicitly drops the
packet.

Egress Queue Acceptance Control ------------------------------- If the
arrival rate of traffic at an egress interface of a switch never exceeds the transmission 
rate of that interface, there is no need for queuing. However, since traffic is rarely 
so cooperative, queues are provided to deal with inevitable, albeit temporary, variation 
in
arrival  rates. If unbalanced arrival conditions are sustained, or last
longer  than what would be considered normal for jitter or a burst of
data, then  some of the traffic may be discarded as the queues begin to
fill up.

All data placed into a given queue are not created equal. Management of packet discard 
strategies to control what traffic is dropped is known
as  queue acceptance control. Queue management of this type can even
drive  different discard probabilities for traffic destined to the same
queue.  A data flow that was policed and trTCM-marked as red, yellow,
and green  needs different parameters to drive different discard
probabilities for  the individual colors. These parameters are called
weights.

The most common queue acceptance control mechanism is the Random Early Detect (RED) 
algorithm. RED was developed primarily to provide congestion feedback to TCP/IP flows, 
but it can also be used for active queue management of all packet types. RED imposes 
increasing drop probabilities once a queue passes a set threshold - its effective 
length. This averts a sudden hard limit to the queue size. In  addition,
some switches implement RED as a means to actively manage  system buffer
resources, as those resources grow scarce.

Weighted RED (WRED) improves the process by enabling multiple classes
of  RED treatment per queue. Each class has different thresholds and
drop  probabilities. Using WRED, trTCM-marked green packets can be
treated on  a base level, while yellow packets can be evaluated against
a shorter  effective queue length and use a steeper probability function
for  dropping packets. And trTCM-marked red packets can be evaluated
against  a still more aggressive RED treatment. WRED therefore allows a
single  queue to support multiple behaviors within a single ordered
traffic  flow.

Traffic Scheduling ------------------ Traffic scheduling comes under two
categories: traffic shaping and link  sharing. Traffic shaping is a
method of limiting the amount of traffic  transmitted through an output
link. It is often referred to as a non- work conserving function since
by limiting the amount of data  transferred; the output link may be
under-utilized. Although traffic  shaping is not necessary for all
traffic, it is very important when a  traffic flow must be limited in
bandwidth, especially when many logical  links share the same physical
link. Traffic shaping insures that a  given flow does not use more
capacity than it should. The leaky bucket  algorithm is an effective
technique for traffic shaping.

Link sharing defines the relationship between multiple traffic flows on an output 
link. Link sharing always fills the output link if traffic is available, and is thus 
viewed as a work conserving function. Link sharing decides how traffic stored in 
multiple queues will be
aggregated  and transferred onto a link. Link sharing makes no
assumptions about  the size or nature of the link, but concentrates on
how traffic will  share the link. There are many algorithms for link
sharing such as  strict Priority Queuing, Round-Robin, Weighted
Round-Robin, Class-Based  Queuing, and Weighted Fair Queuing.

A new link sharing method called Priority Weighted Fair Queuing (PWFQ) provides 
the great flexibility in the construction of egress traffic conditioners by allowing 
multiple queues at the same priority level, each with a different weight. This flexibility 
provides the granularity to enable egress traffic management to meet the diverse 
range of application performance requirements that exist in todayís networks.

Traffic shaping and scheduling can be layered upon one another to achieve complex 
bandwidth management schemes.

Management and Accounting Statistics
------------------------------------ To properly manage and account for
the use of QOS utilities, it is  necessary to collect detailed
statistics on each and every packet  processed by a service edge system.
In this way, the services can be  monitored in real-time, facilitating
timely detection and management of  security threats. This is true
whether one is applying QOS for DOS  attack prevention or for
application service level guarantees.

Defense Strategies

The following section provides a few examples of how the QOS toolbox
can  be put to use defending against various DOS attack scenarios and
provide  valuable services to the customers of network operators.

UDP DDOS attacks ---------------- Recently CERT, the pre-eminent center
of Internet security expertise,  was the target of a DDOS attack. In
this assault a vast number of  large, fragmented User Datagram Protocol
(UDP) packets were sent to  CERTís web port from multiple zombies. While
web servers can usually  handle IP packet reassembly, packet fragments
must first be stored until  all the fragments of a packet are received;
only then can they be  reassembled and ultimately serviced. This process
is resource  intensive, and quickly overwhelmed the servers when too
many fragments  were received

Limiting the number of fragmented UDP packets allowed in the network using QOS utilities 
could avert a fragmented UDP DDOS attack. Network administrators can practice good 
Internet citizenship by controlling
the  volume of fragmented IP packets that their systems originate, thus reducing 
the effectiveness of these systems as zombies. 
Unfortunately, the distributed nature of this type of attack means that regardless 
of how much an individual source clamps down on the sending rate, the sheer numbers 
of senders can still overwhelm the target of an attack. The target, however, can 
lessen the problem by limiting the number of fragmented packets it accepts from the 
network. The farther away from the end system this happens, the fewer resources are 
wasted. The perfect place to implement this usage based filtering is at the aggregation 
point in the network, where traffic from the Internet is aggregated onto the customersí 
access links. Here, traffic can be classified based on the destination address, protocol, 
port number, and whether it is fragmented. A service edge switch at an aggregation 
point can police or shape the aggregate of this traffic to an acceptable volume, 
aggressively discarding the excess traffic with policing or WRED.

Ping-of-Death DOS Attacks ------------------------- The Ping-of-Death is
one of the oldest and best-known type of DOS  attacks. The attacker
sends an Internet Control Message Protocol (ICMP)  echo request (Ping,
or almost any other ICMP datagram) to a server with  a maximum size data
attached. Many IP stacks will fail on the  reassembly of the returned
packet due to its large size. This attack  preys on the possible
vulnerability of the IP stack implementation of  the target system.
However, it can be used in a bandwidth based DOS  attack as well, in
what is popularly called a "Smurf" attack. The  attacker multicasts or
broadcasts echo requests to a group of hosts,  using the target systemís
address as the source of the request. The  large number of Ping
responses returned by the hosts overwhelms both the  network and the
target system.

A potential way to protect a system against Ping-of-Death attacks is to limit the 
amount of data but not the number of packets consumed by Ping datagrams. This can 
be accomplished by queuing Ping packets separately from other traffic. Two WRED processes 
are employed on the Pingsí
queue.  One WRED process controls the number of packets, while the other
one  controls the number of bytes in the queue. If the number of
packets  allowed into the queue is kept fairly large, while the number
of bytes  is kept very small (barely enough to hold a few average sized
messages)  large Pings will be discarded while legal Pings will still go
through.  During normal operation the short Ping packets never trigger
the byte  limiting WRED process, but during an attack with
substantially  increased-length Ping packets, the queue quickly
overflows (potentially  with as little as one packet). As such, long
Ping packets are discarded  while short ones that fit into the queue are
treated normally.

Smurf attacks using multicast Ping requests can also be thwarted by limiting the 
number of Ping reply packets in the network. Policing the number of Ping replies 
the router receives from a particular subnet,
and  shaping what it forwards to a subnet, will help prevent congestion.

TCP-based DOS Attacks --------------------- Several other DOS attack
schemes stress a target systemís ability to  process connection requests
at high rates. Policing incoming rates for  each protocol type or
traffic flow is not the most effective defense  against these assaults,
as this could lead to artificial under- utilization of a lightly loaded
system. Link sharing, on the other  hand, can be effectively used for
prevention of a deluge of Transmission  Control Protocol (TCP)
synchronization requests, known as a "SYN flood",  and other similar
request processing attacks. When the target system is  lightly loaded,
it is capable of handling many session initializations,  but when it
already has a large number of open sessions and their  related traffic,
large bursts of initialization requests should be  prevented.
Classifying new TCP SYN packets and queuing them separately  from
established sessions can effectively separate the two traffic  types.
PWFQ can then be used to allocate bandwidth preferentially to established flows 
versus new session initialization.

Conclusion

When used in conjunction with comprehensive packet filtering, QOS utilities provide 
effective protection against DOS attacks, especially when implemented at the edge 
of the service providersí network in service-enabling systems. Traffic classification, 
policing, queue acceptance control, and scheduling, as well as statistics and event 
collection work together to thwart the aggression of hackers. These capabilities 
are easily configured to keep WAN links open and
enterprise  systems functioning normally, even when malicious traffic
has been  targeted against them.

About The Author

Randy Charland is a Senior Product Manager for Quarry Technologies. He is responsible 
for product definition and implementation strategy of IP security services. Prior 
to joining Quarry, Mr. Charland was a network security and management consultant 
at Lucent Technologies where he was responsible for developing and implementing network 
security and management solutions for high profile customers such as Genuity and 
NaviSite. Before Lucent, he was a member of the US Air Force and stationed at the 
Air Force Communications Agency (AFCA). While at AFCA, Mr. Charland was a key architect 
of the Air Force Barrier Reef and Base Information Protect (BIP) programs to develop 
common security architectures for core AF networks. Mr. Charland holds a BSEE from 
Ohio State University.

Copyright 2001 Core Competence &amp; Mactivity, Inc.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/WoOlbB/7.PDAA/ySSFAA/kgFolB/TM
---------------------------------------------------------------------~->

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



This archive was generated by hypermail 2.1.2 : 2001-12-31 21:00:00 PST