NSP 83 Best Practices Guide Reve En-Us PDF

Best Practices Guide
Revision E
McAfee Network Security Platform 8.3

COPYRIGHT
2016 Intel Corporation
TRADEMARK ATTRIBUTIONS
Intel 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 Agreement
NOTICE 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.3 Best Practices Guide

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 Hardening the MySQL installation for Windows platform 15

Harden the MySQL installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Remove test database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Remove local anonymous users . . . . . . . . . . . . . . . . . . . . . . . . . 15
Remove remote anonymous users . . . . . . . . . . . . . . . . . . . . . . . . 16
Secure MySQL remote access . . . . . . . . . . . . . . . . . . . . . . . . . . 16
How to roll back your changes . . . . . . . . . . . . . . . . . . . . . . . . . 17
Removal of debug shell at port 9001 . . . . . . . . . . . . . . . . . . . . . . . 17
Other best practices for securing Manager . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Large Sensor deployments 19

Staging Sensors prior to deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Recommendations for large Sensor deployment . . . . . . . . . . . . . . . . . . . . . 20
6 Using active fail-open kits 21

Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7 Effective policy tuning practices 23

Analyzing high-volume attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Managing ignore rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Learning profiles in DoS attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8 Response management 25
Sensor response actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
McAfee Network Security Platform 8.3 Best Practices Guide 3

Contents
9 How to create rule sets 27

Best methods for rule set creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10 Working with firewall policies 29
11 How to handle asymmetric networks 31
12 SSL best practices 33

SSL only traffic throughput: M-series Sensors . . . . . . . . . . . . . . . . . . . . . 33
SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors . . . . . . . . . . . . . . . . . . 33
SSL only traffic - throughput: NS-series Sensors . . . . . . . . . . . . . . . . . . . . . 35
SSL traffic mixed with HTTP 1.1 traffic: NS-series Sensors . . . . . . . . . . . . . . . . . 36
13 Sensor HTTP response processing deployment 39

Tests for enabling HTTP response traffic . . . . . . . . . . . . . . . . . . . . . . . . 39
HTTP response processing results for M-series Sensors . . . . . . . . . . . . . . . 40
HTTP response processing results for Virtual IPS Sensor . . . . . . . . . . . . . . . 41
HTTP response processing results for NS-series Sensors . . . . . . . . . . . . . . . 41
14 Sensor performance with Layer 7 Data Collection 43
15 I-series Sensor capacity by model number 49
16 M-series Sensor capacity by model number 51
17 NS-series Sensor capacity by model number 55
18 Virtual IPS Sensor capacity by model number 61
19 Comparison between I-1200/I-1400 and M-1250/M-1450 FE ports 65
Index 67

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 guide

This information describes the guide's target audience, the typographical conventions and icons used
in this guide, and how the guide is organized.
Audience
McAfee 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.
Conventions
This guide uses these typographical conventions and icons.
Italic Title of a book, chapter, or topic; a new term; emphasis

Bold Text that is emphasized
Monospace Commands and other text that the user types; a code sample; a displayed message
Narrow Bold Words from the product interface like options, menus, buttons, and dialog boxes
Hypertext blue A link to a topic or to an external website
Note: Extra information to emphasize a point, remind the reader of something, or
provide an alternative method
Tip: Best practice information
Caution: Important advice to protect your computer system, software installation,

network, business, or data
Warning: Critical advice to prevent bodily harm when using a hardware product

Preface

On the ServicePortal, you can find information about a released product, including product
documentation, technical articles, and more.
Task
1 Go to the ServicePortal at https://support.mcafee.com and click the Knowledge Center tab.
2 In the Knowledge Base pane under Content Source, click Product Documentation.
3 Select a product and version, then click Search to display a list of documents.

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
Introduction
Pre-installation checklist

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 private
network 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
Cabling best practices

3 Hardening the Manager Server for
Windows 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
Hardening the Manager Server for Windows platform
Post-installation
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 services

Disable 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 policies

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

3
Post-installation
Set user policies

Make 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-bit Sensor to Manager
certificates.
8510 Bulk file transfer channel for 1024-bit Sensor to Manager
certificates.
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

3
Post-installation
Configure audit events

Set 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)

4 Hardening the MySQL installation for
Windows platform
This section describes methods for hardening your MySQL installation.
Contents
Harden the MySQL installation
Other best practices for securing Manager

Ensure the cmd window used for making changes to database tables in the "mysql" database stays
opened in the mysql shell until validation is completed.
This is necessary to enable you to rollback the changes in case you need to. Rollback procedures are
shown at the end of this section.
Use another cmd window, where necessary, to validate hardening changes you have made.
Remove test database

Remove the 'test" database from the server.
1. Start My SQL. mysql> use mysql;

2. Backup db table to do dbbackup before changing it. mysql> create table db_backup as
select * from db;
3. Validate that the backup table was created and row count mysql> select count(*) from
matches that of the mysql.db table. db_backup;
4. Check all the databases on the Manager server. mysql> show databases;
5. Remove the test db. mysql> drop database test;
6. The test database should no longer be listed. mysql> show databases;
Remove local anonymous users

To remove local anonymous users:
1. Look for blank entries for user. mysql> select host,db,user

from db;
2. Remove anonymous access to databases mysql> update db set
host="localhost" where
user="";

4
Hardening the MySQL installation for Windows platform
3. Remove anonymous/blank accounts mysql> flush privileges;

4. Validate that "localhost" replaced % entry under the host
column. You will also notice you will now need to qualify
username and password on the local machine to get into mysql
shell from the mysql.exe CLI.
Remove remote anonymous users

To remove remote anonymous users, you harden mysql.exe CLI access by forcing the requirement for
a username and password to get into the mysql shell as follows.
Start MySQL. mysql> use mysql;

Back up the user table to user_backup before mysql> create table user_backup as
changing it. select * from user;
Validate that the backup table was created and row mysql> select count(*) from
count matches that of the mysql.db table. user_backup;
List all users and hosts. mysql> select user,host from user;
Remove anonymous/blank accounts. mysql> delete from user where user="";
Validate that rows with blank user columns have been mysql> select user,host from user;
removed.
Secure MySQL remote access

This section provides two options for removing remote access.
Remove individual users' remote access
Remove ALL remote access (Recommended)
Removal of individual user's remote access

Do ONE of the following:
Remove admin (Network Security Platform user) remote access

mysql> delete from user where host!='localhost' and user='admin';
(The admin user cannot login remotely; however Manager root can. Use second cmd window to
validate.)
mysql>flush privileges;
Remove root remote access (Recommended minimum action)

mysql> delete from user where host!='localhost' and user='root';
This ensures that the root user cannot login remotely; however Manager user can log in remotely.
Use second cmd window to validate.
mysql>flush privileges;
Remove ALL remote access

mysql> delete from user where host!='localhost'.
ALL user access is disabled including Manager users from remote host(s).

4
Use another cmd window to validate; you can ONLY log in to the MySQL CLI on the Manager server by
qualifying username, password and db. For example: mysql -uadmin -pXXX lf.
How to roll back your changes

If you need to roll back your changes, use the following commands:
To roll back changes made to the mysql.db table from the mysql.db_backup table:
mysql> rename table db to db_1;
mysql> alter table db_backup engine=MyISAM;
mysql> rename table db_backup to db;
mysql> flush privileges;
To roll back changes made to the "mysql.user" table from mysql.user_backup table:
mysql> rename table user to user_1
mysql> rename table user_backup to user;
mysql> flush privileges;
Removal of debug shell at port 9001

In addition to denying traffic over port 9001 and 9002 (as per Install a desktop firewall), the
debugging shell that runs on port 9001 can be disabled by modifying the value of the
iv.policymgmt.RuleEngine.BSH_Diagnostics_Port record in the iv_emspropertiestable. To disable the port, set the
value in the field called "value" = -1

4

Use a clean, dedicated machine for the Manager server and perform a fresh install of the Manager
software, including the installation of the embedded MySQL database. No other software should be
installed on the server, with the exception of a host-based firewall as described above.
Make sure the PC is in an isolated, physically secure environment
Disallow access to the installation directory and its sub-directories to anyone other than authorized
administrators. Use Microsoft Knowledge Base article # 324067 to accomplish this procedure.
Disallow the following permissions:
Read Modify
Write List folder contents
Read and Write Full control

5 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 resource
names 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.

5
Large Sensor deployments
Staging Sensors prior to deployment
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 system
simultaneously.
Contents
Recommendations for large Sensor 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.

6 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 between
the 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

6
Using active fail-open kits
Considerations
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 does
not 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.

7 Effective policy tuning practices
All Network Security Sensors (Sensors) on initial deployment, have the ' Default Prevention' policy
loaded on all interfaces. McAfee recommends that you use the Default Prevention 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 ignore rules
Learning profiles in DoS attacks
Analyzing high-volume attacks

Take attacks that are generating the most alerts (use the Attack Log page) and investigate their
legitimacy. For more information, see 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 ignore rules

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 ignore rule 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.

7
Effective policy tuning practices
Consider the McAfee Vulnerability Manager. When McAfee Vulnerability Manager scans a network host,
some of this traffic might appear as an attack. However, you are aware of the purpose of this traffic
and you do not want the Sensor to take any response action on this traffic. However, if similar traffic is
generated by any other server, you want the Sensor to treat it as an attack and respond accordingly.
Network Security Platform provides various options to handle such situations.
Every ignore rule 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 Configuration Report section can be
used to assist the documentation process. The Performance Monitoring - Sensor Configuration report will deliver
reports that list ignore rules that have been applied and attacks that have been otherwise customized.
For more information, see chapter How to create Ignore rules for an applied IPS policy in the McAfee
Network Security Platform IPS Administration Guide.

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 (for
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 significant
sudden 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.

8 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 be
protected 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.

8
Response management
Sensor response actions
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 Network
Security 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.

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

9
How to create rule sets
Best methods for rule set creation

10 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

10
Working with firewall policies

11 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 without
requiring 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 visible
to 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.

11
How to handle asymmetric networks
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.

12 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 Ignore rules.
Refer to the following sections for the SSL throughput measurements and test methodologies.
SSL decryption feature is not supported on Virtual Sensors such as NS3200, NS3100, IPS-VM600,
IPS-VM100, and IPS-VM100-VSS.
Contents
SSL only traffic throughput: M-series Sensors
SSL traffic mixed with HTTP 1.1 traffic: M-series Sensors
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

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
M-8000 M-6050 M-4050 M-3050 M-2950 M-2850/

M-2750
Max. SSL Connections / 8500 4500 2700 1300 750 550
Sec.
Throughput (Mbps) - 1024 3.8 Gbps 2 Gbps 1200 Mbps 600 Mbps 400 Mbps 250 Mbps
bit key length
Throughput (Mbps) - 2048 1.2 Gbps 600 Mbps 550 Mbps 320 Mbps 320 Mbps 200 Mbps
bit key length

128-bit ARC4

12
SSL best practices
M-8000
1024 bit key length 2048 bit key length

Max. SSL Connections / Sec. 1750 1750
SSL Throughput 800 Mbps 700 Mbps
HTTP 1.1 Throughput 8 Gbps 7.9 Gbps
Total Throughput 8.8 Gbps 8.6 Gbps
M-6050

HTTP 1.1 Throughput 4 Gbps 3.9 Gbps
M-4050

HTTP 1.1 Throughput 2.5 Gbps 2.5 Gbps
M-3050

M-2950

HTTP 1.1 Throughput 900 Mbps 900 Mbps
Total Throughput 980 Mbps 960 Mbps
M-2850/M-2750

SSL Throughput 50 Mbps 40Mbps

12
SSL best practices

128-bit ARC4
NS9300

SSL Throughput 20 Gbps 12 Gbps
NS9200

NS9100

SSL Throughput 8 Gbps 5.5 Gbps
NS7300

NS7200

NS7100

SSL Throughput 1.5 Gbps 1.5 Gbps
NS5200

Max. SSL Connections / Sec. 2,000 2,000
NS5100

12
SSL best practices


128-bit ARC4
NS 9300

HTTP 1.1 Throughput 36 Gbps 36 Gbps
Total Throughput 40 Gbps 40 Gbps
NS 9200

NS 9100

NS 7300

NS 7200


12
SSL best practices

NS 7100

NS5200

NS5100


12
SSL best practices

13 Sensor HTTP response processing
deployment
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 response
processing 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 <=
1/10th of the response size, the combined HTTP request and response traffic processed by Sensors
in real deployments is typically less than that shown in the tests.

13
Sensor HTTP response processing deployment
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 trusted
servers, 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 M-series Sensors

Refer to the following table for M-series Sensor performance numbers with HTTP response processing:
Model No. HTTP Response Scanning Disabled HTTP Response Scanning Enabled for
outbound direction
5 HTTP 1.1 get page requests per TCP 5 HTTP 1.1 get page requests per TCP
connection with a 10K response each connection with a 10K response each
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

13
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 HTTP Response Scanning Enabled

Disabled for outbound direction
5 HTTP 1.1 get page requests per 5 HTTP 1.1 get page requests per
TCP connection with a 10K TCP connection with a 10K response
response each each
IPS-VM600 (VMware ESX) 600 Mbps 600 Mbps
IPS-VM100 (VMware ESX) 100 Mbps 100 Mbps
IPS-VM600 (KVM) 600 Mbps 600 Mbps
IPS-VM100 (KVM) 100 Mbps 100 Mbps
IPS-VM100-VSS 100 Mbps 100 Mbps
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

NS9300 40 Gbps
NS9200 20 Gbps
NS9100 10 Gbps
NS7300 5 Gbps
NS7200 3 Gbps
NS7100 1.5 Gbps
NS5200 1 Gbps
NS5100 600 Mbps
NS3200 200 Mbps
NS3100 100 Mbps
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.

13

14 Sensor performance with Layer 7 Data
Collection
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
Since the default value of L7 data collection is set to 20% of all traffic, the number of flows decreases
by approximately 15%.
Table 14-1 NS9x00 performance details with respect to Layer 7 Data Collection
Sensor Model Layer 7 Data Collection setting HTTP Response Observed throughput
Scanning setting
NS9300 Disabled Disabled 40 Gbps
Enabled for outbound 40 Gbps
direction
Percentage of flows that capture Disabled 40 Gbps
L7 data: 5
direction
L7 data: 100
direction
direction
L7 data: 5

14
Sensor performance with Layer 7 Data Collection
Table 14-1 NS9x00 performance details with respect to Layer 7 Data Collection (continued)
Scanning setting
direction
L7 data: 100
direction
direction
L7 data: 5
direction
L7 data: 100
direction
Scanning setting
direction
L7 data: 5
direction
L7 data: 100
direction
direction
L7 data: 5
direction
L7 data: 100
direction
Enabled for outbound 1.5 Gbps
direction
L7 data: 5
direction
L7 data: 100
direction

14
Scanning setting
direction
L7 data: 5
direction
L7 data: 100
direction
NS5100 Disabled Disabled 600 Mbps
Enabled for outbound 600 Mbps
direction
Percentage of flows that capture Disabled 600 Mbps
L7 data: 5
direction
L7 data: 100
direction
Scanning setting
direction
L7 data: 5
direction
L7 data: 100
direction
direction
L7 data: 5
direction
L7 data: 100
direction

14
Virtual IPS Sensor performance with Layer 7 Data Collection

Table 14-5 Sensor performance details with respect to Layer 7 Data Collection
Sensor model Layer 7 Data Collection HTTP Response Observed
setting Scanning setting throughput
IPS-VM600 (VMware Disabled Disabled 600 Mbps
ESX)
Enabled for 500 Mbps
outbound direction
Percentage of flows that Disabled 600 Mbps
capture L7 data: 5
outbound direction
capture L7 data: 100
outbound direction
IPS-VM100 (VMware Disabled Disabled 100 Mbps
ESX)
outbound direction
capture L7 data: 5
Enabled for 90 Mbps
outbound direction
Enabled for 85 Mbps
outbound direction
IPS-VM600 (KVM) Disabled Disabled 600 Mbps
outbound direction
capture L7 data: 5
outbound direction
Enabled for 85 Mbps
outbound direction
IPS-VM100 (KVM) Disabled Disabled 100 Mbps
outbound direction
capture L7 data: 5
Enabled for 90 Mbps
outbound direction
Enabled for 85 Mbps
outbound direction
IPS-VM100-VSS Disabled Disabled 100 Mbps
outbound direction
capture L7 data: 5
Enabled for 90 Mbps
outbound direction

14
Table 14-5 Sensor performance details with respect to Layer 7 Data Collection (continued)
Sensor model Layer 7 Data Collection HTTP Response Observed
setting Scanning setting throughput
Enabled for 85 Mbps
outbound direction
M-series Sensor performance with Layer 7 Data Collection

Table 14-6 Sensor performance details with respect to Layer 7 Data Collection
Sensor model Layer 7 Data Collection setting HTTP Response Observed
Scanning setting throughput
M-8000 Disabled Disabled 10 Gbps
direction
L7 data: 5
direction
Percentage of flows that capture Disabled 8.7 Gbps
L7 data: 100
direction
direction
L7 data: 5
direction
L7 data: 100
direction
direction
L7 data: 5
direction
L7 data: 100
direction
M-3050 Disabled Disabled 1.5 Gbps
direction
L7 data: 5
direction
L7 data: 100

14
Table 14-6 Sensor performance details with respect to Layer 7 Data Collection (continued)
Sensor model Layer 7 Data Collection setting HTTP Response Observed
Scanning setting throughput
direction
direction
L7 data: 5
direction
L7 data: 100
direction
M-2850, Disabled Disabled 600 Mbps
M-2750
direction
L7 data: 5
direction
L7 data: 100
direction
M-1450 Disabled Disabled 200 Mbps
direction
L7 data: 5
direction
L7 data: 100
direction
M-1250 Disabled Disabled 100 Mbps
direction
L7 data: 5
direction
L7 data: 100
direction

15 I-series Sensor capacity by model
number
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 be 64 64 64 64 NA NA
stored on the Sensor
Virtual Interfaces (VIDS) per 1,000 1,000 1,000 100 32 16
Sensor
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 100,000 100,000 100,000 100,000 40,000 20,000
See the note below on how the
number of customized attacks is
affected.
Ignore rules 131,072 131,072 131,072 65,535 32,000 20,000

Number of attacks with ignore rules 128,000 128,000 128,000 64,000 20,000 16,000
Default number of supported UDP 100,000 100,000 50,000 25,000 10,000 5,000
Flows
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 per 1,000,000 1,000,000 500,000 250,000 64,000 83,000
second)
Effective (Firewall) Access Rules 1,000 1,000 1,000 400 100 50
(refer to note below)
For more information on computing Effective Access Rules, see IPS Administration Guide.
Note for customized attacks
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.

15
I-series Sensor capacity by model number
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 " Default Testing rule set".
You see that:
The File Server rule set has 166 exploit attacks.
The Default Testing rule set has 2204 exploit attacks.
The total number of customized attacks for this policy is 2204 116 = 2038 customized attacks.

16 M-series Sensor capacity by model
number
Maximum M-8000 M-6050 M-4050 M-3050 M-2950 M-2850/ M-1450 M-1250

Type M-2750
Aggregate 10 Gbps 5 Gbps 3 Gbps 1.5 Gbps 1 Gbps 600 Mbps 200 100
Performance Mbps Mbps
Maximum Up to 20 Up to 10 Up to 4 Up to 2.5 Up to Up to 1 Up to Up to
throughput Gbps Gbps Gbps Gbps 1.5 Gbps 300 150
with test Gbps Mbps Mbps
equipment
sending UDP
packet size of
1518 bytes
Concurrent 5,000,000 2,500,000 2,000,000 1,000,000 750,000 750,000 80,000 40,000
connections
Connections 120,000 60,000 36,000 18,000 15,000 10,000 4,000 2,000
established per
sec.
Default number 100,000 100,000 100,000 50,000 50,000 25,000 10,000 5,000
of supported
UDP Flows
Supported UDP 3,000,000 1,500,000 750,000 375,000 375,000 187,500 60,000 30,000
Flows
Latency < 100 < 100 < 100 < 100 < 100 < 100 < 100 < 100
(Average UDP micro micro micro micro micro micro micro micro
per packet seconds seconds seconds seconds seconds seconds seconds seconds
Latency)
SSL Flow count 400,000 200,000 150,000 75,000 25,000 25,000 NA NA

Number of SSL 256 256 256 256 256 256 NA NA
certificates that
can be
imported into
the Sensor
Quarantine 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000
rules per
Sensor- IPv4
Quarantine 500 500 500 500 500 500 500 500
rules per
Sensor- IPv6
Quarantine 50 50 50 50 50 50 50 50
Zones per
Sensor

16
M-series Sensor capacity by model number

Type M-2750
Quarantine 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000
Zone ACLs per
Sensor
Virtual 1,000 1,000 1,000 1,000 1,000 100 32 32
Interfaces
(VIDS) per
Sensor
VLAN / CIDR 3,000 3,000 3,000 3,000 300 300 64 32
Blocks per
Sensor
VLAN / CIDR 254 254 254 254 254 254 64 32
Blocks per
Interface
Customized 100,000 100,000 100,000 100,000 100,000 100,000 40,000 20,000
attacks
See the note
below on how
the number of
customized
attacks is
affected.
Ignore rules 262,144 262,144 262,144 262,144 131,072 131,072 65,536 32,768
Number of 128,000 128,000 100,000 100,000 100,000 100,000 40,000 20,000
attacks with
ignore rules
DoS Profiles 5,000 5,000 5,000 5,000 5,000 300 120 100
SYN cookie rate 5,000,000 2,500,000 2,000,000 1,500,000 800,000 600,000 250,000 200,000
(64-byte
packets per
second)
Effective 10,000 5,000 3,000 3,000 2,000 2,000 1,000 1,000
(Firewall)access
rules
Firewall rule 70,000 35,000 21,000 21,000 14,000 14,000 7,000 7,000
objects
Firewall DNS 2,500 1,250 1,000 1,000 750 750 500 500
rule objects
Firewall rule 500 400 300 300 200 200 100 100
object groups
Application on 1,000 500 500 500 250 250 150 150
Custom Port
rule objects
Firewall 2,500 1,250 1,000 1,000 750 750 500 500
user-based rule
objects
Firewall user 10,000 10,000 10,000 10,000 10,000 10,000 10,000 10,000
groups in
access rules
Number of 128 128 128 128 64 64 32 32
whitelist entries
permitted for IP
Reputation

16

Type M-2750
Maximum host 256,000 256,000 256,000 256,000 256,000 256,000 128,000 128,000
entries
supported for
Connection
Limiting
policies
Maximum file 100 MB 100 MB 100 MB 100 MB 58 MB 58 MB 40 MB 40 MB
size during
packet capture
Passive device 100,000 100,000 50,000 25,000 15,000 15,000 10,000 5,000
profile limits
Advanced 50 50 50 50 32 32 16 16
Malware -
Maximum
simultaneous
file scan
capacity when
the file is saved
in the Sensor
See the note
below for more
information.
Advanced 1,024 1,024 1,024 1,024 1,024 1,024 255 255

Malware -
Maximum
simultaneous
file scan
capacity
without saving
files in the
Sensor
See the note
below for more
information.
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.
Note for Advanced Malware - Maximum simultaneous file scan

This feature is not the same as the file saving feature that is enabled through the Save File checkbox in
the Advanced Malware Policies page of the Manager. It mentions the aspect of file saving that occurs
temporarily within the Sensor during analysis. If the analysis result matches the severity configured in
the Manager then the file is sent to the Manager to save.

16
Different outcomes based on your file saving configuration in the Advanced Malware Policies page are
below:
If you have set the Save File to Disable in the Advanced Malware Policies page then the scanned files are
not sent to the Manager.
If you have set the Save File to Always, then all the scanned files are sent to the Manager to be
archived. Before using this option ensure that you have adequate disk space.
If you have set a severity for Save File, then the scanned files are saved in the Sensor so that they
can be analyzed by internal scanning engines like the PDF- JavaScript Engine. Once the analysis is
complete and if the result is same or higher than the severity set then the file is sent to the
Manager. When the Manager receives the file then it is saved in the Manager for future analysis by
a security administrator.

1 Create a policy.
You see that:

17 NS-series Sensor capacity by model
number
The following table describes the supported NS9x00 and NS7x00 Sensor capacity:
Maximum Type NS9300 NS9200 NS9100 NS7300 NS7200 NS7100

Aggregate 40 Gbps 20 Gbps 10 Gbps 5 Gbps 3 Gbps 1.5 Gbps
Performance
Max Throughput up to 70 up to 35 up to 30 up to 15 up to 10 up to 5
with test Gbps Gbps Gbps Gbps Gbps Gbps
equipment
sending UDP
packet size of
1512 Bytes
Concurrent 32,000,000 16,000,000 13,000,000 10,000,000 5,000,000 3,000,000
Connections
Connections 1,000,000 575,000 450,000 225,000 200,000 135,000
established per
second
Default number of 800,000 400,000 300,000 150,000 150,000 150,000
supported UDP
Flows
Supported UDP 12,000,000 6,000,000 6,000,000 3,000,000 3,000,000 3,000,000
Flows maximum
Supported UDP 1,000 1,000 1,000 1,000 1,000 1,000
Flows minimum
Latency <100 s <100 s <100 s <100 s <100 s <100 s
(Average UDP per
packet Latency)
SSL Flow Count 3,200,000 1,600,000 1,200,000 500,000 400,000 250,000

Number of SSL 1,024 1,024 1,024 1,024 1,024 1,024
certificates that
can be imported
into the Sensor
Throughput with 40 Gbps 20 Gbps 10 Gbps 5 Gbps 3 Gbps 1.5 Gbps
SSL Decryption
(based on 10%
SSL traffic)
Quarantine rules 8,000 8,000 8,000 8,000 8,000 8,000
per Sensor- IPv4
Quarantine rules 500 500 500 500 500 500
per Sensor- IPv6

17
NS-series Sensor capacity by model number

Quarantine Zones 50 50 50 50 50 50
per Sensor
Quarantine Zone 1,000 1,000 1,000 1,000 1,000 1,000
ACLs per Sensor
Virtual Interfaces 1,000 1,000 1,000 1,000 1,000 1,000
(VIDS) per Sensor
(Number of Virtual
IPS Systems)
VLAN / CIDR 3,000 3,000 3,000 3,000 3,000 3,000
Blocks per Sensor
VLAN / CIDR 254 254 254 254 254 254
Blocks per
Interface
Customized 100,000 100,000 100,000 100,000 100,000 100,000
attacks
See the note
below on how the
number of
customized
attacks is
affected.
Ignore rules 262,144 262,144 262,144 262,144 262,144 262,144

Number of attacks 128,000 128,000 128,000 128,000 128,000 128,000
with ignore rules
DoS Profiles 5,000 5,000 5,000 5,000 5,000 5,000
SYN cookie rate 13,500,000 9,000,000 5,000,000 3,300,000 1,800,000 1,400,000
(64 byte packets
per second)
Effective (Firewall) 20,000 20,000 10,000 5,000 3,000 3,000
access rules
Firewall rule 140,000 140,000 70,000 35,000 21,000 21,000
objects
Firewall DNS rule 5,000 5,000 2,500 1,250 1,000 1,000
objects
Firewall rule 1,000 1,000 500 400 300 300
object groups
Application on 2,000 2,000 1,000 500 500 500
Custom Port rule
objects
Firewall 5,000 5,000 2,500 1,250 1,000 1,000
user-based rule
objects
Firewall user 10,000 10,000 10,000 10,000 10,000 10,000
groups in access
rules
Number of 128 128 128 128 128 128
whitelist entries
permitted for IP
Reputation

17

Maximum host 256,000 256,000 256,000 256,000 256,000 256,000
entries supported
for Connection
Limiting policies
Maximum file size 100 MB 100 MB 100 MB 100 MB 100 MB 100 MB
during packet
capture
Passive device 100,000 100,000 100,000 100,000 50,000 25,000
profile limits
Advanced 1,000 1,000 1,000 1,000 1,000 1,000
Malware -
Maximum
simultaneous file
scan capacity
when the file is
saved in the
Sensor
See the note
below for more
information.
Advanced 4,094 4,094 4,094 4,094 4,094 4,094

Malware -
Maximum
simultaneous file
scan capacity
without saving
files in the Sensor
See the note
below for more
information.
New HTTP 700,000 375,000 260,000 135,000 128,000 115,000

connections per
second(using 1
GET with 5000
HTTP response)
The following table describes the supported NS5x00 and NS3x00 Sensor capacity:
Maximum Type NS5200 NS5100 NS3200 NS3100

Aggregate Performance 1 Gbps 600 Mbps 200 Mbps 100 Mbps
Max Throughput with test equipment up to 3 Gbps up to 1.5 Gbps up to 1 Gbps up to 600
sending UDP packet size of 1512 Bytes Mbps
Concurrent Connections 1,350,000 750,000 80,000 40,000
Connections established per second 45,000 40,000 25,000 20,000
Default number of supported UDP Flows 50,000 25,000 10,000 5,000
Supported UDP Flows maximum 1,500,000 1,500,000 30,000 30,000
Supported UDP Flows minimum 1,000 1,000 1,000 1,000
Latency <100 s <100 s <100 s <100 s
(Average UDP per packet Latency)
SSL Flow Count 75,000 40,000 NA NA

Number of SSL certificates that can be 1,024 1,024 NA NA
imported into the Sensor

17
Maximum Type NS5200 NS5100 NS3200 NS3100

Throughput with SSL Decryption (based 1 Gbps 600 Mbps NA NA
on 10% SSL traffic)
Quarantine rules per Sensor- IPv4 8,000 8,000 8,000 8,000
Quarantine rules per Sensor- IPv6 500 500 500 500
Quarantine Zones per Sensor 50 50 50 50
Quarantine Zone ACLs per Sensor 1,000 1,000 1,000 1,000
Virtual Interfaces (VIDS) per Sensor 1,000 100 32 16
(Number of Virtual IPS Systems)
VLAN / CIDR Blocks per Sensor 300 300 64 32
VLAN / CIDR Blocks per Interface 254 254 64 32
Customized attacks 100,000 100,000 100,000 100,000
See the note below on how the number
of customized attacks is affected.
Ignore rules 262,144 262,144 65,536 32,768

Number of attacks with ignore rules 100,000 100,000 40,000 20,000
DoS Profiles 5,000 300 128 128
SYN cookie rate (64 byte packets per 1,000,000 750,000 400,000 300,000
second)
Effective (Firewall) access rules 2,000 2,000 1,000 1,000
Firewall rule objects 14,000 14,000 7,000 7,000
Firewall DNS rule objects 750 750 500 500
Firewall rule object groups 200 200 100 100
Application on Custom Port rule objects 250 250 150 150
Firewall user-based rule objects 750 750 500 500
Firewall user groups in access rules 10,000 10,000 10,000 10,000
Number of whitelist entries permitted 64 64 32 32
for IP Reputation
Maximum host entries supported for 128,000 128,000 128,000 128,000
Connection Limiting policies
Maximum file size during packet capture 58 MB 58 MB 40 MB 40 MB
Passive device profile limits 15,000 15,000 10,000 5,000
Advanced Malware - Maximum 32 32 16 16
simultaneous file scan capacity when
the file is saved in the Sensor
See the note below for more
information.
Advanced Malware - Maximum 1,024 1,024 255 255

simultaneous file scan capacity without
saving files in the Sensor
See the note below for more
information.
New HTTP connections per second(using 30,000 25,000 15,000 12,000

1 GET with 5000 HTTP response)

17

below:

1 Create a policy.
You see that:

17

18 Virtual IPS Sensor capacity by model
number
The following table describes the supported Virtual IPS Sensor capacity.
Table 18-1 Virtual IPS Sensor capacity by model number

Maximum Type VMware ESX KVM VMware NSX
IPS-VM600 IPS-VM100 IPS-VM600 IPS-VM100 IPS-VM100-VSS
Aggregate 600 Mbps 100 Mbps 600 Mbps 100 Mbps 100 Mbps
Performance
Maximum Up to 1 Gbps Up to 150 Up to 1 Gbps Up to 150 Up to 150 Mbps
throughput with Mbps Mbps
test equipment
sending UDP
packet size of
1518 bytes
Concurrent 600,000 200,000 600,000 200,000 200,000
connections
Connections 20,000 6,000 20,000 6,000 6,000
established per
second
Default number of 25,000 10,000 25,000 10,000 10,000
supported UDP
Flows
Supported UDP 254,208 39,168 254,208 39,168 39,168
Flows
Latency < 100 micro < 100 micro < 100 micro < 100 micro < 100 micro
(Average UDP per seconds seconds seconds seconds seconds
packet Latency)
SSL Flow count NA NA NA NA NA

Number of SSL NA NA NA NA NA
certificates that
can be imported
into the Sensor
Throughput with NA NA NA NA NA
SSL Decryption
(based on 10%
SSL traffic)
Quarantine rules 1,000 1,000 1,000 1,000 1,000
per Sensor - IPv4
Quarantine rules 500 500 500 500 500
per Sensor - IPv6

18
Virtual IPS Sensor capacity by model number
Table 18-1 Virtual IPS Sensor capacity by model number (continued)

Quarantine Zones 50 50 50 50 50
per Sensor
Quarantine Zone 1,000 1,000 1,000 1,000 1,000
ACLs per Sensor
Virtual Interfaces 100 32 100 32 32
(VIDS) per Sensor
VLAN / CIDR 300 32 300 32 32
Blocks per Sensor
VLAN / CIDR 254 32 254 32 32
Blocks per
Interface
Customized 100,000 20,000 100,000 20,000 20,000
attacks
See the note
below on how the
number of
customized
attacks is
affected.
Ignore rules 131,072 32,768 131,072 32,768 32,768

Number of attacks 100,000 20,000 100,000 20,000 20,000
with ignore rules
DoS Profiles 300 100 300 100 100
SYN cookie rate 600,000 200,000 600,000 200,000 200,000
(64-byte packets
per second)
Effective (Firewall) 2,000 1,000 2,000 1,000 1,000
access rules
Firewall rule 14,000 7,000 14,000 7,000 7,000
objects
Firewall DNS rule 750 500 750 500 500
objects
Firewall rule 200 100 200 100 100
object groups
Application on 250 150 250 150 150
Custom Port rule
objects
Firewall 750 500 750 500 500
user-based rule
objects
Firewall user 2,000 2,000 2,000 2,000 2,000
groups in access
rules
Number of 64 32 64 32 32
whitelist entries
permitted for IP
Reputation

18
Table 18-1 Virtual IPS Sensor capacity by model number (continued)

Maximum host 128,000 55,000 128,000 55,000 55,000
entries supported
for Connection
Limiting policies
Passive device 15,000 10,000 15,000 10,000 10,000
profile limits
Advanced 32 16 32 16 16
Malware -
Maximum
simultaneous file
scan capacity
when the file is
saved in the
Sensor
See the note
below for more
information.
Advanced 1,024 255 1,024 255 255

Malware -
Maximum
simultaneous file
scan capacity
without saving
files in the Sensor
See the note
below for more
information.

below:

18

1 Create a policy.
You see that:

19 Comparison between I-1200/I-1400 and
M-1250/M-1450 FE ports
Operating Condition/Mode I-1200/I-1400 M-1250/M-1450

TAP Internal and external tap are External tap is supported; no
supported. No negotiation with support for internal tap. No
peer devices. negotiation with peer devices.
SPAN Dongles required Dongles not required
Inline fail-close Dongles required on both A and B Dongles not required for both
ports to fail-close ports to fail-close
Inline fail-open (Default) Does not require external passive Does not require external
Fail-open Kit passive Fail-open Kit
Inline fail-open (Active Supported with ports configured in Supported with ports configured
Fail-open Kit) fail-close (no dongles) in fail-close (no dongles)
Link Failure - inline fail-close Ports fail-close and traffic is Ports fail-close and traffic is
disrupted. disrupted.
Link Failure - inline fail-open Ports are not admin disabled and Ports are admin disabled, put
traffic is disrupted into bypass, and no traffic is
disrupted
Port Speed/Duplex 10/100, Full/Half 10/100/1000, Full/Half only for
10/100
Auto negotiation Not supported Supported and can be configured
from the Manager
Sensor Power off - inline Ports fail-close with dongles Ports fail-close and traffic is
fail-close connected; fail-open (bypass) with disrupted.
no dongles
Sensor Power off - inline Ports fail-open (bypass), no traffic Ports fail-open, put into bypass,
fail-open disrupted (must not have dongles and no traffic is disrupted.
connected.)
Warm reboot - inline fail-open Ports are enabled and in the down Ports are admin disabled and put
(CLI reboot or reboot due to state till the Sensor starts in bypass before the Sensor
error and watchdog on) rebooting. Traffic is disrupted till reboots. No traffic is disrupted.
then.
Warm reboot - inline fail-close Ports remain enabled fail-close, Ports remain enabled fail-close,
(CLI reboot or reboot due to traffic disruption till the Sensor is traffic disruption till the Sensor
error and watchdog on) up is up
Resetconfig Restores to default configuration Options to either restore defaults
(inline fail-open) and reboots or to retain the current port
configuration are available
Port link LED interpretation - Normal is green and indicates up; Green indicates up and inline;
inline fail-open OFF indicates down and not OFF indicates bypass.
necessarily bypass

19
Comparison between I-1200/I-1400 and M-1250/M-1450 FE ports
Operating Condition/Mode I-1200/I-1400 M-1250/M-1450

Port link LED interpretation - OFF indicates down and traffic is OFF indicates down and traffic is
inline fail-close disrupted disrupted
Port link LED interpretation OFF indicates - bypass and no OFF indicates bypass and no
during reboot/Sensor power traffic disrupted. traffic is disrupted
down - inline fail-open
Port link LED interpretation OFF indicates down, traffic is OFF indicates down and traffic
during reboot/Sensor power disrupted. disrupted.
down - inline fail-close
Front panel LED for Normal/ Not present Green indicates up and inline;
Bypass operations - inline OFF indicates bypass.
fail-open
Front panel LED for Normal/ Not present Always on (green), normal
Bypass operations - inline operation.
fail-close
Bypass operations - SPAN operation.
Bypass operations - TAP operation.
Link Events No support to control fail-open/ Has support to control fail-open/
bypass operation bypass operation
Port density I-1200 - 1A/1B, I-1400 - 1A/1B 1A/1B through 4A/4B
and 2A/2B
Auto MDIX support No support(Supported in I1200 and Supported by default (not
not in I1400). Configurable configurable through CLI)
through CLI
The Manager port The color codes are: The color codes are:
configuration panel - link
Yellow- not active Yellow - not active
status color coding
Green - up Green - up
Red - enabled but down Red - enabled but down
Gray - disabled and down Gray - disabled and down
(applicable for inline fail-open
only)
The Manager port config Not present Four separate bypass buttons,
panel - Inline/Bypass status one button per port pair:
color coding
Green - inline
Yellow - bypass
The Manager port status at Red Gray

Link failure - inline fail-open
The Manager port status at Red Red
Link failure - inline fail-close
The Manager port status at Red Red
Link failure - SPAN

Index
A Manager server hardening; (continued)

pre-installation
about this guide 5
Windows 2008 11
active fail-open kits 21
Windows 2012 11
asymmetric networks 31
Windows 2008 11
C Windows 2012 11
McAfee ServicePortal, accessing 6
conventions and icons used in this guide 5
monitoring ports; cabling 9
MySQL installation hardening 15
D
documentation P
audience for this guide 5
policy tuning practices 23
product-specific, finding 6
ports comparison 65
typographical conventions and icons 5
post-installation;
DoS attacks profiles; learning 24
Windows 2008 12
Windows 2012 12
F
pre-installation checklist 7
firewall policies 29
R
H
response management 25, 26
high-volume attacks; analyzing 23 rule sets 27
HTTP response processing deployment 39
HTTP response traffic 39 S
processing results; M-series Sensors 40
Sensor capacity by model number
processing results; Virtual IPS Sensors 41
I-series 49
M-series 51
I Virtual IPS 61
ignore rules 23 ServicePortal, finding product documentation 6
SSL best practices 33
L
T
large Sensor deployments 19, 20
technical support, finding product information 6
M
Manager server hardening 15
Manager server hardening;
installation 11

0E00

NSP 83 Best Practices Guide Reve En-Us PDF

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

NSP 83 Best Practices Guide Reve En-Us PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NSP 83 Best Practices Guide Reve En-Us PDF

Uploaded by

Copyright:

Available Formats

Best Practices Guide

McAfee Network Security Platform 8.3

2 McAfee Network Security Platform 8.3 Best Practices Guide

2 Cabling best practices 9

3 Hardening the Manager Server for Windows platform 11

4 Hardening the MySQL installation for Windows platform 15

5 Large Sensor deployments 19

6 Using active fail-open kits 21

7 Effective policy tuning practices 23

McAfee Network Security Platform 8.3 Best Practices Guide 3

9 How to create rule sets 27

10 Working with firewall policies 29

11 How to handle asymmetric networks 31

12 SSL best practices 33

13 Sensor HTTP response processing deployment 39

14 Sensor performance with Layer 7 Data Collection 43

15 I-series Sensor capacity by model number 49

16 M-series Sensor capacity by model number 51

17 NS-series Sensor capacity by model number 55

18 Virtual IPS Sensor capacity by model number 61

19 Comparison between I-1200/I-1400 and M-1250/M-1450 FE ports 65

4 McAfee Network Security Platform 8.3 Best Practices Guide

About this guide

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

Caution: Important advice to protect your computer system, software installation,

McAfee Network Security Platform 8.3 Best Practices Guide 5

Find product documentation

6 McAfee Network Security Platform 8.3 Best Practices Guide

McAfee Network Security Platform [formerly McAfee IntruShield ] is a combination of network

McAfee Network Security Platform 8.3 Best Practices Guide 7

8 McAfee Network Security Platform 8.3 Best Practices Guide

McAfee Network Security Platform 8.3 Best Practices Guide 9

10 McAfee Network Security Platform 8.3 Best Practices Guide

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

Connect the server on a protected or isolated network.

Install the US version of Windows Server.

Use NTFS on all partitions.

McAfee Network Security Platform 8.3 Best Practices Guide 11

Install a Virus Scanner and update the signatures.

Also keep a check on the following:

Uninstall applications that are not necessary.

Disable non-required services

Remote access auto connection manager

Remote procedure call locator

TCP/IP NetBIOS helper service

Enable these services only if it is absolutely required.

Set system policies

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.

Clear virtual memory page file during shutdown

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

12 McAfee Network Security Platform 8.3 Best Practices Guide

Set user policies

Rename the administrator account.

Disable guest account.

Passwords should be at least 8 ASCII characters.