This chapter is from the book

This chapter is from the book

Of the three categories of attacksreconnaissance, access, and
denial-of-service (DoS)DoS attacks are the easiest to implement yet the
hardest to defeat. DoS attacks are based on packet flooding, which uses up
bandwidth, CPU, and memory resources on not just the victim device, but also
intervening devices, such as routers, switches, and firewalls.

When you are experiencing a DoS attack, one of the first things you need to
do is find out the actual kind of DoS attack that is affecting your network. As
you will see in the first section of this chapter, a variety of options are
available to you, including examining the CPU utilization of your routers, using
ACL statements with logging parameters, and using NetFlow.

When you know the kind of DoS attack directed at your network, you can
implement an appropriate solution. The remaining sections in this chapter
focus on these solutions, including TCP Intercept, CBAC, and rate limiting. Of
course, you always can use an ACL to block offending traffic; however, this
might introduce other problems, such as the blocking of legitimate traffic.
Therefore, in many cases, you need to use other tools, such as the ones
discussed in the last half of this chapter, to deal with DoS issues.

Detecting DoS Attacks

A wide variety of DoS attacks can occur. The most common DoS attacks use UDP
echos (Fraggle), ICMP echo and echo replies (Smurf), and TCP (TCP SYN flooding).
However, you nevershould assume that the DoS attack that you are
experiencing falls under one of these three types: Some do not fall under these
categories.

Common Attacks

One of the most common DoS attacks is the Smurf attack, which I covered in
Chapter 7, "Basic Access Lists." (Chapter 7 also covered how to use
ACLs to deal with the Smurf attack.) In a Smurf attack, the attacker sends a
flood of ICMP messages to a reflector or sets of reflectors, with the source IP
address in the ICMP echo messages spoofed. The hacker changes these addresses to
the address of the actual victim device or devices. The reflectors then
innocently reply to the echo messages, inadvertently sending the replies to the
victim. In many cases, the source address is a directed broadcast address,
allowing the attack to target a network segment instead of a specific host.
Based on this information, if you see a large number of ICMP echo replies
coming into your network, you probably are experiencing a Smurf attack, or at
least a derivative of this kind of attack. Likewise, if you are seeing a large
number of packets coming into your network with a directed broadcast address,
this would indicate that you are under attack. One method of preventing this is
to use the no ip directed-broadcast command on your router's
interfaces. I discussed this command in Chapter 4, "Disabling Unnecessary
Services."

The Fraggle DoS attack is similar to the Smurf attack, except that Fraggle
uses UDP echo and echo reply messages instead of ICMP messages. Because UDP
echos typically are filtered, Fraggle typically has a less likelihood of having
the same impact that Smurf does (I discussed in Chapter 4 how to defeat a
Fraggle attack by configuring the no service tcp-small-servers and no
service udp small-servers commands).

The other common attack is a TCP SYN flood attack, in which an attacker tries
to overwhelm one or more TCP services running on a machine. The attacker
executes this attack by sending a flood of TCP SYN segments to the victim. In
most cases, the hacker forges the source address to hide his tracks or possibly
to create another DoS attack against a second victim. Therefore, when the server
receives the TCP SYNs and tries to complete the three-way handshake, the process
fails: The server sends a SYN/ACK response to a bogus or invalid address and,
therefore, never gets the final ACK reply in the three-way handshake. During
this period, resources are tied up on the server for each of these half-open
(commonly called embryonic) connections. Because this kind of attack
typically is targeted at a specific machine, when you experience a slowing of
your server that offers TCP services, such as an e-mail, web, or FTP server, or
if one of these servers crashes or halts, this might indicate that it was (and
possibly still is) the victim of a TCP SYN flood attack.

Symptoms of Attacks

When your router is experiencing a DoS attack (including worm attacks),
either one directed at the router or one in which the router is a transit
device, you can look for the following to help you confirm your hunches:

Your router is seeing an unusually high number of ARP requests.

Your NAT/PAT address-translation tables have a large number of
entries.

The following sections discuss various methods for detecting and tracing DoS
attacks. However, one of the best solutions for detecting DoS attacks is to use
an IDS solution. A good IDS solution should tell you exactly the kind of
DoS attack that you are facing.

Examining CPU Utilization to Detect DoS Attacks

In any DoS attack situation, the network symptoms that you see typically will
be common, such as high CPU utilization on your devices or a high number of
certain kinds of packets. Therefore, one of the first things you want to do is
to log into your perimeter routers and firewalls and examine their CPU
utilization.

On a Cisco router, use the show processes cpu command to examine the
router's CPU utilization, as shown in Example 17-1.

The shaded line is what you should focus on. Three statistics are listed
here:

CPU utilization for five secondsThis is the CPU utilization
on the router for the last 5 seconds. The number after the slash (/) is the
percentage of CPU time spent at the interrupt level. During an interrupt, the
CPU must handle the functions for the process instead of an interface or a
specific ASIC (application-specific integrated circuit).

One minuteThis is the CPU utilization of the router over the
past minute.

Five minutesThis is the CPU utilization of the router over
the past 5 minutes.

In Example 17-1, the 5-second utilization is 92 percent and the 1-minute
utilization is 90 percent. Notice that the 5-minute utilization is only 45
percent. This probably indicates a brief spike in traffic. If all three of these
are at a higher number than normal and are close together in values, such as 75
or 95 percent (depending on your router's baseline, of course), this could
indicate a DoS attack. In this situation, you should look at other things on
your router to determine whether this is just an anomaly in traffic conditions
or a DoS attack.

A derivation of the show processes cpu command is the addition of the
history parameter. This command displays, in an ASCII graphical format,
the total CPU usage of the router over 1 minute, 1 hour, and 72 hours. Example
17-2 shows an example of the use of this command.

In Example 17-2, the Y-axis of the graph represents CPU utilization, and the
X-axis represents the increment period. In this example, I omitted the output
for the 1-minute and 72-hour output and listed only the hour output.

The maximum usage, represented by a *, is measured and recorded every second
(this is displayed at the very top of a vertical entry). The average usage is
measured over a period of 1 second and is represented by a #.

The very top of the graph lists the actual CPU utilization for the 1-minute
interval, which fluctuated between 60 and 80 percent utilization.

For worm attacks, examine the following information in the output of the
show process cpu command: ARP, IP Input, CEF, and IPC processes. Also
examine the following information in the output of the show processes
memory command: IP Input, ARP Input, IP Cache Ager, and CEF processes.

NOTE

Of course, looking at the CPU utilization during a DoS attack assumes that
you have captured a history of CPU utilization baselines during normal traffic
conditions. If you do not have this information and your CPU utilization is
running at 75 percent, this might be a normal condition for your router.
Therefore, you periodically should gather statistical information about your
router, including CPU utilization and the bandwidth utilization on each of its
interfaces. This will help you determine whether something abnormal, such as a
DoS attack, is directed at your router or is flowing through your router. Also,
if your CPU utilization is running at 100 percent because of a severe DoS or
worm attack, your router might reload itself. Therefore, you also should check
to see if your router periodically is reloading, which could indicate that you
are under attack.

Using ACLs to Detect DoS Attacks

One of the most common tools used to detect DoS attacks is ACLs. This is
especially true of your perimeter routers and router firewalls because these
devices already have ACLs in place to filter traffic. As I mentioned in Chapter
7, you always want to include a deny ip any any statement in your ACL at
the end. This is not necessary to drop traffic, but it does have the router keep
statistics on the number of matches on this statement. This can be useful in
determining whether a DoS attack is occurring.

ACL Counters

The first thing you should do is clear the counters for your ACL with the
following command:

Router# clear access-list counters [ACL_#_or_name]

After this, view the ACL in question with the show access-lists or
show ip access-list commands. Example 17-3 shows sample output from the
show access-list command.

Notice in this example that, after I cleared the ACL counters for ACL 100 and
then viewed the ACL the first time (right after clearing the ACL counters), the
match on the deny ip any any statement is 3183, which is relatively high
for just a couple of seconds between executing the two commands. Right after
executing the first show command, I re-executed it. Notice that in the
second or two between the execution of the two commands, the number of matches
more than doubled. In this example, I was sending a flood of ICMP packets from
three devices to one victim device.

Here are some important things to keep in mind about using ACLs to detect a
DoS attack:

In this example, I assumed that the traffic being dropped was the DoS
attack. You also need to examine the matches on permit entries
because your ACL might be permitting the DoS attack, such as a TCP SYN flood.
Again, a good baseline of this information should assist you in determining
whether a DoS attack is occurring. In other words, you should have gathered ACL
statistics in normal traffic periods, and then you can use this to make a
comparison.

Remember that because you are using extended ACLs, you can specify the IP
protocol, source anddestination addresses, and protocol information,
such as TCP and UDP port numbers as well as ICMP message types. This enables you
to be as specific as possible in determining a match.

If the ACL in question is applied to multiple interfaces, remember that
the ACL counters are an aggregate of all of the matches on allinterfaces
on which the ACL has been activated. In this situation, you might want to have a
separate named/numbered ACL for each interface.

Specific ACL Entries

Of course, the problem with the previous examination is that you can see that
your router is dropping a flood of traffic, but you do not see whattraffic the router is dropping. For example, if you do not want to allow any
type of ICMP traffic, or even if you want to permit only certain kinds of ICMP
traffic, put in the appropriate ACL entries so that, minimally, you can see ACL
statistics on matches. Refer to Figure 17-1 for an example. Here, no echo
messages should be allowed into the network, and only echo replies to the
management station are allowed.

This example not only sets up filtering, but it also has specific entries
that can be used to detect four DoS attacks: directed broadcast attacks
(Statement 1), which are used by many types of DoS attacks; a Smurf attack
(Statements 2, 3, and 4); a Fraggle attack (Statements 5 and 6), and TCP SYN
floods (Statements 7 and 8):

For a Smurf attack, if the entries in Statements 2 or 4 are increasing
rapidly, this indicates that Smurf reflectors are attacking you (you are the
victim). If you are the reflector, you will see entries in Statement 3 rapidly
increasing. This is especially true if you do not configure the group of
statements in Statement 1. However, to determine this, you would need to enable
logging for the ICMP ACL statements, which I discuss in the next
section.

For a Fraggle, attack, if the entries in Statement 5 are increasing, this
indicates that you are the victim; a large number of matches against Statement 6
indicates that you are the reflector.

For a TCP SYN flood attack, you will see the number of matches against
Statements 8 and 10 increasing many times over normal baseline numbers. What is
unusual about these two ACL statements is that they are normal ACL statements
allowing traffic to the e-mail and web servers. However, remember that the Cisco
IOS keeps track of the number of matches on all statements, so a large increase
in the number of matches for either of these two servers could indicate a TCP
SYN flood attack. Because there are many types of TCP flood attacks, using
various TCP flags, Statements 7 and 9 look at the other TCP flags for an
abnormal number of other TCP messages.

Also, the statements under Statement 1 block traffic sent to the network and
directed broadcast addresses of the internal network. These addresses are
commonly used in DoS attacks. By having specific entries in your ACL, you can
use the show access-lists command to determine more easily whether a DoS
attack is occurring.

ACL Logging

The main limit of the statistics from the show access-lists and
show ip access-list commands is that they can show you that a high number
of hits are occurring against one or a few ACL statements, but this does not
tell you who the attacker (or the victim, in some cases) is. One option is to
use the log or log-input parameters at the end of the ACL
statements in question. As you recall from Chapter 7, the main difference
between these two commands is that the log-input parameter displays the
input interface of the received packet and the Layer 2 source address in the
packet.

CAUTION

In either situation, remember that using either of these two parameters
disables CEF switching, which seriously impacts the performance of the router.
Therefore, use the log function to pinpoint the attack, including the victim and
the attacker, and then remove the log or log-input parameters from
your ACL statement(s).

Smurf Example

For example, assume that the router in Figure 17-1 is under a Smurf attack.
When you examine the router's ACL, you notice the output in Example
17-5.

In this situation, I probably would disable logging to the console but enable
logging to the internal buffer (this is discussed in Chapter 18, "Logging
Events." Therefore, when there is an inordinate number of log messages, the
console interface will not be overwhelmed.

Given the Smurf attack in the example, here is a snippet of the output
produced by log messages from a match on the ACL statement:

In this example, a single host is being attacked: 192.1.1.1. Also notice that
most of the ICMP traffic is coming from two networks: 201.1.1.0/24 and
205.8.8.0/24. By using the IANA Whois database
(http://www.iana.org), you should
be able to see who these addresses belong to. It is important to point out that
in a Smurf attack, these are probably not the actual attacker devices, but Smurf
reflectors (with Smurf, it is very unlikely that the attacker would use his own
address as a source, unless he is a script kiddie). However, at least you have a
starting point and should be able to contact the ISPs or administrators who are
responsible for these networks so that they can take the appropriate action.

Keep the following items in mind when using logging with ACLs:

Enabling logging with ACLs can have a small- to medium-size impact on
your router, depending on its model. Therefore, I recommend that you be careful
using the logging function on routers that are running at 80 percent utilization
or higherespecially with ACLs on high-speed interfaces.

Depending on the version of the Cisco IOS running on your router, logging
might affect the switching mode that the router must use to implement the
logging function.

If you are seeing matches against ACL entries in the show access-list
command, but you are not seeing any entries actually being logged (you
have added the log parameter to the ACL statement), try clearing the
route cache to force packets to be process-switched. Of course, this can cause a
lot of traffic to be dropped on a very busy router when it is in the process of
rebuilding the cache. To get around this specific problem, use a router that
supports CEF.

ACL logging does notdisplay every packet that matches an ACL
entry. Instead, you will see at least the first packet on a match for a session
and then packets at periodic intervals. The Cisco IOS uses rate limiting to
prevent logging from overloading the router's CPU. It is important to
remember that you will not see all packets that match an ACL statement when you
have logging enabled.

During a Smurf attack that involves multiple reflectors, the amount of
logging information might be overwhelming. In this instance, set up a separate
ACL statement that matches on a single reflector and logging for only this
reflector. Typically, this will be multiple devices from a single network, so
use an ACL that matched on all of these devices. This helps you determine all of
the devices in one reflector site.

TIP

Be as specific as possible in your ACL statements when looking for the DoS
attack. Use the log-input parameter so that you can see the interface
where the attack is coming from. If the router's interface is a multiaccess
interface, this information also will include the MAC address of the next-hop
router; use the show ip arp MAC_address command to see the
router's IP address.

NOTE

The purpose of this section on ACLs was to give you a basic understanding of
how to track down the type of DoS attack. Obviously, you can add or modify ACL
entries to determine the kind of DoS attack you are experiencing.

Damage Limitations

The attacker in a DoS attack wants to affect bandwidth and service levels, so
your first concern should be preventing this traffic from traversing your ISP
links. You could set up an ACL on your perimeter routers to block this traffic,
but this stops it only from entering your network; it does not prevent it from
traversing your ISP links.

In this situation, you need to contact your ISP and explain the situation.
Hopefully they also will investigate the problem on their end and either set up
a temporary ACL filter to block the offending traffic or set up rate limiting to
reduce the effect that the DoS attack will have. As I mentioned, this should be
a temporary filter: When the attack has been mitigated, these measures should be
removed.

Finding the Attacker

When you are the victim of a DoS attack, tracking down the actual attack, as
well as the perpetrator, can be a difficult and stressful task. Remember that
the source addresses in a DoS attack typically are forged and, therefore, are
not very helpful in finding the actual attacker. Therefore, finding the attacker
typically must be done on a hop-by-hop basis, tracing the attack from one router
to the next until you finally arrive at the source of the attack. As you saw in
the "Using ACLs to Detect DoS Attacks" section, this requires
administrators possibly to add ACL entries and/or add logging to specific ACL
entries, which can be a complex process. And because the path of the attack
might take you back through multiple ISPs, you typically must involve
law-enforcement agencies to get the kind of cooperation from ISPs and network
administrators that might be necessary to perform this kind of trace.

The Trace Process

Tracing DoS attacks is a straightforward process. In this subsection and the
following ones, I discuss the use of ACLs to perform the trace process. However,
other options, such as NetFlow, can be used as well. I discuss NetFlow after
discussing ACLs.

Remember that the source address in the packet probably is spoofed, so you
cannot assume anything about the location of the attacker. Therefore, you have
your work cut out for you: The actual trace process requires you to trace back,
router by router, to the real source of the attack. Figure 17-2 illustrates this
process. In this example, the e-mail server (192.1.1.1) is under a DoS attack.
The first thing that you would do is to log into RouterA, which I
am assuming is the router directly connected to the same segment as the
e-mail server. Remember that the DoS attack might be internal, not external, to
the network. From here, you would determine which interface the attack is coming
from, log into the next-hop router, and perform the same process, tracing this
back eventually to the hacker himself.

Trace Problems

In a Smurf attack, in which reflectors are used to instigate the attack
against a victim, it is fairly easy to determine who the reflectors are.
However, when you have found the reflectors, tracing the attack back to the
originator of the attack is difficult, if not impossible, because it must be
done on a hop-by-hop basis, probably through many different ISPs. Given this
tedious process, you face the following problems when tracking down the attacker
who instigated the DoS attack:

Because multiple administrators and networks typically are involved in
the trace-back process, it becomes a tedious and slow process tracing back the
attack to the real source. Even an unintelligent hacker knows that you will
attempt to trace his attack; therefore, the hacker limits the duration of the
DoS attack, which might not give you enough time to trace the attack.

If the attack goes through multiple networks or ISPs, and possibly even
through different countries, getting the appropriate assistance could be
difficult.

The attack might be coming from multiple sources, as in a Smurf attack.
With a Smurf attack, you need to trace the attack back to each reflector and
then, from each reflector, trace the attack back to the real source or sources
of the attack.

The attack might be perpetrated from a hacked computer that was
compromised by the hacker. Therefore, finding the actual perpetrator might be
impossible unless the hacked computer has detailed logs of unauthorized access
to it.

When you actually track down the DoS attacker, you will face legal and
political issues trying to sue for damages in a civil action. You will need
detailed proof of the attack to bring criminal actions against the
attackerand this can be very difficult if the attacker is in a different
country.

NOTE

Given these problems, you should realize that, in most cases, you will not be
able to find the attacker who instigated a DoS attack. Therefore, you should
pick your battles. In most cases, you will want to use tools to limit the effect
of a DoS attack and attempt to trace back attacks only when they are severe
enough to prevent your company from operating or reaching its business goals.
Also, if the trace involves multiple companies and ISPs, you typically must get
law-enforcement agencies involved to get the information necessary to find the
attacker.

Using NetFlow to Detect DoS Attacks

One of the problems of using the log or log-input parameters
with ACL statements is that it is very process-intensive for the router to
handle the logging function. Cisco provides another solution, called NetFlow
switching. NetFlow enables you to capture statistics of flows traveling through
your router. It is a transparent switching method that requires you only to
enable it. Unlike ACLs with logging, NetFlow is a switching technology that has
much less of an impact on the router. As with ACL logging, you can export
NetFlow information to a server, to be examined in more depth.

NetFlow Overview

NetFlow switching is a network-layer switching method that switches packets
at high speeds and captures statistics for traffic analysis. It is supported on
IP and IP-encapsulated traffic types over a variety of interfaces, including
interfaces with input ACLs.

NOTE

NetFlow is not supported on ISL trunk interfaces, ATM and Frame Relay
interfaces if more than one input ACL is used, and ATM LANE interfaces.

Cisco developed NetFlow switching to provide the following benefits:

Processing of ACL statements with little performance penalty (at least,
compared to many other switching modes)

Billing for bandwidth usage in corporate and ISP networks

Capturing of traffic for network management and capacity
planning

NetFlow uses flows to identify traffic. A flow is basically a unidirectional
session based on the following fields in an IP packet: IP protocol, source and
destination IP address, type of service, source and destination port numbers for
TCP and UDP flows, and input interface. When NetFlow identifies a new flow, an
entry is added to the NetFlow cache. This entry then is used to switch packets
and to perform ACL checking.

NetFlow Configuration

Enabling NetFlow is a simple process. You can use many optional parameters to
create a more efficient capturing process for traffic statistics. However, I
focus on only the basics of enabling NetFlow, exporting NetFlow statistics, and
examining the statistics.

Enabling NetFlow

Enabling NetFlow is done on your router's interface(s). When using it to
track down DoS attacks, I recommend that you enable it on an interface or
interfaces of your router where you think the source of the DoS attack is
originating. Here is the basic configuration to enable NetFlow:

The ip route-cache flow command enables NetFlow switching on a
router's interface. If you have a Cisco router that supports distributed
switching, such as the 7500 with RSP and VIP modules, you need to execute one
more command on the router's interface:

Router(config-if)# ip route-cache distributed

This command enables distributed switching with NetFlow.

Exporting NetFlow Data

Optionally, you can export NetFlow statistical data to an external device
that supports NetFlow data imports. After you set up the export function,
NetFlow information is exported every time a flow expires. A few products on the
market, including one from Cisco, can be used to decipher the exported
information. You then can use the NetFlow statistical information to generate
traffic-analysis reports and graphs. To enable export of NetFlow information,
use the following command:

Router(config)# ip flow-exportIP_address UDP_port_# [version 5]

With the ip flow-export command, you must specify the IP address of
the NetFlow server, as well as the UDP port number used on the server. There are
two versions of NetFlow: version 1 and 5. Version 1 is the default if no version
number is specified. To export information to a NetFlow server that supports
version 5, you must specify the version number in the command. One advantage
that version 5 has over version 1 is that version 5 includes a sequence number
in each segment. UDP is unreliable, so there is a chance that the NetFlow server
will not receive some exported NetFlow packets. Using the sequence number in
version 5 allows the NetFlow server to verify that it received all of the
NetFlow segments or determine that some are missing.

Examining and Clearing NetFlow Statistics

After you have set up NetFlow, use the show ip cache flow command to
examine the flows and their statistics:

Router# show ip cache [prefix mask] [type number] [verbose] flow

The prefix mask option displays entries in the cache that match the
prefix and subnet mask, limiting your output. Likewise, you can list the
specific interface, displaying only the flows for that interface. Example 17-6
displays the output of this command:

Here is an explanation of the information in Example 17-6, with reference to
the numbering on the right side. Statement 1 displays the percentage of the
distribution of packets based on their size. Notice that 100 percent of the
packets are in the 128-byte range.

Statement 2 displays some general statistics about NetFlow switching, such as
the total number of bytes that the cache table is using, as well as the number
of active flows. Also notice that the NetFlow statistics have not been cleared
since NetFlow was configured or the router was booted. To clear the flow
statistics, use the clear ip flow stats command.

Table 17-1 NetFlow Protocol Fields

Total number of flows for this protocol since the statistics
last were cleared

Flows/Sec

Average number of flows for the protocol per second for this
summary period

Bytes/Pkt

Average number of bytes for the packets associated with this
protocol for this summary period

Packets/Sec

Average number of packets per second for this summary
period

Active(Sec)/Flow

Total of all the seconds from the first to last packets of an
expired flow, or total flows for this protocol in the summary period

Idle(Sec)/Flow

Total idle time of all seconds since the last packet for this
protocol in the summary period

Table 17-2 NetFlow Flow Fields

Field

Description

SrcIf

The interface that the packet was received on

SrcIPaddress

The source IP address in the packet

DstIf

The interface that the packet was sent out of

DstIPAddress

The destination address in the packet

Pr

The IP protocol number (1 is ICMP)

SrcP

In hexadecimal, the source port number

DstP

In hexadecimal, the destination port number

Pkts

The number of packets for this flow

NOTE

It is important to point out that the port number information in the output
of the show ip cache flow command is in hexadecimal. Keep this in mind
when looking for particular flows in the cache.

NetFlow and DoS Attacks

Now that you have a basic understanding of how to set up NetFlow and examine
its statistics, this section looks at how to use this information to your
advantage when trying to determine whether you are experiencing a DoS attack.
The next few sections show some examples of different Worm and DoS attacks.

TIP

When you are under a heavy DoS attack, I highly recommend that you use
NetFlow instead of ACL logging, to help determine the kind of DoS attack as well
as information about where the attack is coming from. If you use ACL logging,
there is a chance that the overhead that this adds to your router will overwhelm
it, possibly causing it to crash.

W32.Blaster Worm

If you are experiencing high CPU utilization on your router, as well as
packet drops on your input interfaces, you might have an infestation of the
W32.Blaster worm or one of its derivatives. The W32.Blaster worm appears as UDP
traffic on port 69 with high volumes of traffic on ports 135 and 4444. The worm
propagates using valid file-sharing ports, such as TFTP and TCP port 135, which
is the Microsoft RPC protocol, and Kerberos authentication (TCP port 4444).
Blocking these ports can prevent its spread.

Example 17-7 shows a simple example of searching for the W32.Blaster Worm
infection/attack, based on the network shown previously in Figure 17-1.

Notice one interesting thing about the show command that I executed:
You can use the vertical bar (|) and the include parameter to display
only the results that match the string that you enter after this parameter. Port
0087, in hexadecimal, is 135 in decimal. To look for TFTP, use the hexadecimal
number of 0045; for Kerberos authentication, use 115c.

In the previous output, notice that one device, 192.1.1.1, which is the DMZ
web server, is scanning other internal devices using protocol 06 (TCP) with
a DstP of 0087 (135Microsoft RPC). With this information and the number of
random port 135 connections it is trying to make to internal devices, you
definitely should check out your web server.

TIP

Before beginning, you first should clear the NetFlow statistics and then
continually examine the statistics to look for incrementing patterns. This is
true for all DoS attacks.

Code Red Worm

At least three variations of the Code Red worm exist. All versions exploit a
security vulnerability in the Microsoft IIS web server product by sending a
specially formed URI to port 80 on a vulnerable system. Upon a successful
attack, the worm replaces the web page of the IIS server with graffiti. In
version 1 of the worm, an infected device did one of the following:

One problem with the version 1 worm was that it did not use truly random
addresses in its scan process; version 2 does. Version 2 also does not use the
hard-coded IP address of the White House's web server; it uses a DNS name
and does a DNS lookup to find the address. Both worms suffer the same
deficiency: They do not check to see if the devices that they are scanning and
trying to infect already are subverted.

Many Cisco products were affected by the amount of traffic that this worm
generated. For example, the CSS 11000 content switches, under a heavy worm
infestation, experienced memory-allocation errors that required them to be
rebooted. Likewise, the 600 DSL routers stopped forwarding traffic until they
also were rebooted. Cisco has introduced code fixes for all of its products that
experienced problems dealing with this worm.

Because the worm uses a common port, detecting it is slightly more difficult.
However, using NetFlow makes your task much easier. Because Code Red spreads
itself by looking for vulnerabilities in IIS, you should examine NetFlow
information and look for a TCP destination port of 80 (which is 0050 in
hexadecimal). The network shown previously in Figure 17-1 illustrates this in
Example 17-8.

As you can see in this example, there are a few HTTP requests from the web
server in the DMZ to internal addresses. If you see an abnormally high number of
HTTP requests with the same source address, or if the source address is a web
server itself, as is the case here, you have a problem. In this example, the DMZ
web server has been attacked successfully and is attempting to spread itself to
internal devices.

Smurf Attack

As mentioned throughout this book, the Smurf attack is one of the most common
types of DoS attacks because of its simplicity in implementing it on a
hacker's behalf. As with worms, you can use NetFlow to track the reflectors
and possibly the source(s) of the attack. Example 17-9 shows an example, based
on the network shown in Figure 17-1.

As you can see in this example, two networks seem to be set up as reflectors,
attacking the web server on the DMZ (192.1.1.1). Based on this information, you
can contact your ISP and the administrators of these networks to take corrective
action.

TIP

Besides using NetFlow for tracking down specific attacks, some people at Ohio
State University have developed a quick-and-dirty set of tools that uses NetFlow
records to detect network and host intrusions. More information about this nifty
project can be found at
http://www.usenix.org/publications/login/1999-9/osu.html.