Welcome to Volume 3, Issue 24 of The Internet Security Conference newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me.
Enjoy, and be safe,
As I mull over the newsletters we've pushed in 2001, I realize we've managed to touch upon a variety of topics, and have "attacked" the subject of security from many different angles. I'm especially pleased that we've been able to concentrate more on application-based attacks and countermeasures in 2001, and we'll continue to do so next year.
Our Insight archive at http://www.tisc2001.com/insight.html (also available as http://www.tisc-insight.com/insight.html) maintains copies of all past Insight columns. For your convenience, here's a list of 2001 columns...
Protecting Oracle, Pete Finnigan
Pushing IPsec Through NAT, Lisa Phifer
Managing Electronic Records and Evidence, Jeffrey H. Matsuura
How to Spot Source Address Spoofing, Rik Farrow
Are You Prepared In The Event Of A Disaster?, Mark T. Edmead
Introduction to LDAP Security, Sacha Faust
Air Travel Security, David M. Piscitello
External OS Commands: Backdoor or feature? Hacking with SAP R/3, Stefan Hoelzner
The Network Processor: Enabler of Wirespeed Gigabit Security, Dave Buchanan
Securing the Apache Web Server, Rik Farrow
Primer on Predictive Analysis, J. L. Stutzman
Your First Penetration Test, David M. Piscitello
False Security, Terry L. Davis, P.E.
Triangulation in Attack Analysis (Part II), J.L. Stutzman and D. Lemmon
Explaining the Gap between Specification and Actual Performance for IPsec VPN Systems, Ray Savarda and Matt Karash
Social Engineering: The Threat and The Solution, Chris Tobkin
Secure Remote Access with IPsec, Lisa Phifer and David Piscitello
Triangulation in Attack Analysis (Part I), J. L. Stutzman
Cryptographic Protection for the Twenty-First Century, Elaine Barker
Host Detection: Generating Arbitrary Responses to Identify Inter-networked Nodes, dethy
Vulnerability Reporting: Bugs in the bug reporting process, Ivan Arce
Honeypots: Sweet Idea, Sticky Business, David M. Piscitello
Intrusion Prevention: The Ultimate Security?, Mandy Andress
I hope you've enjoyed these columns as much as I've enjoyed tracking down the authors and inviting them to write for you. Have a safe and happy holiday seasonÍ
In today's column, Steve Kohalmi and Randy Charland consider how the application of Quality of Service measures implemented at the edge of a service provider network can complement packet filtering and other countermeasures, to provide a more comprehensive defense against Denial of Service Attacks.
If you're not familiar with DOS attacks in general, or simply want to learn more on this topic, please visit some of the excellent links available at http://www.tisc2001.com/links.html#DOSattacks.
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.
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 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.
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.
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 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.
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.
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.
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.