nsp 81 best practices guide reve en-us

8/19/2019 NSP 81 Best Practices Guide RevE en-us

1/60

Best Practices GuideRevision E

McAfee Network Security Platform 8.1


2/60

COPYRIGHT

Copyright © 2015 McAfee, Inc., 2821 Mission College Boulevard, Santa Clara, CA 95054, 1.888.847.8766, www.intelsecurity.com

TRADEMARK ATTRIBUTIONSIntel and the Intel logo are registered trademarks of the Intel Corporation in the US and/or other countries. McAfee and the McAfee logo, McAfee Active

Protection, McAfee DeepSAFE, ePolicy Orchestrator, McAfee ePO, McAfee EMM, McAfee Evader, Foundscore, Foundstone, Global Threat Intelligence,

McAfee LiveSafe, Policy Lab, McAfee QuickClean, Safe Eyes, McAfee SECURE, McAfee Shredder, SiteAdvisor, McAfee Stinger, McAfee TechMaster, McAfee

Total Protection, TrustedSource, VirusScan are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the US and other countries.Other marks and brands may be claimed as the property of others.

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 8.1 Best Practices Guide

http://www.intelsecurity.com/


3/60

Contents

Preface 5

About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Find product documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Introduction 7

Pre-installation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Cabling best practices 9

3 Hardening the Manager Server for Windows platform 11

Pre-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Post-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Disable non-required services . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Set system policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Set user policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Set the desktop firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Configure audit events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Large Sensor deployments 15Staging Sensors prior to deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Recommendations for large Sensor deployment . . . . . . . . . . . . . . . . . . . . . 16

5 Using active fail-open kits 17

Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Ef fective policy tuning practices 19

Analyzing high-volume attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Managing exception objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Learning profiles in DoS attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Response management 21

Sensor response actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 How to create rule sets 23

Best methods for rule set creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9 Working with firewall policies 25

10 How to handle asymmetric networks 27

11 SSL best practices 29

SSL only traffic - throughput: NS-series Sensors . . . . . . . . . . . . . . . . . . . . . 29

McAfee Network Security Platform 8.1 Best Practices Guide 3


4/60

SSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors . . . . . . . . . . . . . . . . . 30

SSL only traffic — throughput: M-series Sensors . . . . . . . . . . . . . . . . . . . . . 31

SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors . . . . . . . . . . . . . . . . . . 32

SSL only traffic — throughput: I-series Sensors . . . . . . . . . . . . . . . . . . . . . 33

SSL traffic mixed with HTTP 1.1 traffic: I-series Sensors . . . . . . . . . . . . . . . . . . 33

12 Sensor HTTP response processing deployment 35

Tests for enabling HTTP response traffic . . . . . . . . . . . . . . . . . . . . . . . . 35

HTTP response processing results for NS-series Sensors . . . . . . . . . . . . . . . 36

HTTP response processing results for Virtual IPS Sensor . . . . . . . . . . . . . . . 37

HTTP response processing results for M-series Sensors . . . . . . . . . . . . . . . 37

HTTP response processing results for I-series Sensors . . . . . . . . . . . . . . . . 37

13 Sensor performance with Layer 7 Data Collection 39

14 I-series Sensor capacity by model number 45

15 M-series Sensor capacity by model number 47

16 NS-series Sensor capacity by model number 51

17 Virtual IPS Sensor capacity by model number 55

18 Comparison between I-1200/I-1400 and M-1250/M-1450 FE ports 57

Index 59

Contents



5/60

Preface

This guide provides the information you need to configure, use, and maintain your McAfee product.

Contents

About this guide

Find product documentation

About this guideThis information describes the guide's target audience, the typographical conventions and icons used

in this guide, and how the guide is organized.

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.

• Users — People who use the computer where the software is running and can access some or all of

its features.

ConventionsThis guide uses these typographical conventions and icons.

Book title, term,emphasis

Title of a book, chapter, or topic; a new term; emphasis.

Bold Text that is strongly emphasized.

User input, code,

messageCommands and other text that the user types; a code sample; a displayedmessage.

Interface text Words from the product interface like options, menus, buttons, and dialogboxes.

Hypertext blue A link to a topic or to an external website.Note: Additional information, like an alternate method of accessing anoption.

Tip: Suggestions and recommendations.

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



6/60


7/60

1 Introduction

McAfee® Network Security Platform [formerly McAfee® IntruShield®

] is a combination of network

appliances and software, built for the accurate detection and prevention of intrusions and network

misuse.

We recommend that you follow some of the best techniques and tips to use McAfee Network Security

Platform most effectively. This can save considerable time during the installation and tuning process of

the system.

Following chapters outline the best practices for Network Security Platform.

Pre-installation checklist

There are some important tasks that you should consider before McAfee® Network Security Manager

[formerly McAfee® IntruShield®

Security Manager] software installation. For more information, see

Planning for installation, McAfee Network Security Platform Troubleshooting Guide.

1



8/60

1IntroductionPre-installation checklist



9/60

2 Cabling best practices

It is a common practice to physically cable the monitoring ports, only after the McAfee® Network

Security Sensor (Sensor) has been fully configured.

In other words, most administrators cable the console and management ports, use those connections

to configure the solution, and only physically introduce the Sensor into the scanning process once the

proper scanning policies are in place, the monitoring ports have been configured, the latest signature

set has been downloaded, and so on.

Also, in the most security-conscious environments, or those with congestion problems, a privatenetwork is often used to connect the Sensor management ports to the McAfee® Network Security

Manager (Manager). This is another best practice in terms of cabling the Sensors.

2



10/60

2Cabling best practices



11/60

3 Hardening the Manager Server forWindows platform

Implementation of Manager varies from environment to environment. The Manager's physical and

logical position in the network influences specific remote access and firewall configuration

requirements. The following best practices on managing configurable features on Manager impacts the

security of Manager.

These steps are applicable to Windows Server 2008 and Windows Server 2012 editions.

Contents

Pre-installation

Installation

Post-installation

Pre-installation

Use a dedicated machine for the Manager server and then install Manager and the embedded MySQL

database. Other than the host-based firewall, no other software should be installed on the server.

Before installation of Manager do the following:

• Ensure that the server is located in a physically secure environment.

• Connect the server on a protected or isolated network.

• If the hard disk is old, use fdisk (a command line utility) to remove all partitions and create new

partitions.

Installation

Installation of Manager should be performed as follows:

• Install the US version of Windows Server.

• Use NTFS on all partitions.

3



12/60

Post-installation

After installation of Manager perform the following installations:

• Install the latest Windows Server patches, service packs, and hot fixes from Microsoft.

• Install a Virus Scanner and update the signatures.

Exclude "McAfee® Network Security Manager (Manager)" and "MySQL" directories from being

scanned.

Also keep a check on the following:

• Minimize the number of Windows roles and features that are installed.

• Uninstall applications that are not necessary.

Disable non-required servicesDisable the following services:

• DHCP Client

• FTP

• Print spooler

• Remote access auto connection manager

• Remote procedure call locator

• Remote registry

• Server

• TCP/IP NetBIOS helper service

• Telephony service.

Enable these services only if it is absolutely required.

Set system policiesEnsure to set the following system policies:

• Implement the System key and strong encryption of the password database by running

SYSKEY.EXE

• Use Microsoft security compliance toolkit or set local security policy

• Display legal notice at during interactive logon window.

• Do not display username that was earlier used to login.

• Disable Posix

• Clear virtual memory page file during shutdown

• Disable autorun

• Disable LMHOSTS lookup while setting the advanced TCP/IP settings.

3Hardening the Manager Server for Windows platformPost-installation



13/60

Set user policiesMake sure to set the following user policies:

• Rename the administrator account.

• Disable guest account.

• Passwords should be at least 8 ASCII characters.

• Enable locking of screensaver.

Set the desktop firewall

It is recommended that a desktop firewall operates on the Manager server. The following ports are

required for Manager-Sensor communication.

Ensure that there are no other open ports using a scanning tool such as McAfee Vulnerability Manager.

Port Description Communication

80 HTTP port Client to Manager

443 HTTPS Client to Manager

3306 MySQL database Open only while using external SQL database

8500 Command channel(UDP) Manager to Sensor

8501 Install channel (TCP) (1024-bit) Sensor to Manager

8502 Alert channel (TCP) (1024-bit) Sensor to Manager

8503 Packet log channel (TCP) (1024-bit) Sensor to Manager

8504 File transfer channel (TCP) Sensor to Manager

8506 Install channel (TCP) (2048-bit) Sensor to Manager

8507 Alert channel (TCP) (2048-bit) Sensor to Manager

8508 Packet log channel (TCP) (2048-bit) Sensor to Manager

8509 Bulk file transfer channel for 2048-bitcertificates.

Sensor to Manager

8510 Bulk file transfer channel for 1024-bitcertificates.

Sensor to Manager

8555 Alert viewer (TC) Client to Manager

When email notification or SNMP forwarding is configured on Manager and there is firewall between

Manager and SNMP Server, ensure that the following ports are allowed through firewall.


25 SMTP port Manager to SMTP server

162 SNMP forwarding Manager to SNMP server

If you have McAfee ePO™ integration configured on Manager, and there is firewall between Manager

and the McAfee ePO™ Server, ensure the following port is also allowed through firewall.


8443 McAfee ePO™ communication port Manager to McAfee ePO™ server

Hardening the Manager Server for Windows platformPost-installation 3



14/60

Configure audit eventsSet the following events to be audited:

• Audit account logon events • Audit policy change (Success)

• Audit account management • Audit privilege use (Failure)

• Audit logon events • Audit system events (Success)

• Audit object access (Failure)

3Hardening the Manager Server for Windows platformPost-installation



15/60

4 Large Sensor deployments

When you consider large McAfee® Network Security Sensor (Sensor) deployments, (where the number

of Sensors deployed range from 36 to 100) there are some important tasks which should be

considered, before deployment.

McAfee recommends that you have a good understanding on the best techniques required to

accomplish these tasks in your deployment scenario, prior to the deployment.

• Concurrent Signature Set and Sensor Software downloads — In 6.0.7.x and above, the

Manager provides an option for parallel processing of Sensor software and signature set updates.

In earlier releases of 6.0, when multiple Sensors are configured to your Manager, any software

update on the Sensors had to be performed individually. If you are using 5.1, then note that this

option is available on Manager version 5.1.17.2 and above.

This enhancement is applicable only for Sensor updates in the parent domain. The Sensor updates

in the child admin domain is performed in the same method as the earlier releases.

• Sensor Software Updates— All Sensor software updates do require a reboot. A reboot can take

up to 5 minutes. You can schedule this process though you can't reboot the Sensor automatically.

But any update from the Manager Server causes the process to take place sequentially, one Sensor

at-a-time. You can instead use the TFTP method for updating the Sensor image, which helps you to

load concurrent images on the Sensor via the Sensor's CLI, at a much faster rate.

For more information, see Upgrading Sensor software via a TFTP server, McAfee Network Security

Platform CLI Guide.

• Central Manager deployment — If you have a large Sensor deployment of 200 Sensors for

example, which are deployed across various geographic locations, then consider using a Central

Manager at your organization's headquarters and deploy a dedicated Manager for each region. Each

Manager will then handle the daily device operations for all Sensors configured to it. Note that

when you use a Central Manager, your regional/local Managers can add their own region-specific

rules, but cannot modify any configuration established by the Central Manager. Configuration

updates to the Sensors must be applied through the local Managers. See McAfee Network Security

Platform Manager Administration Guide for details.

• Usability — Depending on the number of VIDS and Admin Domains defined in your deployment,

the Manager Resource Tree can become very crowded, which makes it difficult to locate the

resource you require at any point of time. It can also lead to confusion if you have not provided

unique, recognizable names for your Sensors and any VIDS you create. Note that the resourcenames appear both in the Resource Tree of the Manager as well as in Alert data and Reports. Your

VIDS names should also be clear and easy for everyone maintaining the network to recognize at a

glance. For example, compare a worldwide deployment where Sensors are named "4010-1"

through "4010-25" as opposed to "UK-London-sens1," "India-Bangalore-sens1," and so on.

• Alert Traffic — Take note of the volume of alerting in your Sensors. Depending on the policies

deployed on your system, there is potential to starve Manager resources since the resulting alerts

are passed to the Manager. As the volume of alerting increases, more data is passed into the

Manager. The Manager can handle short bursts of high alert volume but on an average, the

Manager can handle a total of 1500 alerts per minute from all the Sensors configured to it.

4



16/60

• Start-up load on the Manager— When the Manager starts, establishing connections with all

Sensors can be time consuming as Sensors continue to collect alerts. If the communication with

the Manager is lost, each Sensor must pass its alert data to the Manager when connectivity is

re-established. So, it is required to account for the start-up load on the Manager.

• Concurrent processes— Be aware of the time periods in which your scheduled processes (such

as database backup or report generation) occur, and try not to attempt other tasks during that time

period, as this can lead to process locking. This includes having many users logged into the systemsimultaneously.

Contents

Staging Sensors prior to deployment

Recommendations for large Sensor deployment

Staging Sensors prior to deployment

With large or very large deployments, and/or if you are planning to release Sensors to various

geographical regions or remote locations, you will have to consider staging your Sensors before you

release them to their final destination.

For example, use the McAfee® Network Security Manager in a lab environment to push Sensor

software to the Sensor, make sure that the Sensor is working as expected, and then box the

configured Sensor and send it to its final destination. For more information, see Updating the

configuration of a Sensor, McAfee Network Security Platform IPS Administration Guide.

Or you might use the TFTP feature to load the Sensor image at one location, before shipping the

Sensor to another. For more information, see Upgrading Sensor software via a TFTP server, McAfee

Network Security Platform Installation Guide.

Very large Sensor deployments mean that the number of Sensors deployed is more than 100. Large

Sensor deployments have Sensors numbering between 36 and 100+.

Recommendations for large Sensor deployment

Most McAfee Network Security Platform customers begin their deployment in their lab environment.

Here they test the Sensor functionality, familiarize themselves with the Manager, and create an initial

policy. Once they are comfortable with the product, they deploy the Sensor in a live environment.

McAfee provides a few recommendations for this process:

• Spend time creating effective policies before actual deployment. Availability of more information

makes the tuning process easier. But policies like the McAfee Network Security Platform provided

All-Inclusive policy can overwhelm you with data, if every Sensor in a large deployment is running

it without any customization.

• Stagger your Sensor deployment in phases. As each new batch of Sensors provides you with more

data points, you can tune your policies more effectively, and become more aggressive in the

number of Sensors you deploy in the next phase.

4Large Sensor deploymentsStaging Sensors prior to deployment



17/60

5 Using active fail-open kits

McAfee supports the following types of passive and active fail-open kits:

• 10/100/1000 Gigabit Copper Passive Fail-Open Bypass Kit

• 1 Gigabit Optical Passive Fail-Open Bypass Kit

• 10 Gigabit Optical Passive Fail-Open Bypass Kit

• 10/100/1000 Copper Active Fail-Open Bypass Kit

• 10/100/1000 Copper Active Fail-Open Bypass Kit with SNMP monitoring

• 1 Gigabit Optical Active Fail-Open Bypass Kit

• 10 Gigabit Optical Active Fail-Open Bypass Kit

Fail-open kits can be deployed in production networks for the following reasons:

• Reduce the network downtime to seconds during any Sensor reboot or Sensor failure

• Protect your network during link failure on the Sensor

• Bypass the traffic when troubleshooting network issues. This will help you identify or eliminate the

Sensor as the cause of network issues

In the passive fail-open kit, if the Sensor goes down, the link has to be renegotiated again betweenthe peer devices and this causes the link to go down for some time. In case of an active fail-open kit,

a physical link will be established between the active fail-open kit and the two peer devices even when

the Sensor is active. There would not be any link flap even when the Sensor goes down. McAfee

recommends deploying active fail-open kits for protection of mission critical networks.

For Virtual IPS Sensors, only 10/100/1000 Copper Active Fail-Open Bypass Kit and 10/100/1000

Copper Active Fail-Open Bypass Kit with SNMP monitoring are supported. For more information, see

Virtual IPS Sensor deployment section in the IPS Administration Guide.

Passive Fail-open

In passive fail-open kits, during normal Sensor in-line, fail-open operation, the Fail-Open Controller or

built-in Control port (depending on which controls the Bypass Switch) supplies power and a heartbeat

signal to the Bypass Switch.

If this signal is not presented within its programmed interval, the Fail-Open Bypass Switch removes

the Sensor from the data path, and moves into bypass mode, providing continuous data flow with little

network interruption. While the Sensor is in bypass mode, traffic passes directly through the switch,

bypassing the Sensor. When normal Sensor operation resumes, you may or may not need to manually

re-enable the monitoring ports from the Manager interface, depending on the activity leading up to the

Sensor's failure.

Active Fail-open

5



18/60

In case of active fail-open kits, during normal Sensor in-line fail-open operation, the built-in

monitoring sends a heartbeat signal (1 every second) to the Bypass Switch. If the Sensor does not

receive 3 heart beat signals within its programmed interval, the Fail-Open Bypass Switch removes the

Sensor from the data path, and moves it into the bypass mode, providing continuous data flow.

When the Bypass Switch loses power, traffic continues to flow through the network link, but is no

longer routed through the Bypass Switch. This allows network devices to be removed and replaced

without network downtime. Once power is restored to the Bypass Switch, network traffic is seamlessly

diverted to the monitoring device, allowing it to resume its critical functions.

Considerations

This section discusses the generic requirements and notes that you need to consider with respect to

active fail-open kits:

• The currently supported active fail-open kits are not plug and play devices. Initial configuration/

setup is required before you begin.

• The following default options are fixed in McAfee active fail-open kits and cannot be changed:

• LFD is set to On

• Bypass Detection is set to Off

Even if you change the configuration for these options using the NetOptics Web Manager or System

Manager, the settings of these options on the McAfee active fail-open kit hardware cannot be changed.

• The management port on the active fail-open bypass kits cannot be configured.

• The parameters for the monitoring port must be set to Auto-Negotiate based on the speed, that is,

10/100/1000 Mbps. McAfee recommends that you set the Speed to 100 Mbps full Duplex with

Auto-Negotiate enabled to improve performance.

• Unlike passive fail-open kits, an active fail-open kit moves into the bypass mode only when it doesnot receive the heart beat signals within its programmed interval. When the Sensor monitoring port

is manually disabled or the cable is pulled out for example, the Manager displays the port status as

AUK (Active Unknown) under Device List / Sensor_Name > Physical Sensor > Port Settings page.

• If you are planning to use the 10/100/1000 copper active fail-open kit with SNMP monitoring, then

note that

• Network Security Platform currently supports only SNMP v1 on active fail-open kits.

• You can configure only a single SNMP Manager. The option to configure a secondary SNMP Manager

is currently not available.

• The active fail-open kits do not provide any CLI option to view the serial and model numbers of the

kits.

• If your network architecture is such that it requires you to remotely manage the active fail-open

kits in your deployment, then you can consider one of the following options:

• Use a terminal server to connect to the system console and then connect using a remote login

[interoperability issues might be seen while using UPLOGIX Terminal Server]

• Pre-configure the kit with the required settings before shipping.

5Using active fail-open kitsConsiderations



19/60

6 Effective policy tuning practices

All Network Security Sensors (Sensors) on initial deployment, have the 'Default Inline IPS' policy

loaded on all interfaces. McAfee recommends that you use the default inline IPS policy as a starting

point, then customize the policies based on your organization's requirements. The customized policies

can be either cloned versions of the default pre-configured policies or custom-built policies that

employ custom rule sets. An appropriately tuned policy will reduce false positives.

Though each network environment has unique characteristics, the following best practices can make

tuning more efficient and effective.

As you interact with Network Security Platform policies, you encounter the term "attack", not

"signature." Network Security Platform defines an attack as being comprised of one or more signatures,

thresholds, anomaly profiles, or correlation rules, where each method is used to detect an attempt to

exploit a particular vulnerability in a system. These signatures and checks may contain very specific

means for identifying a specific known exploit of the vulnerability, or more generic detection methods

that aid in detecting unknown exploits for the vulnerability.

Contents

Analyzing high-volume attacks

Managing exception objects

Learning profiles in DoS attacks

Analyzing high-volume attacks

Take attacks that are generating the most alerts (use Consolidated View in Threat Analyzer ) and investigate

their legitimacy. For more information, see Consolidated View, McAfee Network Security Platform

Manager Administration Guide.

Many of the top alerts seen on the initial deployment of a Sensor will be common false positives seen

in many environments. Typically, at the beginning of the tuning process, it will be evident that your

network or security policy will affect the overall level of alerts. If, for instance, AOL IM is allowed traffic

on the network, then there might not be a need to alert on AOL IM setup flows.

Managing exception objects

When a particular alert is declared as a false positive, the next decision is whether to disable the

corresponding attack altogether OR apply a particular exception object to that attack that will disable

alerting for a particular IP address or range of IP addresses. In almost all cases, it is a best practice to

implement the latter.

6



20/60

For instance, an SMS server may be generating the alert Netbios: Copy Executable file attempt during the

legitimate transfer of login scripts. Rather than disable the alert altogether, and cancel the possibility

of finding a real attack of this nature, we recommend that you create an exception object for the SMS

server and apply it to the attack.

Every exception object created is globally stored, so that the filter can be applied to any Exploit or

Reconnaissance attack.

It is also a best practice to document all your tuning activities. The Report section can be used to

assist the documentation process. The IPS Sensor configuration report will deliver reports that list

exception objects that have been applied and attacks that have been otherwise customized.

For more information, see Managing Exception Objects and Attack Responses, McAfee Network Security

Platform IPS Administration Guide.

Learning profiles in DoS attacks

It is a best practice to let the Sensors learn the profiles of the particular segments they are

monitoring, before tuning DoS attacks. This is Learning Mode operation. The learning process takes

two days. During this period it is not unusual to see DoS alerts associated with normal traffic flows (fo

example, DoS SYN flood alerts reported outbound on a firewall interface to the Internet). After a

profile has been learned, the particulars of the profile (number of SYNS, ACKS, and so on) can be

viewed per Sensor.

DoS detection can also be implemented using the Threshold Mode. This involves setting thresholds

manually for the type of segment characteristics that are learned in Learning Mode. Implementing this

mode successfully is critically dependent on detailed knowledge of the segments that the particular

Sensors are monitoring.

It is a best practice to have the Sensor re-learn the profile when there is a network change (that is,

you move the Sensor from a lab or staging environment to a production environment) or a

configuration change (that is, you change the CIDR block of a sub-interface) that causes a significantsudden traffic change on an interface. If the Sensor does not re-learn the new environment, it may

issue false alarms or fail to detect actual attacks during a time period when it is adapting to the new

network traffic conditions. There is no need to re-learn a profile when network traffic increases or

decreases naturally over time (for example, an e-Commerce site that is getting more and more

customers; thus its Web traffic increases in parallel), since the Sensor can automatically adapt to it.

For more information, see Managing DoS Learning Mode profiles on a Sensor, McAfee Network Security

Platform IPS Administration Guide.

6Effective policy tuning practicesLearning profiles in DoS attacks



21/60

7 Response management

When McAfee® Network Security Sensor (Sensor) detects an activity which violates a configured

security policy, a preset response from the Sensor is integral to the protection or prevention process.

Proper configuration of responses is crucial to maintaining effective protection. Critical attacks like

buffer overflows and DoS attacks require responses in real time, while scans and probes can be logged

and researched to determine compromise potential and the source of the attack.

Developing a system of actions, alerts, and logs based on specific attacks or attack parameters (such

as severity) is recommended for effective network security. For example, since McAfee® Network

Security Platform can be customized to protect any zone in a network, knowing what needs to beprotected can help to determine the response type.

If the Sensor is monitoring the network outside of the firewall in inline mode, preventing DoS attacks

and attacks against the firewall is crucial. Other suspicious traffic intended for the internal network,

such as scans and low-impact well-known exploits, are best logged and analyzed as the impact is not

immediate. In this case, a better understanding of the potential attack purpose can be determined.

Thus, if you are monitoring outside of a firewall in in-line mode, it is important not to set the policies

and responses so fine that they disrupt the flow of traffic and slow down the system.

Remember that response actions are decoupled from alerting. Pay particular attention to this with the

Recommended For Blocking (RFB) category of attacks, lest you enable blocking for an attack, but

disable alerting, causing the attack to be blocked without your knowledge.

When there are multiple attempts to login to a specific web server from a client, the Sensor detects a

reconnaissance Brute force attack (Attack ID 0x40256b00) and raises an alert. Brute force attacks are

used by programs, such as password crackers, to try many different passwords in order to guess the

correct one. The alerts raised are threshold based. The Sensor may generate an alert even in

scenarios, where a legitimate user keeps on retrying to login to the web server simply because he has

forgotten his password. Instances of someone mistyping a password or username on the login are also

common. In such cases, valid traffic flow would be blocked or subject to unnecessary responses from

the Sensor, leading to a false positive. Consequently, the traffic might be dropped.

When such alerts are seen in high volume, there may be multiple reasons for it, like, a dictionary

attack against the web server, or network monitoring systems (like WebSense) not updated with a

user password change, and so on.

McAfee® Network Security Platform recommends that while configuring a Reconnaissance policy, you

to edit and set optimum threshold values to suit your particular environment. This avoids unnecessary

responses from the Sensor and hindrance to the traffic flow.

For example, if you have a web-server farm behind the Sensor so there are more HTTP logins seen on

this segment, in such a scenario you require to set higher thresholds. The default values are good for

most environments.

7



22/60

Sensor response actions

There are multiple Sensor actions that are available for configuration per attack. These include:

• Dropping Alert Packets— Only works in in-line mode. Will drop a detected attack packet and all

subsequent packets in the same flow.

• Quarantine— Sensor will quarantine or remediate a host as per the configurations in McAfee® NetworkSecurity Manager and the Sensor monitoring ports. Quarantine can be enabled per attack in the

Policy Editors.

For more information, see McAfee Network Security Platform IPS Administration Guide.

7Response managementSensor response actions



23/60

8 How to create rule sets

A rule set is configured based on attack category, operating system, protocol, application, severity,

and benign trigger probability options. Each rule in a set is either an include rule or an exclude rule.

An include rule (which should always start a rule set) is a set of parameters that encompass a broad

range of well-known attacks for detection. An exclude rule removes elements from the include rule in

order to focus the policy's rule set.

Proper creation of rule sets is essential for eliminating false positives and ensuring maximum

protection on your network. These best practices can assist while creating rules sets in the McAfee®

Network Security Manager.

Best methods for rule set creation

There are two best practice methods employed for creating rule sets.

• General-to-specific rule creation — The first method is general-to-specific. Start with an include

rule that covers a broad range of operating systems, applications and protocols. After this, create

one or more exclude rules to strip away specific operating systems, protocols, et cetera, thus

focusing the rule set on the environment where it will be enforced. For example, start with an

include rule for all Exploit category attacks. Follow this with multiple exclusion rules that strip away

protocols, applications, severities, et cetera, that are rarely or never seen in a zone of your

network.

• Collaborative rule creation — The second method is collaboration: Create multiple include rules

within one rule set for each category, operating systems, et cetera, combination that needs to be

detected. Each criterion must be matched in order for an alert to be triggered. For example, create

the first rule in the set with the Exploit category, Unix as the OS, Sendmail as the application, and

SMTP as the protocol. Next, create another include rule for Exploit, Windows 2000, WindMail, and

so forth in the same manner. Each include rule added, broadens the scope of the detection.

For more information, see Managing Rule Sets, McAfee Network Security Platform IPS

Administration Guide.

8



24/60

8How to create rule setsBest methods for rule set creation



25/60

9 Working with firewall policies

Review the following points while working with Firewall policies:

• You cannot set explicit access rules for protocols that negotiate ports dynamically, with the

exception of FTP, TFTP, and RPC services. Protocols such as H.323 and Netmeeting, which negotiate

the data channel separately from the control channel, or negotiate ports that do not follow a

standard, are not supported. However, you can explicitly deny these protocol instances by denying

the fixed control port. However, you can configure access rules to explicitly deny these protocol

instances by denying the fixed control port.

• For RPC services, you can configure explicit permit and deny rules for RPC as a whole, but not its

constituents, such as statd and mountd.

• Protocols or services, such as instant messaging and peer-to-peer communication, that use

dynamic ports, are not supported.

• An alternative option for denying protocols that use dynamic ports is to configure IDS policies to

drop the attacks that are detected in such transmissions. Network Security Platform detects use of

and attacks in such programs as Yahoo Messenger, KaZaA, IRC, and so on.

• There is a limit on the number of access rules that can be supported by various Sensor models.

For more information, see McAfee Network Security Platform IPS Administration Guide

9



26/60

9Working with firewall policies



27/60

10 How to handle asymmetric networks

Traffic that uses a different path for the request vs. response is termed as asymmetric traffic. There

are chances of having asymmetric traffic within a network, when networks increase in size.

If there are chances of asymmetric traffic in your network, consider the following options:

• Install IPS Sensors at a location where the traffic is symmetric.

• Implement a port clustering configuration for asymmetric traffic. Port clustering [referred to as

Interface groups in the Manager] enables multiple ports on a single Sensor to be grouped together

for effective traffic monitoring. Asymmetric networks are common in load balancing and active/passive configurations, and a complete transmission may be received on one segment, but depart

on another. Thus keeping state of asymmetric transmissions is essential for successfully monitoring

the traffic. Interface groups normalize the impact of traffic flows split across multiple interfaces,

thus maintaining state to avoid information loss.

• Place an IPS Sensor each on the request and the response path of the asymmetric traffic and

create a failover pair to sync up the traffic flow between the two Sensors.

• If you are using a failover pair to monitor asymmetric traffic where the TCP traffic is going through

two geographically different data centers, connect the Sensors using dark fiber. In this option, both

the Sensors will have full state.

• When the distance between the two IPS Sensors is such that a failover pair cannot be created,

consider enabling Stateless Inspection. In Stateless Inspection, the Sensor detects attacks withoutrequiring a valid TCP state. This option should be used only when Sensors are placed in a network

where the Sensors do not see all packets of a TCP flow like in an asymmetric network

configuration.

When Stateless Inspection is enabled: - ACLs and syn cookie protection cannot be enabled. - HTTP

redirection to the Remediation Portal may or may not work depending on your network deployment

scenario for example, in a setup where SYN+ACK packets cannot be sent from the Sensor to the

client

The diagram below explains about HTTP traffic flow in an asymmetric network between User A and the

University Admin server. The outgoing connection flow from User A is through Switch 1, Switch 2,

Network Security Sensor 1, Router 1, Internet Service Provider 1, to the Internet connection. The

return path for the packet however, is through Internet Service Provider 2, Router 2 etc. If traffic flows

by the Sensor in an asymmetric manner as described above, all packets of a TCP flow are not visibleto a single Sensor.

In such a scenario, if Stateless Inspection is enabled, the Sensor will inspect packets without having

the valid state for the TCP connection. Consequently, it might generate false positives that is, when a

single communication flow is divided across paths, each interface will receive and analyze part of the

conversation and therefore be susceptible to false positives and false negatives.

10



28/60

When you enable Stateless Inspection, there are chances of false positives, and the detection accuracy

will be lower compared to when the Sensor sees all traffic. McAfee recommends that you use this

feature only when network configuration does not allow the Sensor to be placed in locations where it

could see all traffic.

10How to handle asymmetric networks



29/60

11 SSL best practices

Note that there is a performance impact when using the SSL decryption feature. If there is a lot of

outbound SSL traffic from the client to the internet as well, it consumes SSL flows. Therefore, to

enable the Sensor to effectively utilize the SSL decryption feature, it is recommended to bypass these

outbound SSL traffic using ACL Exception Objects.

Refer to the following sections for the SSL throughput measurements and test methodologies.

SSL decryption feature is not supported on IPS-VM600 and IPS-VM100.

Contents

SSL only traffic - throughput: NS-series Sensors

SSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors

SSL only traffic — throughput: M-series Sensors

SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors

SSL only traffic — throughput: I-series Sensors

SSL traffic mixed with HTTP 1.1 traffic: I-series Sensors

SSL only traffic - throughput: NS-series Sensors

• Session resumption for 4 out of 5 TCP connections

• 5 HTTP 1.1 get page requests per TCP connection with a 10K response each

• 128-bit ARC4

NS9300

1024 bit key length 2048 bit key length

Max. SSL Connections / Sec. 44000 30800

SSL Throughput 20 Gbps 12 Gbps

NS9200




NS9100

11



30/60



SSL Throughput 8 Gbps 5.5 Gbps

NS7300




NS7200




NS7100

1024 bit key length 2048 bit key lengthMax. SSL Connections / Sec. 3500 3500

SSL Throughput 1.5 Gbps 1.5 Gbps

SSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors



• 128-bit ARC4

NS9300




HTTP 1.1 Throughput 36 Gbps 36 Gbps

Total Throughput 40 Gbps 40 Gbps

NS9200






NS9100

11SSL best practicesSSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors



31/60






NS7300






NS7200






NS7100




HTTP 1.1 Throughput 0.5 Gbps 0.5 Gbps

Total Throughput 1.5 Gbps 1.5 Gbps

SSL only traffic — throughput: M-series Sensors



• 128-bit ARC4

M-8000 M-6050 M-4050 M-3050 M-2950 M-2850

Max. SSL Connections / Sec. 8500 4500 2700 1300 750 550

Throughput (Mbps) - 1024 bit keylength

3.8 Gbps 2 Gbps 1200 Mbps 600 Mbps 400 Mbps 250 Mbps

Throughput (Mbps) - 2048 bit keylength

1.2 Gbps 600 Mbps 550 Mbps 320 Mbps 320 Mbps 200 Mbps

SSL best practicesSSL only traffic — throughput: M-series Sensors 11



32/60

SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors



• 128-bit ARC4

M-8000



SSL Throughput 800 Mbps 700 Mbps

HTTP 1.1 Throughput 8 Gbps 7.9 Gbps


M-6050




HTTP 1.1 Throughput 4 Gbps 3.9 Gbps


M-4050




HTTP 1.1 Throughput 2.5 Gbps 2.5 GbpsTotal Throughput 2.7 Gbps 2.6 Gbps

M-3050




HTTP 1.1 Throughput 1.2 Gbps 1.2 Gbps


M-2950




HTTP 1.1 Throughput 900 Mbps 900 Mbps

Total Throughput 980 Mbps 960 Mbps

M-2850

11SSL best practicesSSL traffic mixed with HTTP 1.1 traffic: M-series Sensors



33/60



SSL Throughput 50 Mbps 40Mbps



SSL only traffic — throughput: I-series Sensors


• 128-bit ARC4


I-2700 I-3000 I-4000 I-4010

Max. SSL Connections / Sec. 325 600 800 1200

Throughput (Mbps) - 1024 bit key length 85 Mbps 155 Mbps 200 Mbps 310 Mbps


5 HTTP 1.1 get page requests per TCP connection with a 10K response each

I-2700 I-3000 I-4000 I-4010

Max. SSL Connections / Sec. 300 400 800 800


SSL traffic mixed with HTTP 1.1 traffic: I-series Sensors• Session resumption for 4 out of 5 TCP connections


• 1024-bit RSA

• 128-bit ARC4

I-2700





I-3000





SSL best practicesSSL only traffic — throughput: I-series Sensors 11



34/60

I-4000





I-4010





11SSL best practicesSSL traffic mixed with HTTP 1.1 traffic: I-series Sensors



35/60

12 Sensor HTTP response processingdeployment

HTTP response processing is disabled by default. You can enable it for each traffic direction on an

interface pair. To minimize the potential performance impact on the McAfee® Network Security Sensor

(Sensor), we recommend that you enable HTTP response processing on the minimum number of ports

and in only the required directions to achieve your protection goals.

Some examples of HTTP response processing deployment:

• You want to protect a bunch of clients on your internal network - enable HTTP response processing

for inbound traffic only.

• You are serving Web content to external clients, and do not wish to serve attacks embedded in

HTTP response traffic - enable HTTP response processing for outbound traffic only.

• You want to protect both internal clients as well as the Web content you are serving to external

clients- enable HTTP response processing in both directions.

Tests for enabling HTTP response traffic

The test results provided in the next two sections illustrate potential impact of enabling responseprocessing traffic.

The things to note about the test are given below.

• The test involves only HTTP traffic. Changing the HTTP response processing setting does not

change the Sensor performance for any other protocol. Therefore, changes in aggregate Sensor

performance will depend on the proportion of HTTP traffic to other traffic on the link being

monitored.

• The test sends equal HTTP request and response loads in both directions through the Sensor.

Typical real-world deployments do not have equal amounts of HTTP request traffic and response

traffic in both directions through the Sensor. Usually, there is significant amount of request traffic in

one direction and response traffic in the opposite direction. Since HTTP requests are typically


36/60

• The test sends HTTP request continuously at maximum load. Real-world networks are typically

loaded, occasionally peaking at maximum capacity, but typically running at significantly lower

throughput. The test results reflect performance at sustained load. When not running at maximum

load, the Sensor can absorb larger bursts without significant impact.

• The test environment was created to illustrate the likely worst-case performance impact, expected

to occur in deployments protecting large Web server farms. In these deployments, HTTP response

processing typically provides little value because all HTTP response traffic is sourced from trustedservers, which do not usually transmit hostile content due to the security measures taken. In these

environments, customers can consider selectively enabling HTTP response processing to better

optimize their network.

The net result of all of these factors is that in typical networks, the impact of enabling HTTP response

processing is not noticed. The exact impact is, of course, dependent on the traffic being inspected and

some environments could see a reduction in performance as significant as the test results indicate.

The factors to take into account include:

• proportion of HTTP traffic to other protocols

• relative amount of HTTP requests and responses in each direction and,

• size of a response page sent to the client by the sites or applications that are typically accessed.

For Sensor performance numbers under the following conditions:

• HTTP response processing enabled/disabled and

• 5 HTTP 1.1 get page requests per TCP connection with a 10K response each sent in one direction,

HTTP response processing results for NS-series Sensors

Refer to the following table for NS-series Sensor performance numbers with HTTP response

processing:

Model No. HTTP Response Scanning Enabled for outbound direction

5 HTTP 1.1 get page requests per TCP connection with a 10K response each

NS9300 40 Gbps

NS9200 20 Gbps

NS9100 10 Gbps

NS7300 5 Gbps

NS7200 3 Gbps

NS7100 1.5 Gbps

The NS-series performance numbers when HTTP response is disabled will be higher. For example, the

NS9100 performance with HTTP response scanning disabled will be higher than 10 Gbps.

12Sensor HTTP response processing deploymentTests for enabling HTTP response traffic



37/60

HTTP response processing results for Virtual IPS Sensor

Refer to the following table for Virtual IPS Sensor performance numbers with HTTP response

processing:

Model No. HTTP Response Scanning Disabled HTTP Response Scanning Enabled foroutbound direction

5 HTTP 1.1 get page requests per TCPconnection with a 10K response each


IPS-VM600 600 Mbps 600 Mbps

IPS-VM100 100 Mbps 100 Mbps

HTTP response processing results for M-series Sensors

Refer to the following table for M-series Sensor performance numbers with HTTP response processing:




M-8000 10 Gbps 5.4 Gbps

M-6050 5 Gbps 2.8 Gbps

M-4050 3 Gbps 2 Gbps

M-3050 1.5Gbps 1 Gbps

M-2950 1.0 Gbps 850 Mbps

M-2850 600 Mbps 500 Mbps

M-2750 600 Mbps 500 Mbps

M-1450 200 Mbps 200 Mbps

M-1250 100 Mbps 100 Mbps

HTTP response processing results for I-series Sensors

Refer to the following table for I-series Sensor performance numbers with HTTP response processing:




I-4010 2 Gbps 1 Gbps

I-4000 1.78 Gbps 1 Gbps

I-3000 1 Gbps 680 Mbps

I-2700 550 Mbps 430 Mbps

I-1400 195 Mbps 160 Mbps

I-1200 97 Mbps 75 Mbps

Sensor HTTP response processing deploymentTests for enabling HTTP response traffic 12



38/60

12Sensor HTTP response processing deploymentTests for enabling HTTP response traffic



39/60

13 Sensor performance with Layer 7 DataCollection

Turning on the Layer 7 Data Collection feature reduces Sensor performance.

• HTTP Response Scanning setting

• Proportion of HTTP traffic to other protocols

• Relative number of HTTP requests and responses in each direction

• Size of a response page sent to the client by the sites or applications that are typically accessed

The following table provides the performance details in a test environment.

• The test environment used 5 HTTP 1.1 get page requests per TCP connection with a 10 K response,

each sent in one direction.

• When Advanced Traffic Inspection is enabled, in a deployment with 90 percent of traffic without

evasions and 10 percent of traffic with evasions, the overall Sensor throughput would further drop

by an additional five percent approximately. For example , if you get 1 Gbps throughput with Layer

7 Data Collection enabled, you would see 950 Mbps if Advanced Traffic Inspection is also enabled.

NS-series Sensor performance with Layer 7 Data Collection

Table 13-1 NS9x00 performance details with respect to Layer 7 Data Collection

Sensor Model Layer 7 Data Collection setting HTTP ResponseScanning setting

Observed throughput

NS9300 Disabled Disabled 40 Gbps

Enabled for outbounddirection

40 Gbps

Percentage of flows that captureL7 data: 5

Disabled 40 Gbps


40 Gbps


Disabled 40 Gbps

Enabled for outbounddirection 40 Gbps



20 Gbps


Disabled 20 Gbps


20 Gbps

13



40/60

Table 13-1 NS9x00 performance details with respect to Layer 7 Data Collection (continued)


Observed throughput


Disabled 20 Gbps


20 Gbps



10 Gbps


Disabled 10 Gbps


10 Gbps


Disabled 10 Gbps


10 Gbps

Table 13-2 NS7x00 performance details with respect to Layer 7 Data Collection


Observed throughput



5 Gbps


Disabled 7 Gbps


5 Gbps


Disabled 7 Gbps


5 Gbps



3 Gbps


Disabled 6 Gbps


3 Gbps


Disabled 6 Gbps


3 Gbps


Enabled for outbounddirection 1.5 Gbps


Disabled 2 Gbps


1.5 Gbps


Disabled 2 Gbps


1.5 Gbps

13Sensor performance with Layer 7 Data Collection



41/60

Virtual IPS Sensor performance with Layer 7 Data Collection

Table 13-3 Sensor performance details with respect to Layer 7 Data Collection

Sensor model Layer 7 Data Collection setting HTTP ResponseScanning setting

Observed throughput

IPS-VM600 Disabled Disabled 600 Mbps


500 Mbps


Disabled 600 Mbps


400 Mbps


Disabled 600 Mbps


350 Mbps

IPS-VM100 Disabled Disabled 100 Mbps


100 Mbps


Disabled 100 Mbps


90 Mbps


Disabled 100 Mbps


85 Mbps

M-series Sensor performance with Layer 7 Data Collection

Table 13-4 Sensor performance details with respect to Layer 7 Data Collection

Sensormodel

Layer 7 Data Collection setting HTTP ResponseScanning setting

Observedthroughput

M-8000 Disabled Disabled 10 Gbps


5.4 Gbps

Percentage of flows that capture L7data: 5

Disabled 9 Gbps


4.4 Gbps


Disabled 8.7 Gbps


4.2 Gbps



2.8 Gbps


Disabled 4.5 Gbps


2.2 Gbps


Disabled 4.4 Gbps


2.1 Gbps


Sensor performance with Layer 7 Data Collection13



42/60

Table 13-4 Sensor performance details with respect to Layer 7 Data Collection (continued)

Sensormodel


Observedthroughput


2 Gbps


Disabled 2.7 Gbps


1.3 Gbps


Disabled 2.6 Gbps


1.2 Gbps

M-3050 Disabled Disabled 1.5 Gbps


1 Gbps


Disabled 1.4 Gbps


0.7 Gbps


Disabled 1.3 Gbps


0.6 Gbps



850 Mbps


Disabled 921 Mbps


446 Mbps

Percentage of flows that capture L7

data: 100

Disabled 891 Mbps


431 Mbps

M-2850 Disabled Disabled 600 Mbps


500 Mbps


Disabled 540 Mbps


261 Mbps


Disabled 522 Mbps


253 Mbps



200 Mbps


Disabled 180 Mbps


180 Mbps


Disabled 174 Mbps


174 Mbps




43/60

Table 13-4 Sensor performance details with respect to Layer 7 Data Collection (continued)

Sensormodel


Observedthroughput



100 Mbps


Disabled 90 Mbps


90 Mbps


Disabled 87 Mbps


87 Mbps

Sensor performance with Layer 7 Data Collection13



44/60




45/60

14 I-series Sensor capacity by modelnumber

The following table lists McAfee® Network Security Sensor (Sensor) limitations by category and by

Sensor model.

Maximum Type I-4010 I-4000 I-3000 I-2700 I-1400 I-1200

Aggregate Performance 2 Gbps 2 Gbps 1 Gbps 600 Mbps 200 Mbps 100 Mbps

Concurrent connections 1,000,000 1,000,000 500,000 250,000 80,000 40,000

Connections established per sec. 25,000 25,000 10,000 6,250 2,000 1,000

Concurrent SSL Flows 100,000 100,000 50,000 25,000 NA NA

Number of SSL keys that can bestored on the Sensor

64 64 64 64 NA NA

Virtual Interfaces (VIDS) perSensor

1,000 1,000 1,000 100 32 16

VLAN / CIDR Blocks per Sensor 3,000 3,000 3,000 300 64 32

VLAN / CIDR Blocks per Interface 254 254 254 254 64 32

Customized attacks

See the note below on how thenumber of customized attacks isaffected.

100,000 100,000 100,000 100,000 40,000 20,000

Exception objects 131,072 131,072 131,072 65,535 32,000 20,000

Number of attacks with exceptionobjects

128,000 128,000 128,000 64,000 20,000 16,000

Default number of supported UDPFlows

100,000 100,000 50,000 25,000 10,000 5,000

Supported UDP Flows 750,000 750,000 375,000 187,500 60,000 30,000

DoS Profiles 5,000 5,000 5,000 300 120 100

SYN rate (64-byte packets persecond)

1,000,000 1,000,000 500,000 250,000 64,000 83,000

Effective (Firewall) Access Rules(refer to note below)

1,000 1,000 1,000 400 100 50

For more information on computing Effective Access Rules, see IPS Administration Guide.

Note for customized attacks

14



46/60

Customized attacks are not to be confused with custom attacks. A custom attack is a user-defined

attack definition either in the McAfee's format or the Snort rules language. Whereas a customized

attack is an attack definition (as part of the signature set), for which you modified its default settings

For example, if the default severity of an attack is 5 and you change it to 7, it is a customized attack.

The signature set push from the Manager to a Sensor fails if the number of customized attacks on the

Sensor exceeds the customized attack limit.

The number of customized attacks can increase due to:

• Modifications done to attacks on a policy by users.

• Recommended for blocking (RFB) attacks.

• User created asymmetric policies.

Example: How numerous customized attacks are created in asymmetric policies.

1 Create a policy.

2 Set the Inbound rule set to "File Server rule set".

3 Set the Outbound rule set to "All-inclusive with Audit rule set".

You see that:

• The File Server rule set has 166 exploit attacks.

• The All-inclusive with Audit rule set has 2204 exploit attacks.

The total number of customized attacks for this policy is 2204 – 116 = 2038 customized attacks.

14I-series Sensor capacity by model number



47/60

15 M-series Sensor capacity by modelnumber

MaximumType

M-8000 M-6050 M-4050 M-3050 M-2950 M-2850 M-1450 M-1250

AggregatePerformance

10 Gbps 5 Gbps 3 Gbps 1.5 Gbps 1 Gbps 600Mbps

200Mbps

100Mbps

Maximum

throughputwith testequipmentsending UDPpacket size of 1518 bytes

Up to 20

Gbps

Up to 10

Gbps

Up to 4

Gbps

Up to 2.5

Gbps

Up to

1.5Gbps

Up to 1

Gbps

Up to

300Mbps

Up to

150Mbps

Concurrentconnections

5,000,000 2,500,000 2,000,000 1,000,000 750,000 750,000 80,000 40,000

Connectionsestablished persec.

120,000 60,000 36,000 18,000 15,000 10,000 4,000 2,000

Default numberof supportedUDP Flows

100,000 100,000 100,000 50,000 50,000 25,000 10,000 5,000

Supported UDPFlows

3,000,000 1,500,000 750,000 375,000 375,000 187,500 60,000 30,000

Latency

(Average UDPper packetLatency)

< 100microseconds

< 100microseconds

< 100microseconds

< 100microseconds

< 100microseconds

< 100microseconds

< 100microseconds

< 100microseconds

SSL Flow count 400,000 200,000 150,000 75,000 25,000 25,000 NA NA

Number of SSLcertificates thatcan beimported intothe Sensor

256 256 256 256 256 256 NA NA

Quarantinerules perSensor- IPv4

1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000

Quarantinerules perSensor- IPv6

500 500 500 500 500 500 500 500

QuarantineZones perSensor

50 50 50 50 50 50 50 50

15



48/60

MaximumType

M-8000 M-6050 M-4050 M-3050 M-2950 M-2850 M-1450 M-1250

QuarantineZone ACLs perSensor

1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000

Virtual

Interfaces(VIDS) perSensor

1,000 1,000 1,000 1,000 1,000 100 32 32

VLAN / CIDRBlocks perSensor

3,000 3,000 3,000 3,000 300 300 64 32

VLAN / CIDRBlocks perInterface

254 254 254 254 254 254 64 32

Customizedattacks

See the notebelow on how

the number of customizedattacks isaffected.

100,000 100,000 100,000 100,000 100,000 100,000 40,000 20,000

Exceptionobjects

262,144 262,144 262,144 262,144 131,072 131,072 65,536 32,768

Number of attacks withexceptionobjects

128,000 128,000 100,000 100,000 100,000 100,000 40,000 20,000

DoS Profiles 5,000 5,000 5,000 5,000 5,000 300 120 100

SYN cookie rate(64-bytepackets persecond)

5,000,000 2,500,000 2,000,000 1,500,000 800,000 600,000 250,000 200,000

Effective(Firewall)accessrules

10,000 5,000 3,000 3,000 2,000 2,000 1,000 1,000

Firewall ruleobjects

70,000 35,000 21,000 21,000 14,000 14,000 7,000 7,000

Firewall DNSrule objects

2,500 1,250 1,000 1,000 750 750 500 500

Firewall ruleobject groups

500 400 300 300 200 200 100 100

Application onCustom Portrule objects

1,000 500 500 500 250 250 150 150

Firewalluser-based ruleobjects

2,500 1,250 1,000 1,000 750 750 500 500

Firewall usergroups inaccess rules

10,000 10,000 10,000 10,000 10,000 10,000 10,000 10,000

15M-series Sensor capacity by model number



49/60

MaximumType

M-8000 M-6050 M-4050 M-3050 M-2950 M-2850 M-1450 M-1250

Number of whitelist entriespermitted for IPReputation

128 128 128 128 64 64 32 32

Maximum hostentriessupported forConnectionLimiting policies

256,000 256,000 256,000 256,000 256,000 256,000 128,000 128,000

Maximum filesize duringpacket capture

100 MB 100 MB 100 MB 100 MB 58 MB 58 MB 40 MB 40 MB

Passive deviceprofile limits

100,000 100,000 50,000 25,000 15,000 15,000 10,000 5,000

AdvancedMalware -Maximum

simultaneousfile scancapacity withfile save

50 50 50 50 32 32 16 16

AdvancedMalware -Maximumsimultaneousfile scancapacitywithout filesave

1,024 1,024 1,024 1,024 1,024 1,024 255 255

SSL decryption is not supported on M-1450 and M-1250 Sensors.

The number of supported SSL flows on a Sensor directly impacts the number of TCP flows that can be

processed simultaneously.












M-series Sensor capacity by model number15



50/60


1 Create a policy.



You see that:




15M-series Sensor capacity by model number



51/60

16 NS-series Sensor capacity by modelnumber

The following table describes the supported NS-series Sensor capacity.

Maximum Type NS9300 NS9200 NS9100 NS7300 NS7200 NS7100

AggregatePerformance

40 Gbps 20 Gbps 10 Gbps 5 Gbps 3 Gbps 1.5 Gbps

Max Throughputwith testequipmentsending UDPpacket size of 1512 Bytes

up to 70Gbps

up to 35Gbps

up to 30Gbps

up to 15Gbps

up to 10Gbps

up to 5Gbps

ConcurrentConnections

32,000,000 16,000,000 13,000,000 10,000,000 5,000,000 3,000,000

Connectionsestablished persecond

1,000,000 575,000 450,000 225,000 200,000 135,000

Default number of supported UDPFlows

800,000 400,000 300,000 150,000 150,000 150,000

Supported UDPFlows maximum

12,000,000 6,000,000 6,000,000 3,000,000 3,000,000 3,000,000

Supported UDPFlows minimum

1,000 1,000 1,000 1,000 1,000 1,000

Latency

(Average UDP perpacket Latency)


52/60


Quarantine Zonesper Sensor

50 50 50 50 50 50

Quarantine ZoneACLs per Sensor

1,000 1,000 1,000 1,000 1,000 1,000

Virtual Interfaces(VIDS) per Sensor(Number of Virtual IPSSystems)

1,000 1,000 1,000 1,000 1,000 1,000

VLAN / CIDRBlocks per Sensor

3,000 3,000 3,000 3,000 3,000 3,000

VLAN / CIDRBlocks perInterface

254 254 254 254 254 254

Customizedattacks

See the note

below on how thenumber of customizedattacks isaffected.

100,000 100,000 100,000 100,000 100,000 100,000

Exception objects 262,144 262,144 262,144 262,144 262,144 262,144

Number of attackswith exceptionobjects

128,000 128,000 128,000 128,000 128,000 128,000

DoS Profiles 5,000 5,000 5,000 5,000 5,000 5,000

SYN cookie rate(64 ‑ byte packetsper second)

13,500,000 9,000,000 5,000,000 3,300,000 1,800,000 1,400,000

Effective(Firewall) accessrules

20,000 20,000 10,000 5,000 3,000 3,000

Firewall ruleobjects

140,000 140,000 70,000 35,000 21,000 21,000

Firewall DNS ruleobjects

5,000 5,000 2,500 1,250 1,000 1,000

Firewall ruleobject groups

1,000 1,000 500 400 300 300

Application onCustom Port ruleobjects

2,000 2,000 1,000 500 500 500

Firewalluser-based ruleobjects

5,000 5,000 2,500 1,250 1,000 1,000

Firewall usergroups in accessrules

10,000 10,000 10,000 10,000 10,000 10,000

Number of whitelist entriespermitted for IPReputation

128 128 128 128 128 128

16NS-series Sensor capacity by model number



53/60


Maximum hostentries supportedfor ConnectionLimiting policies

256,000 256,000 256,000 256,000 256,000 256,000

Maximum file size

during packetcapture

100 MB 100 MB 100 MB 100 MB 100 MB 100 MB

Passive deviceprofile limits

100,000 100,000 50,000 100,000 50,000 25,000

AdvancedMalware -Maximumsimultaneous filescan capacity withfile save

50 50 50 50 50 50

AdvancedMalware -Maximum

simultaneous filescan capacitywithout file save

4,094 4,094 4,094 4,094 4,094 4,094

New HTTPconnections persecond(using 1GET with 5000HTTP response)

700,000 375,000 260,000 135,000 128,000 115,000













1 Create a policy.



You see that:




NS-series Sensor capacity by model number16



54/60

16NS-series Sensor capacity by model number



55/60

17 Virtual IPS Sensor capacity by modelnumber

The following table describes the supported Virtual IPS Sensor capacity.

Table 17-1 Virtual IPS Sensor capacity by model number

Maximum Type IPS-VM600 IPS-VM100

Aggregate Performance 600 Mbps 100 Mbps

Maximum throughput with test equipment sending UDPpacket size of 1518 bytes

Up to 1 Gbps Up to 150 Mbps

Concurrent connections 600,000 200,000

Connections established per second 20,000 6,000

Default number of supported UDP Flows 25,000 10,000

Su

nsp 81 best practices guide reve en-us

Documents