NSP Denial of Services 6.1

Denial-of-Service

McAfee Network Security Platform

COPYRIGHT

Copyright 2011 McAfee, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without the written permission of McAfee, Inc., or its suppliers or affiliate companies.

TRADEMARK ATTRIBUTIONS

AVERT, EPO, EPOLICY ORCHESTRATOR, FOUNDSTONE, GROUPSHIELD, INTRUSHIELD, LINUXSHIELD, MAX (MCAFEE SECURITYALLIANCE EXCHANGE), MCAFEE, NETSHIELD, PORTALSHIELD, PREVENTSYS, SECURITYALLIANCE, SITEADVISOR, TOTAL PROTECTION, VIRUSSCAN, WEBSHIELD are registered trademarks or trademarks of McAfee, Inc. and/or its affiliates in the US and/or other countries. McAfee Red in connection with security is distinctive of McAfee brand products. All other registered and unregistered trademarks herein are the sole property of their respective owners.

LICENSE INFORMATION License AgreementNOTICE TO ALL USERS: CAREFULLY READ THE APPROPRIATE LEGAL AGREEMENT CORRESPONDING TO THE LICENSE YOU PURCHASED, WHICH SETS FORTH THE GENERAL TERMS AND CONDITIONS FOR THE USE OF THE LICENSED SOFTWARE. IF YOU DO NOT KNOW WHICH TYPE OF LICENSE YOU HAVE ACQUIRED, PLEASE CONSULT THE SALES AND OTHER RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTS THAT ACCOMPANY YOUR SOFTWARE PACKAGING OR THAT YOU HAVE RECEIVED SEPARATELY AS PART OF THE PURCHASE (AS A BOOKLET, A FILE ON THE PRODUCT CD, OR A FILE AVAILABLE ON THE WEBSITE FROM WHICH YOU DOWNLOADED THE SOFTWARE PACKAGE). IF YOU DO NOT AGREE TO ALL OF THE TERMS SET FORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF APPLICABLE, YOU MAY RETURN THE PRODUCT TO MCAFEE OR THE PLACE OF PURCHASE FOR A FULL REFUND.

2

McAfee Network Security Platform Denial-of-Service

Contents

1

PrefaceAbout this Guide . . . . . . Audience . . . . . . Conventions . . . . . Finding product documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55 5 5 6

1 2

Overview Types of DoS attacks handled by Network Security Platform

7 9

Volume-based DoS attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Vulnerability-based DoS attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 DDoS attack tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3

Methods used by Network Security Platform to counter DoS attacksNetwork Security Platform DoS detection signatures . . . . . . . . . . . Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol parsing specifications . . . . . . . . . . . . . . . . Packet Searches . . . . . . . . . . . . . . . . . . . . . . Where signatures fit . . . . . . . . . . . . . . . . . . . . . Threshold-based mode . . . . . . . . . . . . . . . . . . . . . . . Learning-based mode . . . . . . . . . . . . . . . . . . . . . . . Countering profile contamination . . . . . . . . . . . . . . . Source IP classification . . . . . . . . . . . . . . . . . . . Attacks handling by Network Security Platform . . . . . . . . . . . . . Handling volume-based DoS attacks . . . . . . . . . . . . . . Handling vulnerability based DoS attacks . . . . . . . . . . . . Handling attacks that use DDoS attack tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1314 14 14 15 15 15 16 16 16 17 17 18 18

. .

. . . . . . .

4

AlertsCategorical (or imbalance) anomalies Volume anomalies . . . . . . . . Percentiles . . . . . . . . Attack blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19. 19 . . 20 . . 20 . 21

5

Understanding policy editing options

23

Inbound and outbound traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Response sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Setting response sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6

Administration Walk-throughIPS Settings-level options . . . . . . . . . . . . . . . . . . . Setting thresholds . . . . . . . . . . . . . . . . . . . Customizing DoS learning mode . . . . . . . . . . . . . . Sensor-level options . . . . . . . . . . . . . . . . . . . . . . DoS data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27. 27 . 27 . 29 31 . 32


3

Contents

DoS profiles . . . . . . . . . . . . . . . . . . . . . . . . DoS filters . . . . . . . . . . . . . . . . . . . . . . . . . DoS related TCP settings . . . . . . . . . . . . . . . . . . . Rate-Limiting Configurations . . . . . . . . . . . . . . . . . Interface-level options . . . . . . . . . . . . . . . . . . . . . . . Customizing DoS policy at the interface level . . . . . . . . . . . View DoS profiles at the interface level . . . . . . . . . . . . . Viewing DoS alerts in Threat Analyzer . . . . . . . . . . . . . . . . Alert Details . . . . . . . . . . . . . . . . . . . . . . . . Blocking attacks in the Threat Analyzer . . . . . . . . . . . . . Editing attack settings for a DoS alert in Threat Analyzer . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. 33 36 . 37 . 39 44 44 . 47 . 47 . 50 . 51 . 52

7

DoS related actions using CLI commandsset dospreventionseverity . . . . . . . . . . . . . . . . Blocking DoS traffic from a specific host . . . . . . . . . . . DNS spoof protection . . . . . . . . . . . . . . . . . . set dnsprotect . . . . . . . . . . . . . . . . . . dnsprotect . . . . . . . . . . . . . . . . . . . show dospreventionprofile . . . . . . . . . . . . . . . . DOS prevention severity for tcp-syn-ack outbound is 30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55. 55 56 . 56 . 56 . 57 . 57 . 58

8 9

Configuring ACLs DoS related actions using CLI Commands Index

61 63 65

4


Preface

Contents About this Guide Finding product documentation

About this GuideThis special topics guide provides information on how McAfee Network Security Platform detects denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks and the different mechanisms used for countering and preventing such attacks. You get information on the types of DoS and DDoS attacks handled by the Network Security Platform, and on how Network Security Platform protects the network against these attacks. This guide also gives Information on configuring Network Security Sensor (Sensor) for handling DoS and DDoS attacks through the Network Security Manager (Manager). The information in this guide relates only to the IPS Sensor.

AudienceMcAfee documentation is carefully researched and written for the target audience. The information in this guide is intended primarily for: Administrators People who implement and enforce the company's security program.

ConventionsThis guide uses the following typographical conventions and icons. Book title or Emphasis Title of a book, chapter, or topic; introduction of a new term; emphasis. Bold User input or PathCode

Text that is strongly emphasized. Commands and other text that the user types; the path of a folder or program. A code sample. Words in the user interface including options, menus, buttons, and dialog boxes. A live link to a topic or to a website. Note: Additional information, like an alternate method of accessing an option. Tip: Suggestions and recommendations.

User interface Hypertext blue


5

Preface Finding product documentation

Important/Caution: Valuable advice to protect your computer system, software installation, network, business, or data. Warning: Critical advice to prevent bodily harm when using a hardware product.

Finding product documentationMcAfee provides the information you need during each phase of product implementation, from installation to daily use and troubleshooting. After a product is released, information about the product is entered into the McAfee online KnowledgeBase. Task 1 2 Go to the McAfee Technical Support ServicePortal at http://mysupport.mcafee.com. Under Self Service, access the type of information you need: To access... User documentation Do this... 1 Click Product Documentation. 2 Select a product, then select a version. 3 Select a product document. KnowledgeBase Click Search the KnowledgeBase for answers to your product questions. Click Browse the KnowledgeBase for articles listed by product and version.

6


1

Overview

A denial-of-service (DoS) attack is a malicious attempt to render a service, system, or network unusable by its legitimate users. To achieve this goal, attackers usually try one of the following: Crash or disable the target service or system. Disrupt or prevent normal users from accessing the target. Saturate essential, limited resources of the target by flooding.

In a distributed denial-of-service (DDoS) attack, attackers take advantage of many hosts across the Internet, which they had previously compromised, to launch a brute-force attack that starves the target of its essential resources. This guide uses the terms DoS to refer to both Denial of Service and Distributed Denial of Service.Compromised hosts are sometimes called Zombies.

See also About this Guide on page 5


7

1

Overview

8


2

Types of DoS attacks handled by Network Security Platform

In Network Security Platform DoS attacks are classified into three main categories based on their design. This chapter describes in detail the main categories. Contents Volume-based DoS attacks Vulnerability-based DoS attacks DDoS attack tools

Volume-based DoS attacksVolume-based DoS attacks are statistical anomalies in the traffic monitored by a Network Security Platform Network Security Sensor (Sensor). In other words, with insight into the normal distribution and volume of traffic, the Sensor looks for significant changes in these levels, which can indicate malicious behavior. Based on the protocol used, volume-based DoS attacks can be classified as described below: IP IP fragment: In this case, an attacker may be attempting to crash a system on your network by sending a large volume of fragmented IP packets in a short period.

TCP TCP SYN and FIN: This attack is caused by sending a large number of TCP SYN (SYN flooding) or FIN packets to the target host, but not responding to the packets returned by the target host. This fills up the data structures used by the target host to keep track of pending connections. Pending connections will time out eventually and free up space in the data structures. However, the attacker can cause a perpetual DoS condition by sending more SYN or FIN packets. TCP RST: This is based on a large number of TCP RST segments. An initial TCP RST packet can shut down a legitimate connection between a host and a server. An attacker can sniff and mimic the RST sequence number from a network, then send a malicious TCP RST. After a TCP connection has been torn down, receiving further TCP RST packets can cause a DoS condition, because system resources are being used to receive, check, and discard the packets.


9

2

Types of DoS attacks handled by Network Security Platform Vulnerability-based DoS attacks

Out-of-window TCP data segment: An out-of-window data segment is a segment whose sequence number falls out of the acceptable range, or "TCP receiving window" of the destination host. For example, imagine that the last byte the destination host successfully received and processed had a sequence number of 10000 and that it has a receiving window of 1024 bytes. Subsequent packets within the range of 10001 and 11024 are considered within its window. All other packets are considered out-of-window. Under normal conditions, the amount of out-of-window packets should be small. High-volume occurrences of such packets are therefore suspicious and can lead to a DoS condition. This attack may consume significant bandwidth of the target network, and result in service disruption or service quality degradation. In some cases, the targeted server system may exhaust memory, crash, or be rendered otherwise inoperative. Out-of-context TCP data segment: Each TCP packet is identified by a 4-tuple combination of source IP and port, and destination IP and port. An out-of-context data segment is one that does not match the 4-tuples of any established flow. High-volume occurrences of Out-of-context packets can cause a DoS condition and affect the network in the same manner as high-volume occurrences of out-of-window packets.

HTTP flood attacks: HTTP flood attacks are caused when an attacker launches a large number of legal GET request to a target server and exhausts the processing power of the server. UDP UDP flood: When communication is established between two UDP services, an UDP flood attack is initiated by sending a large number of UDP packets to random ports of the targeted system. The targeted system is forced into sending many "Destination Unreachable" ICMP packets, thus consuming its resources and leading to DoS. As UDP does not require any connection setup procedure to transfer data, anyone with network connectivity can launch an attack; no account access is needed. Another example of UDP flood is connecting a host's "chargen" service to the "echo" service on the same or another machine. All affected machines may be effectively taken out of service because of the excessively high number of packets produced. In addition, if two or more hosts are so engaged, the intervening network may also become congested and deny service to all hosts whose traffic traverse that network. DNS spoofing: This is a type of UDP attack, which exhausts the processing power of a DNS server.

ICMP ICMP Echo: This attack involves flooding the network with ICMP Echo Request or Reply packets. A flood of Echo requests to a target system makes the system busy responding to the requests. If there is a flood of Reply packets, then it is very likely that the remote attacker has forged an IP address from within your network and is sending ICMP Echo Request packets to another network. That network replies to the address in the requests, thus starting a request/reply flood between the two networks. All other ICMP (other than Echo Request and Reply): This involves a large number of ICMP packets other than Echo Request and Reply packets.

Non-TCP/UDP/ICMP: This involves flooding the network with packets other than TCP, UDP, or ICMP. Packets involved in this attack may include IPSec and malformed IP packets (such as IP with bad checksums and inconsistent length).

Vulnerability-based DoS attacksUnlike volume-based DoS attacks, vulnerability-based DoS attacks are generally single requests that can result in a DoS condition. Vulnerability based DoS attacks exploit vulnerabilities in the network and its systems. Such attacks keep evolving and Network Security Platform updates protect network against new type of attacks. Some well-known examples of vulnerability based DoS are as follows:

10


Types of DoS attacks handled by Network Security Platform DDoS attack tools

2

Attack Name TearDrop attack

Description This attack involves fragmented ICMP packets with overlaps among the fragments. Such fragments cause certain implementations of the IP stack to crash or go into an infinite loop, thus leading to a DoS condition. This attack involves sending packets that exceed the maximum authorized size (65,536 bytes) to a system with a vulnerable TCP/IP stack, causing it to crash. This attack involves using IP address spoofing with the same IP address and port number in the source and destination fields, causing vulnerable systems to become unstable.

Ping of Death attack Land attack

DDoS attack toolsDDoS attacks can be launched by using tools that are built to generate DDoS attacks. There are many DDoS attack tools. Some well-known tools are listed below: Trinoo: Trinoo is an attack tool that installs agent programs on compromised hosts and uses the agents through a master program to attack one Trinoo:or more target hosts by flooding them with UDP packets. Communication between the master and agents is password protected. Tribal Flood Network (TFN): TFN uses an attack approach similar to Trinoo and can generate multiple attacks and use spoofed IP addresses. ICMP echo request flood, TCP SYN flood and UDP flood are some of the attacks that can be launched by TFN. TFN2K: TFN2K is an advanced version of TFN with features that makes it more difficult to detect. TFN2K uses multiple protocols including UDP, TCP, and ICMP. Stacheldraht: Stacheldraht, which means "barbed wire" in German, has features that include those of Trinoo and TFN. Stacheldraht has features like encrypted communication between agents and the master program. Shaft: Shaft is a tool similar to Trinoo that can launch packet-flooding attacks. Trinity: Trinity is a flood attack tool that uses chat programs such as Internet Relay Chat (IRC). MStream: MStream is a tool based on "stream.c" attack in which access to the handler is password protected.


11

2

Types of DoS attacks handled by Network Security Platform DDoS attack tools

12


3

Methods used by Network Security Platform to counter DoS attacks

When configured according to specific requirements, McAfee Network Security Platform can help you to prevent DoS attacks on your network. Network Security Platform Network Security Sensors (Sensors) managed by Network Security Manager (Manager) can be custom configured for a specific network to prevent DoS attacks. You can deploy Sensors on either on your Internet Service Provider's (ISP's) network or your network or both. Network Security Platform combines three methods to identify and combat DoS and DDoS attacks. Those methods are: Network Security Platform DoS detection signatures Thresholds Learning

Network Security Platform signatures can identify attacks carried out using the DDoS attack tools and vulnerability based DoS attacks. The threshold and learning methods look for statistical anomalies in the traffic Network Security Platform scans, to detect volume-based DoS. With insight into the normal distribution and volume of traffic when the network is not under attack, these methods look for significant changes to those levels that indicate malicious behavior. In addition to the methods used by the Network Security Platform to detect DOS and DDoS attacks, the following options are also available in the Manager for the network administrator to take DoS attack preventive measures. TCP Settings TCP Settings in the Manager permit the configuration of settings such as, TCP Segment Timer, TCP 2MSL Timer, TCP Flow Violation, Unsolicited UDP Packets Timeout, SYN Cookie, Inbound Threshold Value, Outbound Threshold Value and Reset unfinished 3-way handshake connection. An Administrator can configure these parameter values based on the knowledge of a specific network to prevent DoS attacks.

Rate-Limit Traffic Rate-limiting is used to control the rate of egress traffic sent through the ports of a Sensor. An Administrator can set appropriate values in the Manager to prevent DoS by setting Sensor port specific bandwidth limits that are relevant for preventing DoS in a particular network.

See also DoS related TCP settings on page 37 Rate-Limiting Configurations on page 39


13

3

Methods used by Network Security Platform to counter DoS attacks Network Security Platform DoS detection signatures

Contents Network Security Platform DoS detection signatures Threshold-based mode Learning-based mode Attacks handling by Network Security Platform

Network Security Platform DoS detection signaturesNetwork Security Platform uses attack signatures to detect communication between many known DDoS attack tools. The attack signatures identify the specific communication between utilities used to create DDoS attacks, such as, Trinoo, Stacheldraht, and Trinity. For example, the signatures can identify the communication from a Trinity master as it instructs its Zombies to initiate a distributed attack. Network Security Platform also uses exploit signatures for DoS attacks that are not caused by traditional means such as volume overload. For example, the HTTP: Microsoft IIS...SLASH... DenialofServiceexploit identifies a single request that prevents older IIS servers from responding to clients until they are restarted. The Sensor uses signatures to perform different levels of traffic processing and analysis. Network Security Platform signatures operate on a framework of Flows, Protocol parsing and Packet searches to detect vulnerability based DoS attacks and attacks using DDoS attack tools.

FlowsAt the highest level, the Network Security Platform addresses UDP and TCP traffic based on the concept of a flow. Flows are defined by their protocol (either UDP or TCP), source and destination ports, and IP addresses of their endpoints. UDP does not contain the concept of "state" that TCP does, so the Sensor implements a timer-based flow context for UDP traffic. After dividing traffic into flows, the Sensor makes use of port mapping, or in the case of traffic running on non-standard ports, intelligent protocol identification, to pass each flow to the appropriate protocol parsing mechanism. It is also worth noting that Network Security Platform provides you with the ability to specify whether your signature will look at the complete flow, one direction of the flow, or restrict itself to data occurring within single packets of the flow. Precise control of this detection window is necessary for accurate detection of attacks.

Protocol parsing specificationsProtocol specifications (Network Security Platform's protocol parsing mechanisms) parse through network flows to validate traffic and divide it into protocol fields, which may then be actively tested against Network Security Platform-supplied attacks or User Defined Signatures. By dividing protocol traffic into the appropriate fields, Network Security Platform can perform matches against the most specific field or subfield pertinent to an effective attack, thus supporting signatures with very low false-positive rates. Since the parsing process is fully stateful, it allows detection of anomalies in the protocol's behavior. Additionally, this parsing makes it possible to provide an additional benefit to signature writers in the form of qualifiers. Qualifiers are tests that are embodied in the name of a particular protocol field. For example, rather than specifying that an HTTP request method must be "GET", the Network Security Platform system allows the use of "http-get-req-uri" as the name of the field, saving the requirement of providing that test in the signature, and the Sensor from having to perform an extra pattern match.

14


Methods used by Network Security Platform to counter DoS attacks Threshold-based mode

3

Packet SearchesTraffic flows that are not identified as belonging to any particular protocol are passed to the Packet Search Protocol Specification Engine for further parsing. The Network Security Platform presents each direction of the flow to Network Security Platform-defined attacks and to any User Defined Signatures. Tests against packet search traffic typically take the form of specific ordered pattern matches to prevent false positives and performance problems.

Where signatures fitSignatures tie together elements of flows, protocol parsing and packet search framework to derive specific "fingerprints" for network traffic from smaller building blocks. In essence, signatures are like DNA tests. They can identify both specific people and relatives of that person. In the intrusion-detection case, the relatives may be a collection of buffer overflow attacks against a certain piece of software, and the particular person would be a specific piece of exploit code. While the two are not greatly different, Network Security Platform adopts a convention of differentiating between anomaly-based attack signatures (not to be confused with anomaly-based detection for Denial of Service attacks) and signatures pertaining to a specific attack. The main difference is that while anomaly-based signatures examine the network for unexpected or non-conforming behavior, signatures pertaining to specific attacks will often look for a very particular indicator, such as a flag with a particular value, or a specific string's presence. Signature-based anomaly attacks know what to expect in normal traffic, and trigger when they get something else. Normal attack signatures look for specific misbehavior. When defining attacks to detect and protect from vulnerabilities, a blended set of signatures are often defined which check for behavioral anomalies as well as specific exploit strings. Using this mechanism, all possible attempts to exploit the vulnerability can be detected.

Threshold-based modeIn Threshold Mode, the Sensor monitors the network traffic for packet floods, such as too many IP fragments, transmitting through from a source to a destination as detected within a Sensor interface or sub-interface. When configuring the DoS policy or customizing at the interface or sub-interface level, you must specify the count and interval (rate in seconds) for the threshold attacks you want to detect. The Sensor sends an alert (if configured to do so in the DoS policy) when the traffic exceeds the customized thresholds for an enabled attack. You can also enable a notification for an attack if it warrants special attention. This method requires that you to fully understand your typical traffic pattern in order to pick "good" threshold values; otherwise it can produce false alarms due to traffic fluctuations, such as "flash crowds" for example, everyone logging on the network at 9 a.m. or other legitimate increased traffic. For threshold-based attacks, a Sensor monitors both inbound and outbound traffic.Although default values are provided for thresholds and intervals, you must configure the actual thresholds and intervals for each DoS Threshold Mode attack you want to detect. Customization of DoS thresholds works best after researching the current levels to be defended for each DoS threshold. This helps you to determine exactly what counts and intervals are best for protecting your network.


15

3

Methods used by Network Security Platform to counter DoS attacks Learning-based mode

Learning-based modeA new Sensor runs for its first 48 hours in learning mode. After 48 hours are complete, the Sensor automatically changes to detection mode, having established a baseline of the "normal" traffic pattern for the network, or a long-term profile. The assumption is that no DoS attack takes place during those first 48 hours. After moving to detection mode, the Sensor continues to gather statistical data and update its long-term profile. In this way, the long-term profile evolves with the network. The Sensor also builds short time profiles with a time window of few minutes. Learning mode profiles can be customized at the Sensor_Name node level. Learning Mode profiles can be reset (re-learned) or reloaded at this level. This is all performed in the Configuration page of the Manager. Sub-interfaces and individual CIDR hosts within a VLAN tag or CIDR block can be created and protected against DoS attacks with specific learning mode settings. This is useful in preventing a server in your DMZ or other location from being shut down by a DoS attack. A separate profile is created for each resource. The Sensor uses the following checks and counter checks to ensure accuracy of detection: Counter profile contamination Source IP classificationIf there is a change in the routing scheme, McAfee recommends instructing the Sensor to relearn the network so that it can create a new baseline.

Countering profile contaminationThe goal behind the long-term profile is to define normal traffic levels. The Sensor can identify anomalous spikes in traffic with reference to the defined normal levels. The Sensor also uses the gathered statistical data to calculate short-term profiles (statistical data averaged over a time window of a few minutes). If a short-term profile that includes DoS attack data is used to update the long-term profile, it contaminates the long-term profile. Network Security Platform uses the following countermeasures to help prevent contamination: When in detection mode, the Sensor temporarily ceases updating the long-term profile if too many statistical anomalies are seen over a short period. The Sensor uses percentile measure. A few large spikes in the short-term data will probably upset a simple average, but are less likely to affect a percentile measure. For example, imagine a group of four students taking an exam with percentile measure ranges of 0-29, 30-49, 50-69 and 70-100 for judging the effectiveness of the exam. Let us say three of the students receive grades of 95%, 93%, and 92% and the fourth receives a grade of 0%. The average score is only 70% but three of the four students are still in the 70-100 range. The teacher can therefore use the percentile ranges as a valid measure for judging the effectiveness of the exam.

Source IP classificationThe Sensor builds 20 unique source IP profiles; one profile for each tracked packet type in each direction.

16


Methods used by Network Security Platform to counter DoS attacks Attacks handling by Network Security Platform

3

Within each source IP profile, the entire IP address space is divided into a maximum of 128 mutually exclusive IP address blocks, or bins, much in the same way CIDR addressing divides the address space. Each bin is uniquely identified by a prefix and prefix length (from 2 to 32 bits). An IP address falls into a bin when the first 'n' number of bits of the address matches the bin's prefix. The sensor then associates each source IP with a particular bin in the appropriate profile. Each bin has the following two properties: The percentage of long-term (good) traffic originating from the source IPs that belongs to this bin. The percentage of the overall IP address space that the IP range in this bin occupies.

With the source IPs properly classified, the Sensor can now protect a network from DoS attacks. When a statistical anomaly occurs, the Sensor takes the following actions on the source IP profile in question: The Sensor blocks all packets with source IPs in the bins that occupy a large percentage of the IP space, but represent a small percentage of the long-term traffic. This combats attacks that are generated with random, wide-ranging, spoofed source IP addresses. The Sensor blocks all packets with source IPs in the bins that occupy a large percentage of the short-term traffic together with a significantly higher percentage of short-term traffic than historically seen. This combats attacks that are initiated from a handful of networks with authentic source IP addresses. The Sensor does not block packets with source IPs in the bins that occupy a small percentage of the IP space and represent a high percentage of the long-term traffic. This protects against blocking hosts that are known to be good.

The exception to the third criterion is when the traffic also meets the second criterion. In other words, source IPs from the "good" bins are blocked if their short-term traffic level is significantly higher than their peak long-term level. This combats attacks that are initiated from good hosts that have recently been compromised. Source IP classification is more effective than using devices such as firewalls that limits the rate of SYN packets on the network to block DoS attacks. The key difference in such an approach and Network Security Platform is that a rate-limiting device blocks traffic randomly. "Good" traffic has the same probability of being blocked as attack traffic. On the other hand, source IP classification used by Network Security Platform attempts to differentiate good traffic from attack traffic, so attack traffic is more likely to be blocked.

Attacks handling by Network Security PlatformAttacks handling by Network Security Platform Network Security Platform handles different types of DoS attacks by applying a combination of methods involving Network Security Platform signatures, thresholds and learning.

Handling volume-based DoS attacksA DoS attack often occurs at the firewall or in the DMZ, particularly DMZ Web and mail servers. Network Security Platform offers two ways to handle volume-based DoS. First is the threshold-based mode. In this mode, the Sensor monitors traffic volumes that exceed the configured threshold. The second method is learning-based mode in this mode, the Sensor learns long-term normal behavior and compares it to short-term observed behavior. Combining threshold and learning methods greatly improves reliability of detection.


17

3

Methods used by Network Security Platform to counter DoS attacks Attacks handling by Network Security Platform

See also Threshold-based mode on page 15 Learning-based mode on page 16

Handling vulnerability based DoS attacksTo prevent vulnerability based DoS attacks, a Sensor attempts to capture the manifestation of attacks in signatures, and if configured to do so, apply specific countermeasures based on each signature. This is very effective for known attacks with well-known signatures. For example, Network Security Platforms detection mechanisms enable a signature to identify every HTTP traffic flow, every HTTP traffic flow using the GET mechanism, every HTTP traffic flow using GET with /cgi-bin/calendar.pl as the path and even every GET with that path and a parameter named month with a value of February. Network Security Platform supports the aggregation of multiple signatures into every attack. Each signature within an attack can be more or less specific to identify everything from generic network activity that affects a given platform in a particular way to a specific piece of code that has very specific and identifiable effects. Based on their specificity and severity, signatures are assigned different confidence and severity values. When a network event occurs that matches an existing Network Security Platform attack, several signatures (generic and specific) within that attack may be triggered. When alert throttling is enabled, the Network Security Platform Sensor correlates multiple triggering events automatically to raise a single alert with the highest confidence level. See also Vulnerability-based DoS attacks on page 10 Network Security Platform DoS detection signatures on page 14

Handling attacks that use DDoS attack toolsNetwork Security Platform uses attack signatures to identify attacks generated by DDoS attack tools. Network Security Platform signatures can identify attacks from specific DDoS Attack Tools. An alert is generated in the Threat Analyzer when an attack from DDoS attack tools is detected. See also DDoS attack tools on page 11 Network Security Platform DoS detection signatures on page 14

18


4

Alerts

Alerts are raised in the Threat Analyzer of the Manager. DoS related alerts are raised when Sensor detects volume-based DoS attacks, vulnerability based DoS attacks and attacks by DDoS attack tools. Network Security Platform uses attack signatures to detect communication between many known DDoS attack tools as also to detect vulnerability-based attacks. Alerts are raised in the Threat Analyzer when such attacks are detected. In the case of volume-based attacks, Sensor looks for statistical anomalies in short-term and long-term profiles. The Sensor compares the short-term profile against the long-term profile. If there is a significant difference in the traffic levels, an alert is generated, and the Sensor blocks traffic with statistical anomalies if configured to do so. The alert is generated because the Sensor has detected one of two varieties of statistical anomalies: Categorical (or "imbalance") anomalies Volume anomaliesStatistical anomalies are the result of an attack when the long-term profiles accurately reflect the normal traffic for a given network. However variations in network traffic, due interventions such as changes in the routing scheme can cause anomalies. In such cases you need to rebuild the profile from scratch using the Rebuild the DoS Profiles (start the learning process from scratch) option in the DoS Data Management page ( / IPS Settings / Sensor_Name | Advanced Scanning | DoS Data Management).

See also DoS data management on page 32 Contents Categorical (or imbalance) anomalies Volume anomalies Attack blocking

Categorical (or imbalance) anomaliesCertain types of packets are intrinsically related. Without ICMP Echo Reply, for example, ICMP Echo Request would be of little use. Similarly, without FIN and RST, you would be able to begin a TCP connection, but not end it.


19

4

Alerts Volume anomalies

Network Security Platform detects two types of categorical anomalies: ICMP Echo Anomalies (Echo Request and Echo Reply) TCP Control Segment Anomalies (SYN, SYN ACK, FIN, and RST)

Network Security Platform records the distribution of these types of packets in its long-term profile. A significant change in the distribution of these packet types in the short term is a reliable indication of malicious behavior. For example, Network A might have 50 Echo Replies for every 50 Echo Requests, whereas Network B might have only 40 replies for 60 requests. In this case, the distribution would be 50% / 50% and 40% / 60%, respectively. In practice, distribution differs from network to network, but usually maintains a relatively consistent average over an extended period. A sudden and drastic (short-term) change in the distribution of ICMP Echo packets or TCP control packets is historically indicative of malicious behavior, if not an outright attack.

Volume anomaliesNetwork Security Platform also tracks rapid increases in the volume, or intensity, of traffic. To simplify the analysis of volume anomalies, the self-learning algorithm categorizes all packets into one of the following eight types: IP fragment ICMP echo (request and reply) All other ICMP UDP TCP SYN and FIN TCP RST Non-TCP/UDP/ICMP Out-of-window and out-of-context TCP data segment

See also Volume-based DoS attacks on page 9

PercentilesOne of the methods that the Network Security Platform uses to deal with volume anomalies is to establish thresholds based on packet rate and burst size for different packet types. Changes to these established thresholds indicate threats and are dealt with accordingly. To measure volume changes over time, Network Security Platform establishes two percentiles for each of the packet types. For a given packet type, the Sensor looks at the distribution of the following: Short-term packet rate Traffic burst size

The Sensor analyzes these distributions to establish thresholds that the short-term averages must not typically exceed. For example, Network Security Platform might determine that, for a given packet type, 95% of the short-term profiles averaged a rate of X packets per second or fewer, and a packet size of Y bytes or smaller. When the average rate exceeds X packets per second and the pocket size exceeds Y bytes, Network Security Platform analyzes the significance of change.

20


Alerts Attack blocking

4

If the change is significant and matched a threat perception, an alert is raised.Only one statistical anomaly alert is sent per attack every two minutes.

Attack blockingA Sensor can be configured to block traffic when statistical anomalies occur. Blocking DoS traffic is more involved than blocking normal exploits because the source is often unclear. For example, the "success" of a distributed attack may depend on the quantity of compromised hosts generating traffic together, rather than a single host generating a significant volume on its own. This complicates the blocking process because a Sensor cannot merely block hosts that individually generate large volumes of traffic. Moreover, DoS attack tools typically generate traffic with spoofed IP addresses, so attempting to block them gains nothing and wastes resources. Instead, Network Security Platform classifies source IP addresses as IP profiles to differentiate between good and bad hosts. It then uses these IP profiles to determine a blocking scheme for the Sensor. See also Source IP classification on page 16


21

4

Alerts Attack blocking

22


5

Understanding policy editing options

The Leaning Mode and Threshold Mode settings in the DoS Attacks tab of the Edit IPS Policy page have Inbound, Outbound and Bidirectionalsub-tabs. The Leaning Mode sub-tab also has the Response Sensitivity for all DoS Learning Attacks option. It is important to understand how these options work before actually setting them.Click / IPS Settings >Policies | IPS Policies, select a policy and click View / Edit to view the Edit IPS Policy page.

Contents Inbound and outbound traffic Response sensitivity Setting response sensitivity

Inbound and outbound trafficIn learning-based detection, DoS policy applies to inbound, outbound, and bidirectional traffic. Inbound traffic is that traffic received on the port designated as "Outside" (that is, originating from outside the network) in In-line or Tap mode. Typically, inbound traffic is destined to the protected network, such as an enterprise intranet. Outbound traffic is that traffic sent by a system in your intranet, and is on the port designated as "Inside" (that is, originating from inside the network) in In-line or Tap mode. There are also learning mode attacks that do not have an "Inbound" or "Outbound" directional association, specifically ICMP ECHO Anomaly and TCP Control Anomaly. These attacks are classified as "Bidirectional". When configuring with the Policy Editor, you can customize severities and enable an admin notification for a number of categories. Report generation and the Threat Analyzer can help determine the types of statistical information that are affecting your network's performance.Sensors can only alert in case of ICMP Echo Anomaly and TCP Control Anomaly attacks but cannot block them, even when in In-line mode.

Response sensitivityResponse sensitivity determines how much (volume and duration) a traffic surge is considered abnormal and if an alert should be raised. Setting the response sensitivity to "Low" tells the detection algorithm to be tolerant of traffic spikes before raising alerts. The system becomes more sensitive to traffic surges if the response sensitivity is set to "High." The implications of setting the sensitivity to High are ambiguous: "High" makes it possible to detect even small-scale DoS attacks while at the


23

5

Understanding policy editing options Setting response sensitivity

same time making the system more prone to false positivesthe opposite can be said for Low sensitivity. These settings are therefore meaningful when set with an in-depth knowledge of a specific network. DoS learning mode response sensitivity is configured during policy creation and is enforced at the interface and sub-interface levels when policies are applied at these levels.

Setting response sensitivityThe way in which a Sensor determines that a change is significant enough to warrant an alert varies from profile to profile and packet type to packet type. Network Security Platform maintains a separate history for each combination of profile and packet type. It consults the unique history to determine a precise level of sensitivity for that combination. For example, if the normal volumes of IP fragments vary very little between snapshots for profile A, a small change in volume may trigger an alert. Profile B might see the volumes of TCP resets vary from small to large between short-term snapshots under normal conditions. In this case, the algorithm will be significantly less severe about sending alerts when a change is recorded. The DoS Attacks tab in the Edit an IPS Policy or Add an IPS Policy editors have a Learning Mode sub-tab in each direction (Inbound, Outbound and Bidirectional). The administrator can modify the Response Sensitivity level on each tab to exercise a limited amount of control over how responsive Network Security Platform is to traffic fluctuations.

Figure 5-1 Adding an IPS policy

The Response Sensitivity level controls how much of a short-term deviation from the long-term profile is enough to trigger an alert. Each level translates into statistical thresholds. A high sensitivity translates into lower thresholds, so alerts are generated more easily. A low sensitivity translates into higher thresholds and alerts are therefore less likely to be triggered.

24



5

For example, if left at its default value of Low, Network Security Platform might raise an alert when the short-term traffic volume for a given combination of profile and packet type reaches a 98th percentile. Changing the response sensitivity to High might cause Network Security Platform to alert when the short-term traffic volume reaches the 95th percentile. The way in which the response sensitivity values are quantified depends directly on the history gathered for the profile and packet type in question. There is a Response Sensitivity option on each of the Inbound, Outbound, and Bidirectional tabs. The Inbound and Outbound tabs contain volume attacks for each of the tracked packet types, and the Bidirectional tab contains the two categorical attacks. The administrator has the choice to be more or less severe for a given direction or variety of anomaly. Categorical attacks are bidirectional because they are monitored in both directions. For example, when Network Security Platform monitors ICMP echo packets, it monitors ICMP inbound requests, inbound replies, outbound requests, and outbound replies as a group. In this way, a significant change in the overall distribution of ICMP echo packets causes a statistical anomaly.


25

5


26


6

Administration Walk-through

In this section, we step through the DoS-specific sections of the Manager. Contents IPS Settings-level options Sensor-level options Interface-level options Viewing DoS alerts in Threat Analyzer

IPS Settings-level optionsThe following IPS Settings-level options are available from the IPS Polices sub-tab of the Polices tab of the IPS Settings node in the configuration page of the Manager. Set Thresholds Customize DoS learning mode

Setting thresholdsThe threshold method provides administrators with a way to trigger alerts if a pre-configured traffic volume threshold is exceeded. The key to successfully using thresholds is to have an understanding of the normal traffic levels on the network. In most cases, an external device such as, a Sniffer is used to baseline the network, and the initial levels are set according to that data. Once a baseline has been established, the administrator can enable the relevant threshold for an attack and configure each with values that make sense for a particular network.


27

6

Administration Walk-through IPS Settings-level options

Follow this procedure to set threshold values for an attack: Task 1 Click / IPS Settings | Policies | IPS Policies to view the IPS Policies page.

Figure 6-1 Setting threshold

2 3 4 5

Select a policy and click View / Edit to view the Edit IPS Policy page. Click the Threshold Mode sub-tab of the DoS Attacks tab to view the attacks listed. Select the attack for which you want to set thresholds and click View / Edit to view theEdit Threshold Attack Detailspage. Set the attack threshold: For example, select Customize Threshold Valueand Customize Threshold Interval check boxes, and type 1000 and 1 respectively as values for these selections in the Edit Threshold Attack Details page for Inbound Link Utilization (Bytes/Sec) Too High attack. Such a setting will enable an alert to be sent if a Sensor sees 1000 or more Inbound Link Utilization within a 1-second interval.

Figure 6-2 Threshold value The Threshold method can be configured only to send alerts; traffic meeting or exceeding the pre-defined thresholds cannot be blocked.

The Threshold method is used mostly for troubleshooting. The administrator might want to be notified if bandwidth utilization goes above a pre-defined limit. In contrast to the Threshold method, the learning-based method automatically establishes a baseline and if configured, can alert or block if that baseline is exceeded in such a way that it constitutes an attack. See also Learning-based mode on page 16

28



6

Customizing DoS learning modeFollow this procedure to customize the DoS learning mode for a selected policy: Task 1 2 3 Open the required policy in the IPS Policy Editor. The navigation path to the Policy Editor is / IPS Settings | Policies | IPS Policies. Select a policy listed in the IPS Polices list and click View / Edit to view the Edit IPS Policy page. Click the DoS Attacks tab; the Inbound sub-tab opens with the Learning Mode sub-tab. Network Security Platform provides enforcement of DoS traffic profiling by direction of the flow: Inbound, Outbound, or Bidirectional. You must enable attacks for each direction separately. By default, severity, Sensor response, and blocking of all Learning Mode attacksInbound, Outbound, and Bidirectionalare disabled. You must manually enable these for each learning attack you want to detect through the application of a policy.

Figure 6-3 IPS edit policy

Selecting a value from the Response Sensitivity for all DoS Learning Attacks drop-down list sets the learning curve for the profile to be less (Low), moderately (Medium), or very sensitive (High). For example, if you want the Sensor to be sensitive to slight traffic deviations, select High. See: Response Sensitivity, Setting Response Sensitivity. 4 Select the required attack and click View / Edit to customize it.


29

6


5

View the DoS attack you selected for customization. The fields are as follows: Attack Name: Full name of the attack. Severity: Potential impact of the attack. Attack Description: Click to open the full attack description. Annotate Description: Click to add your annotations for an attack in the attack encyclopedia. Benign Trigger Probability: Displays a value that indicates the chance that detection for the attack will trigger an alert falsely.

Figure 6-4 Details of the attack

6

When the Customize Severity check box is selected, the default severity level is set to 7 (High). Select a different severity level from the Customize Severity drop-down list, if you want the attack to be of a higher or lesser priority.

30


Administration Walk-through Sensor-level options

6

7

In the Sensor Response area, select Customize and Enable Alert check boxes to activate the alert for this attack.

Figure 6-5 Details of the attack - Sensor response To customize notifications, first select Customize next to each response under Notifications and select the Email, Pager, Script, SNMP, Auto. Ack. and Syslog check boxes as required.

8

Select the Drop DoS attack packets of this attack type when this attack is detected check box if you want to drop offending DoS packets when they are detected. You must set this for each learning mode attack you want dealt with in this manner. This only applies to a Sensor deployed in In-line mode. Note: For detailed information on customization of attack response, see How Customization of Attack Response Works.

See also Response sensitivity on page 23 DoS related actions using CLI Commands on page 4 Setting response sensitivity on page 24

Sensor-level optionsThe following Sensor-level DoS related options are available in the Manager: DoS data management DoS profiles DoS filters DoS related TCP settings Rate Limiting configurations


31

6


DoS data managementThe DoS Data Management page displays information and options on the DoS profiles for the selected Sensor. Task 1 Select / IPS Settings / Sensor_Name | Advanced Scanning | DoS Data Management to view the DoS Data Management page.

Figure 6-6 DoS data management

2

The DoS Data Management page lists the following information and options: DoS Profiles on Manager DoS profiles uploaded to the Manager are listed here. These profiles can be selected for restoration to the Sensor when Restore a DoS Profile (Manager to device) option under DoS Profile Upload and Restoration is selected. DoS Profile Learning Rebuild the DoS Profiles (start the learning process from scratch) Typically, this is only required when: It is known that a DoS attack occurred during the initial learning phase, contaminating the long-term profile. There has been a significant change in network traffic, for example, an overhaul to the routing infrastructure.When a port runs in learning mode, it does not analyze traffic for DoS attacks. You can infer whether DoS attack has occurred during the initial phase or not by reading situations specific to your network.

Force the IPS Sensor into Detection Mode (bypass learning) You can force a Sensor into detection mode before the normal 48-hour minimum learning period. This option must be reserved for testing and troubleshooting.

Manage DoS Packet Copying Actions (not supported on M-series and N-450 Sensors) Enable copying of DoS packets to Response port(s) Disable copying of DoS packets to Response port(s)

32



6

Because of the significant traffic DoS attacks produce, Network Security Platform does not collect DoS related packet logs for forensic analysis. Instead, you have the option to copy DoS packets to a Sensor response port to which you can attach a packet-capturing device.The response port for this purpose is specific to the Sensor model. For example, the I-2700 uses its third response port (R3) for this purpose. One way to know which interface is used for a given model is to go through the motions of enabling the option. The user interface includes the response port number as it prompts you to confirm your choice.

DoS Profile Upload and Restoration Upload a DoS Profile (device to Manager) Restore a DoS Profile (Manager to device)

You can upload the current long-term profiles from the Sensor to the Manager or restore previously uploaded profiles. In most circumstances, there is no need to upload and restore profiles. The exceptions include: The Sensor fails to detect an attack. In this case, the Sensor mistakenly learns the bad traffic pattern as good. A previous profile can be restored to replace the contaminated one, if one was saved. The Sensor is used for testing that skews the long-term profile. To bring the Sensor back in good standing, a profile is saved, the testing is performed, and the previously saved profile is restored. A change to the quantity of interfaces/sub-interfaces is made, but the change needs to be reversed. For example, you add a new sub-interface, which also changes the quantity and makeup of DoS profile. You then decide to back out of the change. Restoring a profile eliminates the requirement to go through the re-learning phase.Rebooting a Sensor does not return it to learning mode. A Sensor stores long-term data and picks up where it left off when the reboot started.

DoS profilesA DoS profile is an analysis of network traffic with reference to the normal traffic flow captured during the learning period of a Sensor. DoS profiles of the selected Sensor are displayed in the DoS profiles page. The profiles can be viewed for information in this page.


33

6


Follow this procedure to view the DoS profiles for a Sensor: Task 1 Select / IPS Settings / Sensor_Name | Advanced Scanning | DoS Profiles to view the DoS Profiles page. The DoS Profile page displays the status (Detection or Learning) of each DoS profile as well as the time of transition from one mode to the other.

Figure 6-7 DOS Profile - List

A DoS profile defines a grouping of traffic for which the Sensor maintains unique profiles. 2 Select a profile and click View to view the profile for the selection. The information displayed is for either Inbound or Outbound traffic for the following measures: Measure tcp-control icmp-echo-count udp-rate icmp-rate ip-frag-rate tcp-rst-rate rejected-tcpseg-rate rejected-pkt-rate syn-fin-rate icmp-echo-req&rep-rate 3 Select a Direction and Measure.

34



6

4

Click View again to see the DoS profile for a selected direction and measure.

Figure 6-8 DoS profile - Measure selection

Figure 6-9 DoS profile - Advanced scanning

The profiles show a comparative display of Short Term and Long Term distribution for the selected profile. The Packet rate tab shows the Packet rate in the last 1 minute. When reading the chart, it is helpful to remember that: The long-term profile is the compilation of the short-term profiles. The horizontal axis contains buckets of the various packet rates. The vertical axis indicates the percentage of those rates falling into each bucket.If you select a profile, which is still in the learning mode, the following message is displayed, "NOTE: The VIDS is still in learning mode".

DoS profile limitsThe limit to the quantity of DoS profiles that can be configured per Sensor is unique for each Sensor model. The details are as follows: I-Series Maximum DoS profiles supported


35

6


I-4010 5,000

I-4000 5,000

I-3000 5,000

I-2700 300

I-1400 120

I-1200 100

M-Series Maximum DoS profiles supported M-8000 5,000 M-6050 5,000 M-4050 5,000 M-3050 5,000 M-2750 300 M-1450 120 M-1250 100

DoS filtersClick / IPS Settings / | Advanced Scanning | DoS Filters to view the DoS Filters page. The DoS Filterspage displays a list of interfaces that will potentially drop DoS packets. DoS packets are not dropped by default, so the DoS Filters list is empty as per default configuration.

Figure 6-10 DoS filters

When you use the Policy Editor to edit the inherited DoS policy that is applied to an interface in theDoS Policy page for the interface (/ IPS Settings / Sensor_Name / >Scanning >DoS Policy), and change the default blocking settings, thereby applying a filter; the applied filter is displayed in the DoS Filters page. The filters displayed are for a unique combination of Resource, Measure, Direction and Filter End Time.

Figure 6-11 DoS filter - Advanced scanning

When blocking is enabled from the IPS Policy Editor, the Filter End Time has a value of ALWAYS. In this case, the packets are blocked from the attacking source until the attack is over. The Filter End Time option becomes applicable when an attack is blocked from the drill-down option of the Threat Analyzer. In that case, we can stipulate that the blocking action be applied to the interface on which that alert was generated for a specified amount of time. For those line items listed in the DoS Filters page the end time can be extended by selecting the Filter and clicking Extend.

36



6

See, Blocking Attacks in the Threat Analyzer.The blocking action can be configured for volume anomalies only; it cannot be configured for categorical anomalies.

See also Blocking attacks in the Threat Analyzer on page 51

DoS related TCP settingsThe TCP Settings page enables configuration of TCP parameters. Some of these parameters are relevant for preventing DoS attacks. Based on the knowledge of your network, you can configure suitable options with specific reference to your network to prevent DoS attacks. Task 1 Click TCP Settings to view the TCP Settings page.

Figure 6-12 TCP settings for DoS

2

Of the configurable parameters, the following parameters are particularly relevant for configuring your TCP settings to prevent DoS. After making configuration changes, clickUpdate. You need to push the changes to the Sensor ( / IPS Settings / Device_Name | Configuration Update >IPS Sensoror IPS Sensoror >. Make changes, if necessary. To remove a port or port range from the selected ports list, make your selection and click . Make changes, if necessary. To remove a port or port range from the selected ports list, make your selection and click .You cannot specify IP protocol numbers 6 (TCP) and 17 (UDP).


43

6

Administration Walk-through Interface-level options

8 9

Make changes, if necessary. To remove a port or port range from the selected port list, select it and click Alert Notificationor / NTBA Settings > Alert Notification) is a prerequisite for forwarding these notifications. Another prerequisite that is specific to e-mail forwarding is to configure the e-mail server settings at the Sensor level ( / Manager > Manager > E-mail Server).The Edit Attack Details pages for Exploit Attacks, Reconnaissance Attacks, NTBA Attacks, and DoS Threshold attacks contain options that are slightly different from the ones illustrated; however, the rules of customization described here apply to those attacks as well.

64


Index

AACL 61 Alert details 5, 50 Alerts 19 Attack settings in the Threat Analyzer 52 Attacks handling 17

Handling vulnerability based DoS 18

IInterface level 44, 47

LLearning 16

BBlocking 21, 27, 31 Blocking in the Threat Analyzer 51

MManage DoS data 32 McAfee ServicePortal, accessing 6 Methods for countering DoS 13

CCategorical anomalies 19 conventions and icons used in this guide 5 Customize attack response 63

PPacket search 15 Percentiles 20 Profile contamination 16 protocol parsing 14

DDDoS attack tools 11 dnsprotect 56 documentation audience for this guide 5 product-specific, finding 6 typographical conventions and icons 5 DoS alerts 9, 47 DoS detection signatures 14 DoS filters 36 DoS learning mode 29 DoS profile limits 35 DoS profiles 33 DoS related CLI commands 55 dospreventionprofile 57, 58 dospreventionseverity 55

QQueue count 41

RRate limiting 39 Response sensitivity 23

SServicePortal, finding product documentation 6 Set response sensitivity 24 Set thresholds 27 Signatures 15 Source IP 16, 56, 57

EEdit policy 23

TTCP settings 37, 44 Technical Support, finding product information 6 Threshold 15 Traffic 23, 27 Traffic management 40

FFlows 14

HHandling DDoS attack tools 18 Handling volume based DoS 17

VVolume anomalies 20


65

Index

Vulnerability based DoS 10

66


700-2384-00

Date post:	16-Jul-2015
Category:	Documents
Upload:	mwadib2050
View:	256 times
Download:	2 times

NSP Denial of Services 6.1

Documents