|
Denial-of-Service attacks:
Understanding network
vulnerabilities.
Introduction
By adopting and employing stable, pre-emptive strategies for avoiding and
site intrusions and the resulting disruptions, executives and
practitioners can bolster their company’s defences against attacks like
those recently highlighted in the media. These incidents, as unfortunate
as they may be, emphasize what will soon become a common refrain: Security
on the Web requires teamwork and attentiveness by all members of the
Internet community.
Denial-of-Service (DoS) attacks is a phenomenon that has recently plagued
a number of well-known online companies. This paper will explore DoS
attack methods; best practices for implementing sound strategies for risk
management; and how best to equip systems and people to recognize and
respond to attacks should they occur.
Key Topics
Placing risk in the proper context
Defining Denial-of-Service
methods and remedies
Defending against Distributed
Denial-of-Service attacks
Understanding basic Denial of-Service response methods
Looking to the future: The likelihood of more sophisticated attacks
Placing risk in the proper context
There is no longer any question that the Internet is revolutionizing the
way companies
communicate and conduct business. Its remarkable growth is already
translating into significant business rewards—financial and
otherwise—especially for those who are first to implement. At the same
time, with every opportunity comes a measure of risk.
By nature, the Web is public, distributed, connected and highly
dynamic—subject
to phenomenal growth in terms of infrastructure, the number of people
online—as well as the sheer volume and types of applications running
across and beyond today’s complex corporate environments. Security threats
and attacks can often be traced to hackers, who enjoy the thrill of
pushing security boundaries, pointing out companies’ security weaknesses
and winning the respect of their peers. These traits are fostering a new
generation of skilled hackers armed with sophisticated tools designed to
attack the weakest link in a network. DoS attacks point out the heavy
price that companies can pay when security is lacking, and underscore the
vulnerabilities of the weakest link in a given entity.
Network environments are complicated. Security solutions are most
effective when
they can be customized to a specific installation. Unfortunately, a high
percentage of
individuals involved in building and maintaining Web sites and
infrastructures for these
environments have little knowledge of security protocols. As a result,
many of today’s
Web hosting systems and networks are vulnerable to break-ins and
disruptions.
Still, learning to build and maintain secure Web sites is only one piece
of the security
puzzle. Security gaps must be detected, new technologies implemented, and
tools and best practices developed for minimizing risk and avoiding the
repercussions
of service interruptions—or worse.
That said, it is important to note that creating a secure posture for
e-business is not a single effort; it is an ongoing process. The effort
takes time, and must be continually refined to become an integral part of
standard business operations. Security approaches that take a holistic
view of hardware, software, services and networks have the best chance of
succeeding.
To help ensure and manage Internet security, you can begin by following
three
fundamental guidelines:
• Understand your dependencies on the Internet
• Maintain constant awareness of the status and nature of those
dependencies
• Be prepared to react quickly yet thoughtfully to changes in the
environment.
Remember, successful online businesses all share a distinguishing
characteristic:
awareness and effective management of security risks. Although security
gaps will
continue to emerge, enterprises can mitigate risk by exercising diligence
and implementing
proactive processes.
DoS attacks: What are they?
When DoS attacks occur, the hacker’s objective is to render target
systems
inaccessible by legitimate users. During a recent spate of incidents,
hackers effectively
flooded the companies’ Web servers and communication links—temporarily
halting access.
Fortunately, this type of attack does not threaten credit card information
or other
corporate data stored on host systems, which could otherwise be vulnerable
to
viewing, tampering or theft. Nevertheless, DoS occurrences can pose
serious problems
for companies whose very business depends on their ability to service
customers on the Web. For these organizations, downtime constitutes a
closed
store; customers can shift their allegiance with the click of a mouse.
The nature of DoS attacks can vary—from the more publicized incidents that
can
be remedied with operating system fixes, to very sophisticated violations
that are
more difficult to detect and avoid. The following section provides a
summary of the
types and nature of DoS attacks, as well as their remedies.
DoS attack methods and remedies
Numerous DoS attack methods have been documented. Attacks that
directly
target host systems can most often be checked with operating system
patches. It
is much more difficult, however, to defend against attacks that flood
networks with
data packets.
Network flooding attacks can be categorized as “Smurf,” “TCP SYN,” “UDP,”
“TCP”
and combinations thereof.
•Smurf
During a Smurf1 attack, the hacker floods the network with Internet
Control Message
Protocol (ICMP) ping response messages. Ping is the simplest kind of
activity
you can have on the Internet, and is routinely employed by hackers to hunt
for
active servers.
These requests are forwarded to a directed broadcast address; the source
address
is set to the address of the target system, which then becomes flooded
with ping
response packets from all the hosts on the selected network. The attack
system
can amplify its original ping request hundreds of times. The original
address is
hidden behind the forged address. Furthermore, by bouncing the attack off
a
number of networks, effective Smurf attacks make it impossible for the
victimized
system to filter out the intrusive data.
Although this scenario is complex, Smurf attacks can be stopped if all
leaf routers—
the router at the top of an IP subnet that defines the subnet—are
configured not
to forward directed broadcast packets. This is strongly recommended by
IETF
(Internet Engineering Task Force) and the Computer Emergency Response Team
(CERT). Unfortunately, many sites have not implemented this type of
filtering.
Smurf attacks can also be handled with upstream rate limiting, which
maintains total
ICMP traffic to approximately 2.5 percent—high enough to handle expected
ICMP
traffic, but low enough to keep large attacks at bay.
•
ICMP
An ICMP flood attack is similar to Smurf, but without the amplification
caused by
sending packets to broadcast addresses. Similar remedies apply.
•
TCP SYN
A TCP SYN flood2 sends erroneous Transmission Control Protocol (TCP)
requests
to the target system, which cannot complete the connections. The hacker
hides his
or her identity by using the address of an innocent party—further
complicating
attempts to trace the hacker. Incomplete connection requests fill up the
target’s
request table, preventing it from accepting anymore valid requests.
These type of attacks can be handled with a defence called “random early
drop,”
which, as the name implies, randomly deletes incomplete connection
requests.
Today, “patches” are available for most operating systems. Cisco routers
have
implemented another defence called TCP Intercept,3 which reportedly helps
protect
host systems.
•UDP
A UDP flood sends large numbers of User Datagram Protocol (UDP) packets to
the target system, effectively tying up available network bandwidth.
Packets typically
contain forged source addresses to prevent simple filtering.
The best way to deflect UDP attacks is to have all peered boundary routers
implement
Network Ingress Filtering,4 which blocks packets with clearly forged
source
addresses from entering the Internet in the first place. While this method
does not
prevent UDP floods, it will indicate their source. Upstream rate limiting
of UDP traffic
is another defensive approach to UDP attacks, and can be achieved in much
the
same way as ICMP limiting. The problem is that different sites may have
different
volumes of normal UDP traffic. Limiting should thus be undertaken with
care.
•TCP
TCP floods are similar to UDP floods, except the attacker uses TCP packets
instead
of UDP packets. TCP floods create a problem unlike the UDP case—upstream
rate
limiting is not an option, since most valid traffic is over TCP. The only
defence for TCP
floods is to enforce Network Ingress Filtering.
•Distributed Denial of Service (DDoS)
Distributed Denial of Service (DDoS)5 attacks are harder to remedy than
simple DoS
attacks, and therefore require a more comprehensive set of approaches. By
utilizing
DoS building blocks, DDoS takes a more sophisticated approach by
replicating
the attacking host hundreds of times around the Internet.
These distributed attack agents are controlled remotely from a central
location manned by one or more “handlers.” Even if one attack system is
traced and shut down, others can continue their assault, making it
difficult to eliminate the problem. Nonetheless, defending against each
component of these well orchestrated incidents can still help. Most
network vulnerability scanners can detect common vulnerabilities, which
can be
patched to prevent loading of the DDoS agent.
A
number of DDoS programs have been developed by hackers over the past few
years. The ones that are most prevalent in widespread attacks include
Floodnet,
Trinoo, TFN, Stacheldraht and TFN2K.
Floodnet (Netstrike) is a JavaTM application that inundates the target
host with
requests for non-existent pages and queries to the search engines. It uses
a form of
TCP/IP flooding that attacks inbound and outbound data. This form of
TCP/IP flooding
saturates not only the CPU, but also the network—filling up disk space
used
for logging. Floodnet is a cooperative system; the debilitating
application is downloaded
by a willing perpetrator. In 1998, Floodnet was used for an online sit-in
as a
political protest called NetStrike. The protests were directed at the Web
sites of the
Department of Defence, the president of Mexico and the Frankfurt Stock
Exchange.
Floodnet agents can be identified by an intrusion detection system, then
filtered
based upon the packet content.
Trinoo 6 is the first and simplest of the DDoS systems. In this case, the
target and
date of the attack is controlled by the master, and contains only the UDP
flood
package. Its agents are detected with remote scanning.
Tribal Flood Network (TFN)7 comprises multiple DoS attacks: Smurf, TCP SYN
flood,
UDP flood, and ICMP flood. Its agents can be detected with remote
scanning.
Stacheldraht 8 (German for “barbed wire”) is based on TFN, and
incorporates
multiple DoS attacks: Smurf, TCP SYN flood, UDP flood and ICMP flood. Its
agents
can be detected with remote scanning.
TFN2k9–Although similar to TFN, TFN2k attacks are much harder to detect.
Communications are encrypted, and there is no default key. Agents can be
detected
with a remote scanner if a key is known, or with a host-based tool like
National
Infrastructure Protection Centre's (NIPC) find_ddos.
DDoS Defence Planning
This section details additional measures that can be employed to help
protect
against DoS attacks. It begins by describing general security practices
that
every organization should have in place, then focuses on intrusion
detection—
a key factor in defending against DoS attacks. Finally, it provides a
detailed
description of steps that can help prevent DoS attacks, followed by a
discussion
of incident management.
e-business security checklist
_ Have you implemented a thorough and aggressive security policy that is
reflected throughout the business—including firewall configurations,
access
controls and employee communications?
_ Have you received endorsement by all levels of management and the
Board of Directors to implement effective security measures?
_ Have you fully integrated established security processes and procedures
with your organization’s systems management software?
_ Do you have operating systems that are configured to the most secure
settings? Are vendor-supplied password default settings replaced with your
own secure passwords?
_ Have you installed firewalls on outside borders, as well as internal
borders?
Have the default settings on the firewall application been changed?
_ Have you adopted intrusion detection software? Similar to installing
burglar
alarms and motion detectors, intrusion detection is equally critical for
internal
and external networks. Complementary policy-based roles and
responsibilities
should be assigned and used at the application layer to prevent Trojan
horse software.
_ Have you distributed antivirus software? The best antivirus systems will
have
easy, effective update mechanisms for thorough, up-to-date implementation.
_ Can you regularly validate installed software inventories? Software
should
be obtained from sources that are consistent with corporate security
policy.
_ Are clients equipped with enhanced security capabilities for network
access?
It is important to establish access rights via hardware-based security
elements
such as embedded security subsystem, smart-cards and secure access
tokens. Usage privileges and access control should be authenticated via
Public Key Infrastructure-based credentials.
_ Have you implemented a user administration system? Enterprise solutions
should be established to enable centralized support staff to easily
create,
modify and delete user accounts that are consistent with the corporation’s
security policy.
_ Have you established rules for password selection? Determine very clear
guidelines for passwords, e.g., six characters with at least one numeral,
and
develop an easy way to verify. Passwords should be changed periodically.
Users should not store their passwords in their applications, or on or
near
their systems.
_ Have you conducted a security awareness campaign to regularly remind
employees of their security responsibilities (Web-based certification or
regular
e-mails, etc.)?
_ Do you perform security audits on a regular basis? These should be
unannounced
and random—some electronic, some physical, some concealed
and others overt. The purpose of these audits is to test whether policies
are
being implemented and whether practices are effective. The goal of some
audits, for example, may be to attempt to break into a target system,
access
valuable data if possible, and determine if the intrusion was noticed by
those
charged with monitoring the systems.
_ Have you designated someone as the main network security contact and
determined clear procedures for reporting and responding to security
issues?
_ Do your employees clearly understand that they should report all
incidents
that seem to breach the security policy? Do they know whom to contact?
_ Can you ensure that system administrators stay abreast of security
advisories
and make security-related changes in a timely manner? These people are
your first, best defence; they need to take a proactive role and be ready
to
react quickly to security issues.
_ Do you have a clear policy for action when an employee leaves the
company,
regardless of the reason? Measures should be taken to quickly disable
an ex-employee’s building and computer access, delete or redistribute
computer accounts, and change all passwords and access codes known
by the employee.
•Risk management
Companies should deploy a risk-management solution to help centrally
manage
attacks, threats and exposures by correlating security information from
firewalls,
intrusion detectors, vulnerability scanning tools and other security
check-points. This
helps administrators eliminate “clutter” such as false-positives, and
respond with
adaptive security measures.
Integrated security management also makes it easier for system
administrators—
who are not necessarily security experts—to monitor and assess security
risks in
real-time and with a high degree of integrity and confidence across an
organization’s
multiple security checkpoints. Automated countermeasures help ensure
limited
access to business partners, customers, suppliers, internal employees and
other
authorized users.
• Intrusion detection
In matters of network security, corrective actions to intrusions should be
taken as
soon as possible. Intrusion Detection Systems (IDS) support network
managers
in two ways: They alert them promptly so that planned responses can be
invoked,
and help them determine whether an unusual traffic pattern is an attack or
a
random event caused by non-malicious actions. IDS can detect when
malicious
users are employing your site to launch attacks against another site.
Intrusion detection
systems can be designed for network-based and host-based systems.
Network-based IDS are attached to the network; they detect attacks by
analyzing
the content of network packets sent over the wire. An unusually high
number
of TCP, UDP, or ICMP packets sent to a single destination can easily be
detected.
IDS are configured to determine if these packets should be considered
attacks or
normal traffic. Tivoli SecureWay Risk Manager 11 is a good example of a
product
solution capable of recognizing basic attacks (Smurf, TCP SYN flood, UDP
flood,
TCP flood) and preventing DDoS incidents.
Host-based IDS are software components that attempt to detect attacks
against
the computers on which the IDS is installed. Host-based IDS can analyze
the
network packets received on the network interface, as well as the log
files written
by the operating system or by applications running on the computer.
Typically, a
host-based IDS can detect DoS attacks against Web servers by analyzing its
log
in real-time.
Sites should install both network and host-based detection systems. Rapid
availability
of network analyzers must be assured to help determine the nature of an
incident,
and to help formulate possible filtering/rate limiting responses in the
event of an actual
DoS or DDoS attack.
Additional DDoS defence planning
The previous sections have outlined sound security and intrusion detection
practices
that all organizations should implement. Sites more vulnerable to DDoS
attacks
require additional measures, which can help organizations respond in a
calm,
prudent manner.
Be prepared: Establish a response plan before an attack occurs:
• Develop a documented incident management plan (see p. 11)
• Create a list of the names and numbers of your security team and
securing partners
who can begin analysis of attacks
• Maintain a list of available emergency response services
• Know the name and number of your Internet Service Provider (ISP)
contact, who
can provide additional filtering/limiting
• Know the name and number of your law enforcement contact
• Work with your ISP to establish proactive rate limiting of ICMP12 and
define procedures
for implementing new filters or rate limits
• Install intrusion detection systems that are capable of recognizing
basic attacks
(Smurf, TCP SYN flood, UDP flood, ICMP flood)
• Ensure rapid availability of network analyzers to determine the nature
of an attack
and formulate possible filtering/rate limiting responses should an actual
attack occur.
Understand basic DoS response methods
It is important to know how to address each type of DoS attack.
Be a good neighbour
Defending against DDoS attacks is especially challenging; traditional
security
strategies are simply not sufficient. Defence management requires the
cooperation
of multiple organizations in the Internet community; organizations
experiencing
an attack can do little to stop or track these incidents without the help
of others.
A victimized system is highly dependent upon its ISP and its upstream
routers—as
well as administrators at remote sites—to help limit and stop such
assaults.
Attacks are better controlled if all organizations practice basic “good
neighbour”
policies that limit the use of their sites as “agents” or “soldiers” in
Distributed DoS
attacks. These measures require that the company:
• Implement Network Ingress Filtering.16 on all boundary routers. This
type of filtering
blocks all packets with forged source addresses from moving from the site
to
the Internet. This filtering stops Smurf attacks, while simplifying attack
filtering
and tracking. It is important to note that the Internet Engineering Task
Force has
advanced the network ingress filtering Request for Comment (RFC) to a
status
of Best Current Practices (BCP).
•
Disable directed broadcast messages at leaf routers.17 The routers closest
to end-user
systems know the broadcast addresses for their subnets. Therefore, they
can
be configured not to forward packets directed to broadcast addresses.
Blocking
directed broadcast packets stops the amplification used in Smurf attacks,
but does
not halt legitimate broadcasts. It prevents only those broadcasts that are
going from
leaf nodes upwards. In addition, if a broadcast is trying to move up from
a leaf and it
couldn’t possibly have originated on the sub-network that the leaf is on,
the packet’s
origin address was probably forged and should be considered suspect. As
with
ingress filtering, the IETF has just elevated the directed broadcast
filtering RFC to a
status of BCP.
•
Scan external hosts for vulnerabilities to prevent installation of new
DDoS agents.18
Current DDoS installation tools appear to use well-known vulnerabilities
in some
RPC services; fixing these known weaknesses will help to shield a site’s
systems
from attack.
•
Scan external hosts for the existence of known DDoS agents.19, 20
Detecting and
removing existing DDoS agents will also help prevent DDoS attacks.
•
Report attacks to local law enforcement and industry organizations.
A good summary of these and related countermeasures is contained in the
IETF
working draft, “Security Expectations for Internet Service Providers,” by
Tom Killalea.21
Secure Web site configurations
There are several security practices that, if implemented during a Web
site’s system
configuration, can reduce the likelihood of future attacks. A sound IT
security policy
should provide guidance to Web masters and Web system administrators
during the
system setup and subsequent deployment. This policy should entail:
•
Guidance on installing and configuring peripheral packet filters and
Internet firewalls
as a first line of defence
•
A list of TCP/IP services that are not required for Web site function.
These services
should be disabled
•
Installation of devices to ensure that configured controls do not change;
these
should include intrusion-detection “health checking” tools
•
Application of timely security fixes to the operating system and Web
server,
including replacement of vendor-supplied default settings for passwords,
etc.
•
Regular scanning of the Internet/intranets to detect vulnerabilities.
Unless specific traffic is allowed to reach the Web server, no service can
be
provided. Therefore, you must allow certain TCP/IP traffic to reach the
Web server.
Generally, this is TCP ports 80 and 443. It is very difficult to defend
against a DoS
attack on a Web server on one of these ports, since the normal primary
defence
mechanisms, such as routers and firewalls, are configured to allow traffic
through.
Hence, special steps are needed.
First, consider where the Web server will reside within the
infrastructure. Traditionally,
the Web server is located between filtering devices, such as firewalls and
routers.
This places it in a "demilitarized" zone (DMZ), which offers some
protection from
Internet intrusions. The internal network receives protection from the Web
server.
Outside filtering devices permit only ports 80 and 443 to reach the Web
server;
other potentially dangerous traffic, such as ICMP, is inhibited. The
inside filtering
device is important, since the Web server itself should not rely on other
hosts within
the secure LAN. Although you must allow potentially dangerous parties
access to
your Web server, careful measures should be taken to prevent unwanted
entry. (There
are many reference books that address the different DMZ methods in more
detail).
The second step is to configure these filtering devices to comply with the
service
you are providing, while restricting everything else. Proper configuration
of firewalls
and routers can be a complex task, and is often assigned to highly skilled
security
consultants. Many types of undesirable attacks, such as TCP and UDP, as
well as
the methods for blocking them, have been described in this paper. It is
important
to remember that in addition to blocking traffic, attacks can also be
directed at your
infrastructure.
A
key consideration of comprehensive intrusion detection can help
discover when an unwanted intruder has been attempting unauthorized use.
Deny logs triggered by these filtering devices should be sent to a logging
server
for analysis and storage. Much like filtering-device logs, Web server logs
provide
excellent sources for detecting intrusions. Many DoS attacks can be
detected by
the signature they leave in the Web server log files. More sophisticated
mechanisms
include intrusion detection boxes, which perform network “sniffing” as
they seek
out suspect signatures.
A simpler technique involves writing a piece of shell code that notices
exception
patterns like unusual CPU utilization, or a dramatic increase in the
number of threads
currently running on the Web server. If such patterns are detected, the
tools page
can alert key personnel. Of course, this method takes some tuning to
determine
what is truly unusual, versus what constitutes a simple increase in normal
service
requests. Nevertheless, this has proven to be an effective approach for
circumventing
DoS attacks.
It is critical to develop, document and test a detailed response plan
before problems
occur. In the case of a prolonged DoS attack, an appropriate response is
to continue to keep the problem away from the Web server complex. This
would
involve pushing the offending traffic away from the Web server and back
into the
supporting infrastructure network, then pushing it away from the
infrastructure and
back into the assigned ISP, who would help in the recovery process. Other
remedial
tactics for deflecting a severe attack include:
• Adding filter rules to the Web server or operating system to block
traffic associated
with the attack. Not all Web servers or operating systems provide this
function, so
a deliberate check is recommended
• Adding filter rules to routers and/or firewalls to block undesirable
traffic
• Adding rules to divert unwelcome traffic to a nonexistent host IP on the
LAN
• Minimizing exposure of IP pool addresses. If there is no route, the
packet will
collapse at the nearest full routing router.
Incident management
When an incident occurs, security personnel are faced with many different
and
difficult choices. At the same time, hasty, improper reactions can only
make matters
worse. Before any actions are taken, several key questions must be
answered:
• Has an incident actually occurred? Human error or a software failure can
sometimes
mimic the actions of an intruder.
• Was any damage really done? In many incidents, the perpetrator gains
unauthorized
access, but doesn’t actually access privileged information or alter data.
• Is it important to collect and protect evidence that might be used in an
investigation?
Is it important to get systems back into normal operation as soon as
possible?
• Is it acceptable to assume that data has been changed or deleted? How do
you
determine if changes have been made?
• Does it matter if people inside and outside the organization hear about
the incident?
• Could this event happen again?
The answers to some of these questions may be contradictory. For example,
collecting and protecting evidence may not be possible if the primary goal
is
to get systems and services back into normal operation immediately.
Because
such choices must be made quickly—when an incident is actually detected—
a well-defined process is vital to helping security personnel take
appropriate
and necessary actions.
An Internet Security Event Response Process (ISERP) should be designed to
help
companies react in a rapid, structured, efficient and effective manner.
The ISERP
should be carried out by a group of people possessing a variety of
skills—not only
in relevant technologies, but also in non-technical areas such as public
relations.
This group is referred to as the “Response Team.” By effectively
organizing responses,
the ISERP allows organizations to optimize the protection that
technological components
provide. This will in turn extend protection to a company’s data, systems
and
services, safeguarding the business’s reputation. The ISERP plan comprises
four
elements, which should be clearly documented:
•
The process description articulates what needs to be done from a
high-level
operational standpoint—but not how it should be done. The process
description
thus remains independent of the specific technological components and the
configuration of a company’s current environment, and can be easily
adapted to
accommodate change. The process description should include—at a minimum—
contact information for your security specialists, ISPs and enterprise
security vendors.
• Scope and goals describes the scope, context, inputs and outputs and
external
connections, plus required mechanisms and measurements.
•
Functionality defines diagrams and descriptions of each of the major
sub-processes,
including Internet security event notification, categorization,
investigation, reaction,
restoration, defence strengthening and documentation. Process testing,
review and
updating are also addressed.
•
Staffing and assignments provide detailed definition on process roles,
assignments
and associated responsibilities.
In the event of a DoS attack:
_
Work with your ISP and emergency response team to perform rate limiting
and
other steps outlined on pages 4-7. If these do not work, try steps 2 and
3.
_
Change the IP address of the target and update the DNS to reflect the new
address. Most of these attacks, once initiated, are then left to run. They
do not
look up the IP address at each attempt and therefore do not go to the
correct
address. In these cases, an enterprise can block intrusions at the router
level.
The problem with this approach is caching; in the time it takes for the
DNS information
to propagate, the attack could be over—before the change is completed.
_
Investigate the actual attack by working with the ISP, who can check each
router.
If the attack spans multiple ISPs, the providers must work together. When
severe
attacks occur, it may be appropriate to contact federal law enforcement,
specifically
the FBI, for assistance. In order to trace one connection to the source of
the attack, the location of the master station must be known before
appropriate
actions can be taken.
DDoS attacks have two distinct types of victims: end targets—the sites
under
attack, and soldiers or agents—companies whose systems have been
compromised
and are now controlled by the hacker. Typically, organizations become the
hacker’s soldier, rather than the end target. Hackers assign soldiers by
exploiting
weaknesses and defects in networks and operating systems, which gains them
root/administrator access. Next, they install software to hide the
break-in and all
subsequent activities. The software they employ includes a process to
remotely
control the victimized system and use it for subsequent attacks on others.
DDoS attacks make detective work extremely difficult. Although the packets
flooding
the network—those with source and destination addresses—must be inspected,
this is not really helpful, since a target’s IP address is the destination
and the source
address is random. The only valid information available is the hardware
address of
the last router the packet passed through before reaching its final
destination.
Sometimes, this provides insight into the ISP, who may be passing the
flood of packets.
The greater the complexity of a company’s LAN or WAN, the more steps it
will
take to access the initial outside router. A company may even have to
trace its own
internal routers first. Next, a packet from the other side of that outside
boundary
router must be obtained. Since the enterprise under attack would not own
this
router, cooperation is required from the network administrator, who can
obtain the
hardware address of the previous router. Finally, a packet from the other
side of that
previous router must be found.
These steps must be performed over and over, from network to network,
until the
hardware address of one soldier machine is determined. Note that the
success
of DDoS attacks on the scale of a gigabit of packets per second will
depend on
hundreds of soldier systems. Once one soldier is located, the next effort
is to trace
it back to the controlling system. There may be information on the soldier
system
that describes its origin or the original compromise that led to the setup
of the
soldier system.
Another tactic is to track the controlling system when the controller next
deploys the
soldier system. This type of tracking can only be done when the controller
is active.
It may involve multiple intermediate links, limiting its chance of
success. Both of
these approaches should be done in parallel with tracking down additional
soldier
systems. Shutting off soldier systems can provide immediate relief from a
portion of
the attack.
The above tactic is from the point of view of the victim. The owner of the
soldier
system may have a different objective: to restore their system. Their
recovery may
remove the chance of examining the compromised system for clues to the
origin
of the attack; however, their cooperation can still allow placement of a
network IDS
to deflect attempted contacts by the controlling system. In this event, a
request to
do a bit-level copy of the system’s disk storage might be granted, opening
a larger
window of time to examine the system for additional evidence (particularly
if one
“peeks” beneath the file system layer and examines the raw disk blocks to
locate
intruder data file contents subsequently deleted).
Again, knowing your service providers and having the right contact
information can speed this process. If you are looking for a drive’s full
data forensics, be sure to make a bit-copy of the drive (if possible) and
conduct the exam on copies of that mirror. Using monitoring tools to
detect active soldiers is easy. An IDS should be able to pick up both
incoming and outgoing floods. If an organization’s routers are configured
properly,
outbound traffic should not appear to originate from outside the network.
Some
new routers provide this capability, but are turned off by default. Also,
since the
masters of these soldiers (shall we call them “generals”?) can use
“connectionless”
protocols (udp/icmp), they can also disguise the address of the
“generals’” orders.
This makes detection much more difficult, and of limited value.
Looking to the future
Over time, the variety and sophistication of network attacks are likely to
increase.
The Internet technical community has repeatedly risen to the challenge of
closing
security exposures, and will undoubtedly do the same regarding DDoS
attacks.
A
promising new approach to blocking and tracking DDoS attacks is the packet
tagging22 method. Backbone routers add tagging information to packets to
help
trace them back to their real source. Another encouraging area involves
finding ways
to share attack data while removing sensitive packets that might
inadvertently
disclose private or confidential information. This is referred to as
“blinding” the data
captured by intrusion detection systems so that details like “who is
surfing which
Web sites” are hidden from view. If there is a subsequent investigation,
the security
officer can unlock the relevant records.
System design techniques that appear to be effective for defending against
DDoS
attacks avoid single points of failure; that is, they have built-in
redundancy. An
example of this method is distributed replication of caching servers,
where multiple
servers, maintaining similar content, are spread geographically.
Work is also underway to make operating systems more secure. The concepts
behind evaluated systems are being adapted for broader use. An area that
needs
further research is the improvement of forensic tools to apprehend
hackers.
Conclusions
DoS attacks should be viewed as a risk management issue—one that can be
effectively dealt with like other business issues. Having appropriate
plans in place
allows organizations to deal with attacks on their systems in a
controlled, consistent
manner, in an environment where duties and actions are clearly defined and
understood
by all key players. Two plans are essential:
•
A preventive plan can help ensure that appropriate measures are taken to
maintain
business continuity. These include installing software to detect and
prevent attacks,
as well as software to identify the nature of the attack. Because
preventive measures
are typically not 100 percent effective, a plan must consider how to deal
with
security breaches when they do happen.
•
The incident response plan outlines the steps to take should a security
breach
event occur, and specifies responsibilities for executing necessary tasks.
A clear-cut
plan can prevent panic, as well as ineffective or sometimes detrimental
actions.
In many parts of the world, neighbourhood “watch” programs rely on members
of
the community to help keep other residents safe. The community of
e-business is
no different; responsible users of the Internet should adhere to “good
neighbour”
principles. When a problem does arise, the community should join forces to
maintain
their collective security.
The principles of being a good neighbour on the Internet include:
•
Securing one’s own systems to help prevent against them being compromised
or
used against others
•
Conducting regular testing of those systems for vulnerabilities
•
Instituting a process to proactively monitor systems activity and take
action when
any attempt is made to illegally gain access to those systems
•
Reporting factual information promptly
•
Avoid spreading inaccurate or untrue information that could create or
exacerbate
a situation.
Cooperation with authorities is essential. Timely responses to law
enforcement
subpoenas for critical information, for example, can help locate and
identify hackers
and minimize further disruptions to your business or others on the
network.
The collective strength of an informed, responsible and cooperative
Internet
community is a powerful security tool that can aid in the success of your
business,
as well as those on whom it depends.
For more information
To learn how the professionals of Lindengrove security and privacy
services can help
you protect your IT infrastructure, contact your Lindengrove sales
representative, or contact us here:
References
1 Smurf
http://www.cert.org/advisories/CA-98.01.smurf.html
2 TCP-SYN flood Information
ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding
3 TCP Intercept
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/intercpt.htm
4 Network Ingress Filtering RFC 2267 (January 1998)
http://www.ietf.org/rfc/rfc2267.txt
5 CERT analysis of DDoS
http://www.cert.org/advisories/CA-2000-01.html
http://staff.washington.edu/dittrich/talks/cert/
http://www.cert.org/reports/dsit_workshop.pdf
6
Trinoo
http://staff.washington.edu/dittrich/misc/trinoo.analysis
7 Tribe Flood Network (TFN)
http://staff.washington.edu/dittrich/misc/tfn.analysis
8 Stacheldraht
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
9 TFN2K
http://packetstorm.securify.com/distributed/TFN2k_Analysis.htm
10 ICMP
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/
qcpart4/qcpolts.htm
http://www.cisco.com/warp/public/707/newsflash.html
11 Network Ingress Filtering RFC 2267 (January 1998)
http://www.ietf.org/rfc/rfc2267.txt
12 Directed Broadcast Filtering
http://www.cert.org/advisories/CA-98.01.smurf.html
http://www.ietf.org/rfc/rfc2644.txt
13 NSA Host Vulnerability Scanner
http://dr.watson.ibm.com/nsa
14 NIPC’s find_ddos
http://www.fbi.gov/nipc/trinoo.htm
15 Internet Engineering Task Force working draft,
"Security Expectations for Internet Service Providers"
http://www.ietf.org/internet-drafts/draft-ietf-grip-isp-expectations-03.
Updates will be posted at
http://ww.ietf.org/ieft/...abstracts.txt.
16 Packet tagging
http://www.cs.washington.edu/homes/savage/traceback.html
BUY SECURELY ONLINE
|
Partners? We are looking
for partners to distribute our product and provide first line support.
Please
contact us if you would like further info. |
|
