Note: This is an historic document. We are no longer maintaining the
content, but it may have value for research purposes. Pages linked to
from the document may no longer be available.
Internet Denial of Service Attacks and the Federal Response
Testimony of Katherine T. Fithen, Manager, CERT® Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Before the Subcommittee on Crime of the House Committee on the Judiciary and the Subcommittee on Criminal Justice Oversight of the Senate Committee on the Judiciary
February 29, 2000
Contents:
Introduction
Mr. Chairman and Members of the House and Senate Subcommittees: My name is
Katherine Fithen. I am the manager of the CERT® Coordination Center (CERT/CC),
which is part of the Software Engineering Institute (SEI) at Carnegie Mellon
University. Thank you for the opportunity to testify on the issue of Internet
denial-of-service attacks. Today I will describe distributed denial-of-service
attacks (DDoS), the role that the CERT/CC played, and what the future holds.
The CERT® Coordination Center (CERT/CC) is part of the Survivable Systems Initiative
of the Software Engineering Institute, a federally funded research and development
center operated by Carnegie Mellon University. The CERT/CC was established in
1988, after an Internet “worm” stopped 10% of the computers connected to the
Internet. This program—the first Internet security incident to make headline
news—was the wake-up call for network security. In response, the CERT/CC was
established at the SEI. The center was up and running in just two weeks, and
we have worked hard to maintain our ability to act quickly.
The CERT/CC charter is to work with the Internet community to respond to computer
security events, raise awareness of computer security issues, and prevent security
breaches. While continuing to respond to incidents, the CERT/CC provides training,
investigates tools and techniques that enable typical users and administrators
to effectively protect systems from damage caused by intruders, conducts research
leading to increased security of the Internet, and serves as a model to others
establishing incident response teams. The CERT/CC is now recognized by both
government and industry as a neutral, authoritative source of information assurance
data and expertise. More details about our work are attached to the end of this
testimony (see Meet the CERT Coordination
Center).
In the first full year of operation, 1989, The CERT/CC responded to 132 computer
security incidents. In 1999, the staff responded to more than 8,000 incidents.
In total, the CERT/CC staff has handled well over 24,000 incidents and analyzed
more than 1,500 computer vulnerabilities. This testimony is based on that first-hand
experience.
--Back to top.--
Distributed Denial-of-Service Tools
Distributed systems based on the client/server model have become increasingly
common. In recent months, there has been an increase in the development and
use of distributed network sniffers, scanners, and denial-of-service tools.
Attacks using these tools can involve a large number of sites simultaneously
and be focused to attack one or more victim hosts or networks.
Damaged systems include those used in the attack as well as the targeted victim.
For the victim, the impact can be extensive. For example, in a denial-of-service
attack using distributed technology, the attacked system observes simultaneous
attacks from all the nodes at once— flooding the network normally used to communicate
and trace the attacks and preventing any legitimate traffic from traversing
the network.
There are indications that the processes for discovering vulnerable sites,
compromising them, installing daemons (programs used in the attack), and concealing
the intrusion are largely automated, with each step being performed in “batch”
mode against many machines in one “session.” Attack daemons have been discovered
on a variety of operating systems with varying levels of security and system
management.
It is critical to plan and coordinate before an attack to ensure an adequate
response when an attack actually happens. Since the attack methodology is complex
and there is no single-point solution or “silver bullet,” resolution and restoration
of systems may be time-consuming. The bottom line is that an organization’s
systems may be subject at any time to distributed attacks that are extremely
difficult to trace or defend against. Only partial solutions are available.
Although an organization may be able to “harden” its own systems to help prevent
having its systems used as part of a distributed attack, there is essentially
nothing a site can do with currently available technology to prevent becoming
a victim of, for example, a coordinated network flood. The impact upon the site
and its operations is dictated by the (in)security of other sites and the ability
of a remote attacker to implant the tools and, subsequently, to control and
direct multiple systems worldwide to launch an attack. The result may be reduced
or unavailable network connectivity for extended periods of time, possibly days
or even weeks depending upon the number of sites attacking and the number of
possible attack networks that could be activated in parallel or sequentially.
Coordinated attacks across national boundaries have occurred. The tools and
attacks demonstrate that a network that optimizes its technology for speed and
reliability at the expense of security may experience neither speed nor reliability,
as intruders abuse the network or deny its services. The intruder technology
is evolving, and future tools may be more difficult to defeat.
Here are key points to note about distributed-system denial-of-service (DDoS)
tools:
- Intruders compromise systems through other means and install DDoS tools.
- The DDoS tools often are equipped with a variety of different attack types.
- Computers that are compromised with DDoS tools are aggregated into networks.
- These networks act in unison to attack a single victim. Any computer on
the Internet can be a victim.
- The networks can be activated remotely at a later date by a “master” computer.
- Communication between the master computer and the networks can be encrypted
and obfuscated to make it very difficult to locate the master.
- Once activated, the tools typically proceed on their own. No further communication
is necessary on the part of the intruder – it is not possible to discover
the master by tracing an ongoing attack. However, there may be evidence on
one or more of the machines in the DDoS network regarding the true location
of the master.
- Attacks from the network to the victim typically employ techniques designed
to obfuscate the true location of the machines in the DDoS network. This makes
it difficult to recognize the traffic (and thus block it), to trace the traffic
back from the victim to the nodes in the network, and to analyze an attack
while it is in progress.
- There are no proactive technical steps an organization can take to prevent
becoming a victim. Everyone’s security is intertwined. However, by preparing
a response in advance, sites can significantly diminish the impact. For information
on preparing to respond to these attacks, see the report on the results of
a workshop that the CERT Coordination Center organized in November 1999 to
address the imminent threat posed by the tools:
http://www.cert.org/reports/dsit_worksho-final.html
- The tools are rapidly evolving but have not reached their full potential
by any means.
- The magnitude of the attacks can overwhelm even the largest networks.
- Intruders are building networks of machines used in these attacks ranging
in size from tens to hundreds of machines. It is likely that some networks
are much larger.
- The individual nodes in the network can be automatically updated by the
master machines, enabling rapid evolution of tools on an existing base of
compromised machines.
- A variety of tools are available to detect DDoS tools. Each of these tools
has weaknesses, and none is a general-purpose solution. Some of these tools
can be found at
http://www.fbi.gov/nipc/trinoo.htm
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
http://www.iss.net/cgi-bin/dbt-display.exe/db_data/press_rel/release/122899199.plt
http://www.sans.org/y2k/stacheldraht.htm
- Currently, there is a nearly inexhaustible supply of computers with well-known
vulnerabilities that intruders can compromise and install DDoS tools on. Additionally,
many networks are configured in a way that facilitates the obfuscation techniques
used by intruders to conceal their identity. Information about how to configure
networks properly is available at
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2267.txt
- An archive of DDoS tools can be found at
http://packetstorm.securify.com/distributed/
- The CERT/CC published advisories and other documents about this topic:
http://www.cert.org/advisories/CA-2000-01.html
http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html
http://www.cert.org/tech_tips/denial_of_service.html
--Back to top.--
Role of the CERT/CC in Distributed Denial-of-Service Attacks
The CERT Coordination Center constantly monitors trends and watches for new
attack techniques and tools. As the attached timeline shows, we began seeing
distributed denial-of- service tools in early 1998. Denial-of-service attacks
are not new. (See, for example, the attached CERT advisories CA-96.21
on TCP “syn” flooding and CA-98.01
on “smurf” attacks, as well a “tech
tip” on denial-of-service attacks, which the CERT/CC wrote for system administrators
in 1997.)
By fall 1999, it was evident that steps needed to be taken to deal with increasingly
sophisticated intruder tools before they—and attacks using them—became widespread.
On November 2-4, 1999, the CERT/CC invited 30 experts from around the world
to address the problem of network attack tools that use distributed systems
in increasingly sophisticated ways. During the Distributed-Systems Intruder
Tools (DSIT) Workshop, participants discussed a large number of approaches to
preventing, detecting, and responding to distributed attacks. The CERT/CC invited
personnel who could contribute technically to the solutions regardless of their
position in their home organization or their “political” stature in the community.
Thus, the workshop effectively provided a venue for experts around the world
to share experiences, gain a common understanding, and creatively brainstorm
possible responses and solutions to this category of attack before the dissemination
of the attack tools?and the attacks themselves?became widespread. A paper, Results
of the Distributed-Systems Intruder Tools Workshop, is available on
the CERT web site (www.cert.org). This paper explains the threat
posed by these intruder tools and provides suggestions for safeguarding systems
from this type of malicious activity.
The CERT/CC continues to collaborate with the participants who attended the
workshop and with an additional group of security experts to address the ongoing
problem. Earlier this month, Rich Pethia of the CERT/CC, Alan Paller of the
SANS Institute, and Gene Spafford of Purdue University, prepared a Consensus
Roadmap for Defeating Distributed Denial of Service Attacks for the Partnership
for Critical Infrastructure Security. The most current version can be found
on the SANS Institute Web site (www.sans.org).
--Back to top.--
Internet Trends and Factors Affecting Security
The recent attacks against e-commerce sites demonstrate the opportunities that
attackers now have because of several Internet trends and related factors:
- The Internet is becoming increasingly complex and dynamic, but among those
connected to the Internet there is a lack of adequate knowledge about the
network and about security. The rush to the Internet, coupled with a lack
of understanding, is leading to the exposure of sensitive data and risk to
safety-critical systems. Misconfigured or outdated operating systems, mail
programs, and Web sites result in vulnerabilities that intruders can exploit.
Just one naive user with an easy-to-guess password increases an organization's
risk.
- When vendors release patches or upgrades to solve security problems, organizations'
systems often are not upgraded. The job may be too time-consuming, too complex,
or just at too low a priority for the system administration staff to handle.
With increased complexity comes the introduction of more vulnerabilities,
so solutions do not solve problems for the long term?system maintenance is
never-ending. Because managers do not fully understand the risks, they neither
give security a high enough priority nor assign adequate resources.
- Attack technology is developing in an open-source environment and is evolving
rapidly. Technology producers, system administrators, and users are improving
their ability to react to emerging problems, but they are behind and significant
damage to systems and infrastructure can occur before effective defenses can
be implemented. As long as defensive strategies are reactionary, this situation
will worsen.
- Currently, there are tens of thousands—perhaps even millions—of systems
with weak security connected to the Internet. Attackers are compromising these
machines and building attack networks (and will continue to do so). Attack
technology takes advantage of the power of the Internet to exploit its own
weaknesses and overcome defenses.
- Increasingly complex software is being written by programmers who have no
training in writing secure code and are working in organizations that sacrifice
the safety of their clients for speed to market. This complex software is
then being deployed in security- critical environments and applications, to
the detriment of all users.
- User demand for new software features instead of safety, coupled with industry
response to that demand, has resulted in software that is increasingly supportive
of subversion, computer viruses, data theft, and other malicious acts.
- Because of the scope and variety of the Internet, changing any particular
piece of technology usually cannot eliminate newly emerging problems; broad
community action is required. While point solutions can help dampen the effects
of attacks, robust solutions will come only with concentrated effort over
several years.
- The explosion in use of the Internet is straining our scarce technical talent.
The average level of system administrator technical competence has decreased
dramatically in the last 5 years as non-technical people are pressed into
service as system administrators. Additionally, there has been little organized
support of higher education programs that can train and produce new scientists
and educators with meaningful experience and expertise in this emerging discipline.
- The evolution of attack technology and the deployment of attack tools transcend
geography and national boundaries. Solutions must be international in scope.
- The difficulty of criminal investigation of cybercrime coupled with the
complexity of international law mean that successful apprehension and prosecution
of computer criminals is unlikely, and thus little deterrent value is realized.
- The number of directly connected homes, schools, libraries and other venues
without trained system administration and security staff is rapidly increasing.
These “always-on, rarely-protected” systems allow attackers to continue to
add new systems to their arsenal of captured weapons.
--Back to top.--
Near-Term Actions to Reduce Risk and Dampen the Effects
of Attacks
The problem of distributed denial-of-service attacks is complex, and there
are no easy answers. The Results
of the Distributed-System Intruder Tools Workshop contains specific
steps that can be taken by managers, system administrators, Internet service
providers, and computer security incident response teams. The Consensus Roadmap
for Defeating Distributed Denial of Service Attacks, contains additional
recommendations. The recommendations below,divided into four key problem areas,
can be found in the Consensus Roadmap.
Solutions to mitigate “spoofing”
Attackers often hide the identity of machines used to carry out an attack by
falsifying the source address of the network communication. This makes it more
difficult to identify the sources of attack traffic and sometimes shifts attention
onto innocent third parties. Limiting the ability of an attacker to spoof IP
source addresses will not stop attacks, but will dramatically shorten the time
needed to trace an attack back to its origins.
- User organizations and Internet service providers can
- ensure that traffic exiting an organization’s site, or entering an ISP’s
network from a site, carries a source address consistent with the set
of addresses for that site, and
- ensure that no traffic from “unroutable addresses” listed in RFC 1918
are sent from their sites. This activity is often called egress filtering.
- ISPs can provide backup to pick up spoofed traffic that is not caught by
user filters. ISPs may also be able to stop spoofing by accepting traffic
(and passing it along) only if it comes from authorized sources. This activity
is often called ingress filtering.
- Dial-up users are the source of some attacks. Putting an end to spoofing
by these users is also an important step.
- ISPs, universities, libraries and others that serve dial-up users should
ensure that proper filters are in place to prevent dial-up connections from
using spoofed addresses.
- Network equipment vendors should ensure that no-IP-spoofing is a user setting,
and the default setting, on their dial-up equipment.
Solutions to help stop broadcast amplification
In a common attack, the malicious user generates packets with a source address
of the site he wishes to attack (site A) (using spoofing) and then sends a series
of network packets to an organization with lots of computers (site B), using
an address that broadcasts the packets to every machine at site B. Unless precautions
have been taken, every machine at Site B will respond to the packets and send
data to the organization (site A) that was the target of the attack. The target
will be flooded and people at site A may blame the people at site B. Attacks
of this type often are referred to as Smurf attacks. In addition, the echo and
chargen services can be used to create oscillation attacks similar in effect
to Smurf. Solutions include the following:
- Unless an organization is aware of a legitimate need to support broadcast
or multicast traffic within its environment, the forwarding of directed broadcasts
should be turned off. Even when broadcast applications are legitimate, an
organization should block certain types of traffic sent to "broadcast" addresses
(e.g., ICMP Echo Reply) messages so that its systems cannot be used to effect
these Smurf attacks.
- Network hardware vendors should ensure that routers can turn off the forwarding
of IP directed broadcast packets as described in RFC 2644 and that this is
the default configuration of every router.
- Users should turn off echo and chargen services unless they have a specific
need for those services. (This is good advice, in general, for all network
services – they should be disabled unless known to be needed.)
Solutions that encourage appropriate response to attacks
Many organizations do not respond to complaints of attacks originating from
their sites or to attacks against their sites, or respond in a haphazard manner.
This makes containment and eradication of attacks difficult. Further, many organizations
fail to share information about attacks, giving the attacker community the advantage
of better intelligence sharing.
- User organizations should establish incident response policies and teams
with clearly defined responsibilities and procedures.
- ISPs should establish methods of responding quickly if they discover that
their systems were used for attacks on other organizations. They must also
have enough staffing to support these efforts.
- User organizations should encourage system administrators to participate
in industry- wide early warning systems, where their corporate identities
can be protected (if necessary), to counter rapid dissemination of information
among the attack community.
- Attacks and system flaws should be reported to appropriate authorities (e.g.,
vendors, response teams) so that the information can be applied to defenses
for other users.
Solutions to protect unprotected computers
Many computers are vulnerable to take-over for distributed denial-of-service
attacks because of inadequate implementation of well-known “best practices.”
When those computers are used in attacks, the result can be major costs, headaches,
and embarrassment for the owners of computers being attacked. Furthermore, once
a computer has been compromised, the data may be copied, altered or destroyed,
programs changed, and the system disabled. Solutions include the following:
- User organizations should check their systems periodically to determine
whether they have had malicious software installed, including DDoS Trojan
horse programs. If such software is found, the system should be restored to
a known good state.
- User organizations should reduce the vulnerability of their systems by installing
firewalls with rule sets that tightly limit transmission across the site’s
periphery (e.g. deny traffic, both incoming and outgoing, unless given specific
instructions to allow it).
- All machines, routers, and other Internet-accessible equipment should be
periodically checked to verify that all recommended security patches have
been installed.
- The security community should maintain and publicize a current “Top-20 Exploited
Vulnerabilities” and the “Top 20 Attacks” list of currently most-often-exploited
vulnerabilities to help system administrators set priorities.
- Users should turn off services that are not required and limit access to
vulnerable management services (e.g., RPC-based services).
- Users and vendors should cooperate to create “system-hardening” scripts
that can be used by less sophisticated users to close known holes and tighten
settings to make their systems more secure. Users should employ these tools
when they are available.
- System software vendors should ship systems where security defaults are
set to the highest level of security rather than the lowest level of security.
These “secure out-of-the-box” configurations will greatly aid novice users
and system administrators. They will furthermore save critically scarce time
for even the most experienced security professionals.
- System administrators should deploy “best practice” tools including firewalls
(as described above), intrusion detection systems, virus detection software,
and software to detect unauthorized changes to files. Use of software to detect
unauthorized changes may also be helpful in restoring compromised systems
to normal function.
- System and network administrators should be given time and support for training
and enhancement of their skills. System administrators and auditors should
be periodically certified to verify that their security knowledge and skills
are current.
--Back to top.--
Prognosis for the Future
In spite of preparation and protective measures that can be taken now, the
problem of conquering DDoS attacks requires a long-term effort to define and
implement effective solutions. The Consensus Roadmap for Defeating Distributed
Denial of Service Attacks identifies these actions that should be considered:
- Establish load and traffic volume monitoring at ISPs to provide early warning
of attacks.
- Accelerate the adoption of the IPsec components of Internet Protocol Version
6 and Secure Domain Name System.
- Increase the emphasis on security in the research and development of Internet
II.
- Support the development of tools that automatically generate router access
control lists for firewall and router policy.
- Encourage the development of software and hardware that is engineered for
safety with possibly vulnerable settings and services turned off, and encourage
vendors to automate security updating for their clients.
- Sponsor research in network protocols and infrastructure to implement real-time
flow analysis and flow control.
- Encourage wider adoption of routers and switches that can perform sophisticated
filtering with minimal performance degradation.
- Sponsor continuing topological studies of the Internet to understand the
nature of “choke points.”
- Test deployment and continue research in anomaly-based, and other forms
of intrusion detection
- Support community-wide consensus of uniform security policies to protect
systems and to outline security responsibilities of network operators, Internet
service providers, and Internet users.
- Encourage development and deployment of a secure communications infrastructure
that can be used by network operators and Internet service providers to enable
real-time collaboration when dealing with attacks.
- Sponsor research and development leading to safer operating systems that
are also easier to maintain and manage.
- Sponsor research into survivable systems that are better able to resist,
recognize, and recover from attacks while still providing critical functionality.
- Sponsor research into better forensic tools and methods to trace and apprehend
malicious users without forcing the adoption of privacy-invading monitoring.
- Provide meaningful infrastructure support for centers of excellence in information
security education and research to produce a new generation of leaders in
the field.
- Consider changes in government procurement policy to emphasize security
and safety rather than simply cost when acquiring information systems, and
to hold managers accountable for poor security.
--Back to top.--
Conclusion
We have discussed for many years the tremendous interconnectedness and interdependency
among computer systems on the Internet. As a result, the security of each system
on the Internet depends on the security of all other systems on the network.
The distributed denial-of-service attacks clearly demonstrate this interdependency.
Any computer system can be a victim of a DDoS attack, and there is little system
owners can do beyond depending upon others to protect their systems from being
used as a launch site in a DDoS attack. To address the distributed denial-of-service
attacks and other security problems on the Internet, we must continue to work
together. We must pool our expertise, take steps to protect ourselves, and help
others protect themselves.
Prepared for presentation on the Web February 2000
Disclaimers and copyright information
