Detect and Limit DoS Attacks

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

Recent denial-of-service attacks against popular web sites have made headlines and raised consciousness about vulnerability. These insidious attacks employ a variety 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

• 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 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 user event 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 user event feature to notify yourself or an appropriate person when the number of connections or server ignores exceed the normal range.

Look for Unwelcome Hosts

One way to detect potential attacks is to look for abnormal hosts on your network. PacketWise offers two techniques for spotting these hosts: with the Top Talkers feature and with the host accounting feature. Both techniques are outlined below.

To use the Top Talkers feature to help you spot an unusual host:

1. Set Top Talkers for /Inbound, /Outbound, /Inbound/Default, and /Outbound/Default.
   
   
2. Periodically display the Top Talkers list to see who contributes to the traffic in these classes. Are there any IP addresses you don't expect to be generating the most traffic on your network? These hosts could possibly be causing trouble on your network. (See Monitor TCP Connections for further information on determining when an attack is occurring.

The host accounting feature offers a method to record total bytes sent and received per IP address. To use the host accounting feature:

1. Access the CLI.
   
   
2. Enable host accounting.
   
   
3. Retrieve host accounting data for subnets or host lists to establish a pattern of who the "normal" heavy users are.
   
   
4. If a new heavy user appears on the list, you can investigate further to see if an attack has occurred or is occurring.

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.

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 rate or priority policy assigned to them, and PacketWise will automatically block any flows that exceed these limits.

Note: You cannot set a flow limit on a class unless it already has a rate or priority policy assigned to it.

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 PacketShaper 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.

These steps are advised only if your internal network's IP addresses can be identified easily by subnet.

1. Create a traffic class for Inbound traffic that contains a source address from inside your own network.
   
   
2. Block all traffic in your new traffic class.
   
   
3. Monitor the class hits on your traffic class to see if anyone has tried to send traffic with an incorrectly trusted source. Alternatively, notify yourself or an appropriate person when the class hits spike.

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.

Disrupt Virus Attacks (Back to top)

You can create a class with URL matching criteria to track a virus.

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
   
   

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

3. Simulate an attack. From any web browser, enter www.yahoo.com/url 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).
   

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 virus protection. Attacks have been known to get past firewalls under the best circumstances — use PacketWise as additional protection.