Detect and Limit DoS Attacks

A collection of procedures to prevent DoS (denial-of-service) attacks

Recent denial-of-service attacks against popular websites have made headlines and raised consciousness about vulnerability. These insidious attacks employ a variety of mechanisms to wreak havoc. The suggestions below are a collection of techniques using PacketWise to reduce the impact of a variety of different types of attacks. You can pursue any or all. Keep in mind that PacketWise products are not firewalls, but they do offer some rather sophisticated help in this particular security arena.

The ultimate targets of DOS attacks are not the only victims. Frequently, if the type of DoS attack involves flooding a target with too much traffic or too many TCP connections, the attack methodology creates countless other victims — so-called "launch pads." Launch pads are third-party servers that are forced into being unwitting assailants; they're infected with instructions to generate large amounts of traffic or connections to be sent to the intended final target.

The attack-foiling methods described here:

• Monitor for attacks

• Restrict the bandwidth used by violating hosts
  
  

• Limit the rate to or from one host

• Limit ICMP floods

• Limit concurrent flows of one type
  

• Detect pseudo-address attacks

• Detect portscan attacks

• Disrupt virus attacks
  

Monitor for Attacks

The techniques in this section show you several different ways to check whether a denial-of-service attack has occurred on your network. The other sections show you more proactive ways to detect and limit DoS attacks.

Monitor Hosts with a High Number of Failed Flows and/or New Flows

A high number of new flows per minute and/or failed flows per minute can indicate an attack is occurring. Adaptive response offers several agent templates that monitor flows to/from hosts to help in the detection of SYN attacks and spoofing. After setting up these adaptive response agents, you can be notified automatically when a host has excessive failed flows and/or new flows per minute, thus alerting you to a possible attack. In addition, you can automatically restrict the bandwidth of these violating hosts so that you can minimize the problem while you do further investigation. For complete details, see Use Agents to Detect SYN Attacks and Use Agents to Detect Spoofing.

Look for Unwelcome Hosts

One way to detect potential attacks is to look for abnormal hosts on your network, such as hosts consuming an excessive amount of bandwidth. To help you in this detection, the adaptive response feature has several agent templates in the host category. These agents use information from PacketShaper's host database, allowing you to monitor per-host bandwidth, flows, and connections. For details on each of the host agents, see Host Agent Templates. For examples on using these agents, see Identify and Control High Bandwidth Hosts, Use Agents to Detect Spoofing, and Use Agents to Detect SYN Attacks.

Additional Monitoring Techniques

PacketWise includes additional techniques you can use if you would like to do even more in-depth monitoring.

Monitor class hits.

Class hits let you know the number of times flows match a class. By monitoring class hits regularly, you'll know what constitutes a normal number of hits in a class and an abnormally high number of hits will be apparent.

1. Click the monitor tab. The Monitor Traffic window appears.
   
   
2. Look at the numbers in the Class Hits column. These values have been accumulating since the unit was last reset or since the statistics were reset.
   
   
3. If desired, reset the monitor statistics and check back later to see the values of the class hits.
   
   
4. Repeat step 3 on a periodic basis to monitor class hits.
   
   
5. Optionally, click the Class Hits column heading to sort by class hits. The classes with the greatest hits will sort to the top of the list.

Spot a huge increase on an ignored traffic class.

An attack can use a traffic type that has been assigned an ignore policy (remember, this policy does not toss traffic but simply ignores it and lets it pass).

1. Select the monitor tab and scan your traffic tree for any classes that are assigned an ignore policy.
   
   
2. Check the Class Hits column for classes with ignore policies. Keep tabs frequently enough so that you can spot abnormalities.
   
   If you spot any suspiciously high class hits, continue to the next steps.
   
   
3. Change the policy so that PacketWise will track statistics for its traffic. (PacketWise does not keep statistics on classes with ignore policies.) A priority policy with priority 3 might be appropriate.
   
   
4. Set Top Talkers and Top Listeners for the class.
   
   
5. Turn traffic discovery on within the class.
   
   
6. After waiting a few minutes for enough traffic to pass, examine any available information:

• Look at Top Talkers to see who contributes to the traffic.
  
  
• Look at the utilization graphs. Is it really a flood?
  
  
• Look at the traffic tree. After you turned on traffic discovery for the class, did PacketWise add any child classes to refine what makes up the traffic? Who are the recipients? Is it legitimate traffic?

Monitor TCP connections.

Two PacketWise measurement variables (tcp-conn-inits and tcp-conn-server-ignores) track the number of new TCP connections and the number of TCP connections for which the server never responded. By studying the values of these variables for Inbound and Outbound traffic, you can establish baselines for TCP connections in a normal, non-attack setting. Then, using the adaptive response feature, you can be notified automatically when these values are outside the "normal" range. Note that the normal range will be different for every network.

The TCP Health graph is useful in this type of analysis.

1. Create a graph for TCP Health for the Inbound link. Try a variety of time periods and end dates so that you can get a good idea of normal ranges for Connections and Server Ignores on your network.
   
   
2. Repeat step 1 to create a TCP Health graph for the Outbound link.
   
   
3. Use the adaptive response feature to notify yourself or an appropriate person when the number of connections or server ignores exceed the normal range. You could even respond automatically with protective action if you want. See Create an Agent that Monitors a Link Variable.

Limit Flood Attacks (Back to top)

Flood attacks establish a large number of illegitimate connections, consuming bandwidth or overwhelming hosts. Attacks can originate from single or multiple hosts and be destined for single or multiple hosts.

Restrict the Bandwidth Used by Violating Hosts

As described previously, you can create adaptive response agents to detect hosts that might be involved in a SYN or other DoS attack. When an agent detects a possible attack, it will generate an incident report with the list of IP addresses that are in violation of the agent's thresholds. In addition, the agent will automatically place the IP addresses of these violating hosts in a host list. This host list can be used as a matching rule in a traffic class; in other words, you can create Inbound and Outbound classes that will classify traffic for the violating hosts. Once you have classes defined, you can apply policies and partitions to them to restrict the bandwidth.

If you would like to automatically restrict the bandwidth of the violating hosts until you have a chance to research the hosts, perform the following steps ahead of time:

1. Create Inbound and Outbound traffic classes that are based on the violating host list.
2. Apply restrictive policies and/or partitions to these classes.

Once you have set this up, a violating host will automatically have its bandwidth restricted according to the policy and partition you have defined.

Limit the Rate of New Traffic Flows to or from One Host

PacketWise can detect and limit the impact of SYN flood or similar denial-of-service attacks that are directed at a particular host or if the attack is from a specific IP address. In order to improve PacketWise’s ability to automatically contain denial-of-service attacks, PacketWise can enforce a limit on the number of flows per minute that can be initiated by any client or received by any server. The limits are set to default values of 10,000 flows per minute on client hosts and 100,000 flows per minute on servers. Flow limits are automatically set on any classes that have a policy set on them, and PacketWise will block any flows that exceed these limits.

1. Access the CLI.
   
   
2. Use the hostdb info CLI command to determine the normal numbers of flows per minute on the client and server sides of a host.
   
   
3. If you want to set or adjust the default limits on a particular class, use the CLI command policy flowlimit to restrict the rate at which any given client or any given server can initiate new flows.
   
   For example, enter policy flowlimit /Inbound/Default 100000 200000 to restrict the number of new flows from any given client to one hundred thousand per minute and from any given server to two hundred thousand per minute. Depending on network size and conditions, you may find lower values are more appropriate for your network
   
   Any traffic that is classified in Inbound/Default or is in any traffic class that inherits Inbound/Default's policies is held to these limits. (Background information on inheritance.)
   
   
4. If you have any traffic classes that do not inherit the policy you just defined, consider whether you want these classes' clients/servers to be included in the evaluation of your host limits. If so, repeat the policy flowlimit command for each class.
   
   
5. Remember to apply flow limits to your Outbound traffic as well as your Inbound traffic.
   
   If one of your hosts has been infected with a virus that initiates copious amounts of traffic to deluge an intended target, you have been turned into a DoS launchpad. You can avoid the legal and service implications of contributing to someone else's attack by using the policy flowlimit command on Outbound traffic.
   
   
6. Set up automatic notification so that you can be notified if PacketWise detects more per-host flows than the limits you set. Use the two PacketWise metrics client-flood-block and server-flood-block.

Limit the Amount of ICMP Traffic

Many DoS attacks use the ICMP protocol. Normally, ICMP traffic uses only a tiny portion of bandwidth. There are exceptions, especially if you require large numbers of pings, typical in hosting environments for mail, games, and so on.

1. ICMP traffic is automatically classified by PacketWise and has its own class. Check the Monitor window for ICMP's peak usage or display ICMP's Utilization graph for an interval over the last month.
   
   Take the class' highest peak number, double it, and jot it down.
   
   If you have no historical data to examine (for example, if you're just setting up), you could just take 5 or 10 percent of your link (for example, 75 Kbps). However, this alternative is not advisable if you have an unusually high amount of ICMP on your network in normal conditions. It's best to let PacketWise gather a week or two of ICMP statistics and use the previous method.
   
   
2. Create a non-burstable partition for Inbound/ICMP and Outbound/ICMP traffic classes using the rate you jotted down as the size.

Limit the Number of Concurrent Traffic Flows for One Traffic Class

1. Examine the metric "licenses-peak" over the last month to spot trends for the highest number of simultaneous sessions for a traffic class. Double the highest number and jot it down.
   
   
2. Limit the number of allowable concurrent traffic flows for one traffic class using the CLI command class licenses. Use the number you jotted down in the previous step. Note that although rate policies and partitions limit the amount of bandwidth, this command limits the number of simultaneous flows. For example, you could enter class licenses Inbound/Oracle 5000 on the command line to contain Oracle to 5000 simultaneous sessions.
   
   
3. Use the CLI command traffic licenses to monitor the concurrent flows for the class.
   

Detect Psuedo-Address Attacks (Back to top)

Spoofing and LAND attacks send packets that appear to be from a trusted source by maliciously setting the source and/or destination to false addresses. The traffic can then gain access to hosts or services that should be secure. The adaptive response feature offers two preconfigured agents to help detect hosts that are spoofing: Spoofing - Client and Spoofing - Server. For details on using these agents, see Use Agents to Detect Spoofing.

Detect Portscan Attacks (Back to top)

Some attacks generate traffic to a multitude of different ports. Because the active port continuously changes, traditional port-blocking techniques fail to stop the attack.

1. The policy flowlimit command is useful in these situations. See the explanation above.
   
   
2. Every time a TCP connection is made to a server via a port with no associated process, PacketWise increased its tcp-conn-server-ignore metric. Keep tabs on that metric to catch portscan attacks. You can look at the metric itself or you can notify yourself or an appropriate person when the metric climbs.

The New Application agent can also be helpful in detecting portscan attacks.

Disrupt Virus Attacks (Back to top)

Specific Packeteer suggestions for spotting and tossing the traffic from current viruses, worms, and so on can be found in Packeteer's Technical Information Library. Try searching the TIL using the keyword "virus."

If a virus contains an identifiable string in a field you can specify in a matching rule, then you can use a traffic class definition to spot and toss the traffic. A virus using HTTP with a characteristic sequence of characters in its URL is the easiest traffic to block and a very common vehicle for viruses.

1. Create a traffic class under Inbound/ HTTP to collect all instances of the virus. Use this URL criteria:
   Name: AnyName
   Protocol family: IP
   Service Type: HTTP
   Service Location: Any
   Class Criterion: URL : use known URL with asterisks for wildcards
   
   For example, the Code Red virus from months ago used a URL with one of two characteristic strings. Customers used the following line in their class definition to catch the first:
   Class Criterion: URL: */default.ida?NNNNNNNNNNNNNNN*
   
   The Nimda virus from the same vintage used:
   Class Criterion: URL : */root.exe*
   
   

2. Add a matching rule using any additional known URL criteria: (optional)
   Protocol Family: IP
   Service Type: HTTP
   Server location: Any
   Class Criterion: URL: use known URL with asterisks for wildcards
   
   For example, the Code Red virus mentioned in the previous step used the following final line in its additional matching rule:
   Class Criterion: URL:*/default.ida?XXXXXXXXXXXXXXX*
   
   And the Nimda virus used:
   Class Criterion: URL:*readme.eml*

3. Simulate an attack. From any web browser, enter www.yahoo.com/url pattern you used. You will get a message telling you that the document was not found. Refresh the page. This will show up as a hit on your class (check the monitor tab).
   
   For example, the nimda virus could be tested using:
   www.yahoo.com/system32/cmd.exe.
   

4. When you are certain the class is collecting only the proper traffic, apply a never-admit policy to the class.

5. Copy the class to the Outbound branch to prevent any existing virus from spreading.

Note: Although PacketWise can help prevent this kind of traffic and has some firewall characteristics, it is not a firewall. High traffic demands on PacketWise can result in improper classification; this is not a risk worth taking. We recommend that you have a firewall in place dedicated to protection. Attacks have been known to get past firewalls under the best circumstances — use PacketWise as additional protection.