Mcafee® Network Security Platform

Best Practices Guide
revision 3.0
McAfee® Network Security Platform

version 6.0
McAfee®
Network Protection
Industry-leading network security solutions
COPYRIGHT
Copyright ® 2001 - 2010 McAfee, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into
any language in any form or by any means without the written permission of McAfee, Inc., or its suppliers or affiliate companies.
TRADEMARKS
ACTIVE FIREWALL, ACTIVE SECURITY, ACTIVESECURITY (AND IN KATAKANA), ACTIVESHIELD, CLEAN-UP, DESIGN (STYLIZED E), DESIGN (STYLIZED N),
ENTERCEPT, EPOLICY ORCHESTRATOR, FIRST AID, FOUNDSTONE, GROUPSHIELD, GROUPSHIELD (AND IN KATAKANA), INTRUSHIELD, INTRUSION PREVENTION
THROUGH INNOVATION, McAfee, McAfee (AND IN KATAKANA), McAfee AND DESIGN, McAfee.COM, McAfee VIRUSSCAN, NET TOOLS, NET TOOLS (AND IN KATAKANA),
NETSCAN, NETSHIELD, NUTS & BOLTS, OIL CHANGE, PRIMESUPPORT, SPAMKILLER, THREATSCAN, TOTAL VIRUS DEFENSE, VIREX, VIRUS FORUM, VIRUSCAN,
VIRUSSCAN, VIRUSSCAN (AND IN KATAKANA), WEBSCAN, WEBSHIELD, WEBSHIELD (AND IN KATAKANA) are registered trademarks or trademarks of McAfee, Inc. and/or
its affiliates in the US and/or other countries. The color red in connection with security is distinctive of McAfee brand products. All other registered and unregistered trademarks
herein are the sole property of their respective owners.
LICENSE AND PATENT 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 ACCOMPANIES 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 WEB SITE
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.
License Attributions
This product includes or may include:
* Software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). * Cryptographic software written by Eric A. Young and software written by
Tim J. Hudson. * Some software programs that are licensed (or sublicensed) to the user under the GNU General Public License (GPL) or other similar Free Software licenses
which, among other rights, permit the user to copy, modify and redistribute certain programs, or portions thereof, and have access to the source code. The GPL requires that for
any software covered under the GPL, which is distributed to someone in an executable binary format, that the source code also be made available to those users. For any such
software covered under the GPL, the source code is made available on this CD. If any Free Software licenses require that McAfee provide rights to use, copy or modify a software
program that are broader than the rights granted in this agreement, then such rights shall take precedence over the rights and restrictions herein. * Software originally written by
Henry Spencer, Copyright 1992, 1993, 1994, 1997 Henry Spencer. * Software originally written by Robert Nordier, Copyright (C) 1996-7 Robert Nordier. * Software written by
Douglas W. Sauder. * Software developed by the Apache Software Foundation (http://www.apache.org/). A copy of the license agreement for this software can be found at
www.apache.org/licenses/LICENSE-2.0.txt. * International Components for Unicode ("ICU") Copyright (C) 1995-2002 International Business Machines Corporation and others. *
Software developed by CrystalClear Software, Inc., Copyright (C) 2000 CrystalClear Software, Inc. * FEAD(R) Optimizer(R) technology, Copyright Netopsystems AG, Berlin,
Germany. * Outside In(R) Viewer Technology (C) 1992-2001 Stellent Chicago, Inc. and/or Outside In(R) HTML Export, (C) 2001 Stellent Chicago, Inc. * Software copyrighted by
Thai Open Source Software Center Ltd. and Clark Cooper, (C) 1998, 1999, 2000. * Software copyrighted by Expat maintainers. * Software copyrighted by The Regents of the
University of California, (C) 1996, 1989, 1998-2000. * Software copyrighted by Gunnar Ritter. * Software copyrighted by Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
California 95054, U.S.A., (C) 2003. * Software copyrighted by Gisle Aas. (C) 1995-2003. * Software copyrighted by Michael A. Chase, (C) 1999-2000. * Software copyrighted by
Neil Winton, (C) 1995-1996. * Software copyrighted by RSA Data Security, Inc., (C) 1990-1992. * Software copyrighted by Sean M. Burke, (C) 1999, 2000. * Software copyrighted
by Martijn Koster, (C) 1995. * Software copyrighted by Brad Appleton, (C) 1996-1999. * Software copyrighted by Michael G. Schwern, (C) 2001. * Software copyrighted by Graham
Barr, (C) 1998. * Software copyrighted by Larry Wall and Clark Cooper, (C) 1998-2000. * Software copyrighted by Frodo Looijaard, (C) 1997. * Software copyrighted by the Python
Software Foundation, Copyright (C) 2001, 2002, 2003. A copy of the license agreement for this software can be found at www.python.org. * Software copyrighted by Beman
Dawes, (C) 1994-1999, 2002. * Software written by Andrew Lumsdaine, Lie-Quan Lee, Jeremy G. Siek (C) 1997-2000 University of Notre Dame. * Software copyrighted by Simone
Bordet & Marco Cravero, (C) 2002. * Software copyrighted by Stephen Purcell, (C) 2001. * Software developed by the Indiana University Extreme! Lab
(http://www.extreme.indiana.edu/). * Software copyrighted by International Business Machines Corporation and others, (C) 1995-2003. * Software developed by the University of
California, Berkeley and its contributors. * Software developed by Ralf S. Engelschall <rse@engelschall.com> for use in the mod_ssl project (http:// www.modssl.org/). * Software
copyrighted by Kevlin Henney, (C) 2000-2002. * Software copyrighted by Peter Dimov and Multi Media Ltd. (C) 2001, 2002. * Software copyrighted by David Abrahams, (C) 2001,
2002. See http://www.boost.org/libs/bind/bind.html for documentation. * Software copyrighted by Steve Cleary, Beman Dawes, Howard Hinnant & John Maddock, (C) 2000. *
Software copyrighted by Boost.org, (C) 1999-2002. * Software copyrighted by Nicolai M. Josuttis, (C) 1999. * Software copyrighted by Jeremy Siek, (C) 1999-2001. * Software
copyrighted by Daryle Walker, (C) 2001. * Software copyrighted by Chuck Allison and Jeremy Siek, (C) 2001, 2002. * Software copyrighted by Samuel Krempp, (C) 2001. See
http://www.boost.org for updates, documentation, and revision history. * Software copyrighted by Doug Gregor (gregod@cs.rpi.edu), (C) 2001, 2002. * Software copyrighted by
Cadenza New Zealand Ltd., (C) 2000. * Software copyrighted by Jens Maurer, (C) 2000, 2001. * Software copyrighted by Jaakko Järvi (jaakko.jarvi@cs.utu.fi), (C) 1999, 2000. *
Software copyrighted by Ronald Garcia, (C) 2002. * Software copyrighted by David Abrahams, Jeremy Siek, and Daryle Walker, (C) 1999-2001. * Software copyrighted by Stephen
Cleary (shammah@voyager.net), (C) 2000. * Software copyrighted by Housemarque Oy <http://www.housemarque.com>, (C) 2001. * Software copyrighted by Paul Moore, (C)
1999. * Software copyrighted by Dr. John Maddock, (C) 1998-2002. * Software copyrighted by Greg Colvin and Beman Dawes, (C) 1998, 1999. * Software copyrighted by Peter
Dimov, (C) 2001, 2002. * Software copyrighted by Jeremy Siek and John R. Bandela, (C) 2001. * Software copyrighted by Joerg Walter and Mathias Koch, (C) 2000-2002. *
Software copyrighted by Carnegie Mellon University (C) 1989, 1991, 1992. * Software copyrighted by Cambridge Broadband Ltd., (C) 2001-2003. * Software copyrighted by
Sparta, Inc., (C) 2003-2004. * Software copyrighted by Cisco, Inc and Information Network Center of Beijing University of Posts and Telecommunications, (C) 2004. * Software
copyrighted by Simon Josefsson, (C) 2003. * Software copyrighted by Thomas Jacob, (C) 2003-2004. * Software copyrighted by Advanced Software Engineering Limited, (C)
2004. * Software copyrighted by Todd C. Miller, (C) 1998. * Software copyrighted by The Regents of the University of California, (C) 1990, 1993, with code derived from software
contributed to Berkeley by Chris Torek.
Issued JUNE 2010 / Best Practices Guide

700-2379-00/ 3.0 - English
Contents
Preface ........................................................................................................... v
Introducing McAfee Network Security Platform............................................................................. v
About this Guide............................................................................................................................ v
Audience .......................................................................................................................................vi
Conventions used in this book ......................................................................................................vi
Related Documentation................................................................................................................vii
Contacting Technical Support ..................................................................................................... viii
Chapter 1 Introduction.................................................................................. 1
Pre-installation checklist................................................................................................................ 1
Chapter 2 Recommended Manager specifications.................................... 2

Manager Server specifications ...................................................................................................... 2
Manager Client specifications ....................................................................................................... 2
Determining your Database Requirements ................................................................................... 3
Chapter 3 Cabling best practices ................................................................ 4
Chapter 4 Large Sensor deployments ........................................................ 5

Staging Sensors prior to deployment ............................................................................................ 6
Recommendations for large Sensor deployment .......................................................................... 6
Chapter 5 Troubleshooting issues with Sensor ........................................ 7
Chapter 6 Configuration of Speed and Duplex settings ........................... 8

Duplex mismatches ....................................................................................................................... 8
Troubleshooting a Duplex Mismatch with Cisco Devices.............................................................. 8
Cisco PIX® Firewall ...............................................................................................................9
Cisco CSS 11000...................................................................................................................9
Cisco Catalyst® 2900XL, 3500XL Series (Hybrid).................................................................9
Cisco Catalyst 4000, 5000, 6000 Series (Native) ..................................................................9
Cisco IOS® for Catalyst 4000, 6000 Series ...........................................................................9
Auto-negotiation issues ................................................................................................................. 9
Situations that may result in Auto-negotiation issues...........................................................10
Valid Auto-negotiation and Speed Configuration settings....................................................10
Explanation of CatOS show port command counters ..........................................................11
Gigabit auto-negotiation (no link to connected device) ........................................................12
Chapter 7 Effective Policy Tuning practices ............................................ 13

Analyzing high-volume attacks.................................................................................................... 13
Managing Attack filters ................................................................................................................ 13
Learning profiles in DoS attacks.................................................................................................. 14
Chapter 8 Response Management ............................................................ 15

Sensor Response Actions ........................................................................................................... 15
Chapter 9 Creating Rule sets ..................................................................... 16
iii
Best methods for rule set creation............................................................................................... 16
Chapter 10 Port clustering on Asymmetric networks ............................. 17
Chapter 11 Access Control Lists (ACLs).................................................. 18
Chapter 12 SSL best practices .................................................................. 19

SSL only traffic - throughput........................................................................................................ 19
SSL only traffic - throughput........................................................................................................ 19
SSL traffic mixed with HTTP 1.1 traffic........................................................................................ 20
Supported SSL functionalities ..................................................................................................... 21
Supported Web servers .......................................................................................................22
Supported cipher suites .......................................................................................................22
SSLv3/TLS cipher suites......................................................................................................22
Unsupported SSL functionalities ................................................................................................. 22
Chapter 13 Sensor HTTP Response Processing deployment................ 23

Tests for enabling HTTP Response Traffic ................................................................................. 23
HTTP Response processing results for I series Sensors.....................................................24
HTTP Response processing results for M-series Sensors ..................................................24
Chapter 14 Database maintenance ........................................................... 26

Backup of data and configurations .............................................................................................. 26
Chapter 15 Alerts and Disk space maintenance ...................................... 28

Archiving alerts............................................................................................................................ 28
Scripts for disk space maintenance............................................................................................. 28
Dbtuning.bat .........................................................................................................................28
Purge.bat..............................................................................................................................29
Using File Maintenance Scheduler.............................................................................................. 29
Chapter 16 Manager Disaster Recovery (MDR) best practices .............. 30
Chapter 17 Performance issues ................................................................ 31

Sniffer trace ................................................................................................................................. 31
Data link errors ............................................................................................................................ 31
Half-duplex setting ...............................................................................................................31
Full-duplex setting ................................................................................................................31
Chapter 18 Vulnerability Assessment....................................................... 32
Chapter 19 I-series Sensor capacity by model number .......................... 33
Chapter 20 M-series Sensor capacity by model number ........................ 35
Chapter 21 Comparison Between I-1200/I-1400 and M-1250/M-1450 FE

ports ............................................................................................................. 37
Index ............................................................................................................. 40
iv
Preface
This preface provides a brief introduction to the product, discusses the information in this
document, and explains how this document is organized. It also provides information such
as, the supporting documents for this guide and how to contact McAfee Technical Support.
Introducing McAfee Network Security Platform

McAfee® Network Security Platform [formerly McAfee® IntruShield®] delivers the most
comprehensive, accurate, and scalable Network Access Control (NAC), network Intrusion
Prevention System (IPS) and Network Threat Behavior Analysis (NTBA) for mission-critical
enterprise, carrier, and service provider networks, while providing unmatched protection
against spyware and known, zero-day, and encrypted attacks.
McAfee® Network Threat Behavior Analysis Appliance provides the capability of monitoring
network traffic by analyzing NetFlow information flowing through the network in real time,
thus complementing the NAC and IPS capabilities in a scenario in which McAfee Network
Security Sensor, NAC Sensor, and NTBA Appliance are installed and managed through a
single Manager.
About this Guide

This guide provides the recommended practices for using Network Security Platform most
effectively.
Best practices are provided for the following topics/issues in Network Security Platform:
• Hardware and software recommendations for Network Security Platform

• Cabling best practices
• Considerations for large McAfee® Network Security Sensor [formerly McAfee®
IntruShield® Sensor] deployments
• Troubleshooting tips for the McAfee Network Security Sensor (Sensor)
• Sensor Deployment issues - speed & duplex settings
• Policy Tuning best practices
• Best Practices for creating Rule sets
• Port clustering on asymmetric networks
• Tips for Access Control Lists (ACLs)
• SSL best practices
• HTTP Response processing deployment for the Sensor
• Database Maintenance
• Alerts & Disk space Maintenance issues
• Manager Disaster Recovery (MDR) pairs
• Performance issues and
• Vulnerability Assessment
v
McAfee® Network Security Platform 6.0 Preface
Audience
This guide is intended for use by network technicians and maintenance personnel
responsible for installing, configuring, and maintaining McAfee® Network Security Manager
[formerly McAfee® IntruShield® Security Manager], but is not necessarily familiar with daily
IPS-related tasks, the relationship between tasks, or the commands necessary to perform
particular tasks.
Conventions used in this book

This document uses the following typographical conventions:
Convention Example
Terms that identify fields, buttons, The Service field on the Properties tab specifies the
tabs, options, selections, and name of the requested service.
commands on the User Interface
(UI) are shown in Arial Narrow bold
font.
Menu or action group selections Select My Company > Admin Domain > Summary.
are indicated using a right angle
bracket.
Procedures are presented as a 1. On the Configuration tab, click Backup.
series of numbered steps.
Names of keys on the keyboard Press ENTER.

are denoted using UPPER CASE.
Text such as syntax, key words, Type: setup and then press ENTER.
and values that you must type
exactly are denoted using
Courier New font.
Variable information that you must Type: Sensor-IP-address and then press
type based on your specific ENTER.
situation or environment is shown
in italics.
Parameters that you must supply set Sensor ip <A.B.C.D>
are shown enclosed in angle
brackets.
Information that you must read Caution:
before beginning a procedure or
that alerts you to negative
consequences of certain actions,
such as loss of data is denoted
using this notation.
vi
Convention Example
Information that you must read to Warning:

prevent injury, accidents from
contact with electricity, or other
serious consequences is denoted
using this notation.
Notes that provide related, but Note:
non-critical, information are
denoted using this notation.
Related Documentation
The following documents and on-line help are companions to this guide. Refer to Quick Tour
for more information on these guides.
• Quick Tour
• Installation Guide
• Upgrade Guide
• Getting Started Guide
• IPS Deployment Guide
• Manager Configuration Basics Guide
• I-1200 Sensor Product Guide
• M-1250/M-1450 Sensor Product Guide
• M-1250/M-1450 Quick Start Guide
• M-2750 Sensor Product Guide
• M-2750 Quick Start Guide
• M-3050/M-4050 Sensor Product Guide
• M-3050/M-4050 Quick Start Guide
• Gigabit Optical Fail-Open Bypass Kit Guide
• Gigabit Copper Fail-Open Bypass Kit Guide
• 10 Gigabit Fail-Open Bypass Kit Guide
• M-8000/M-6050/M-4050/M-3050 Slide Rail Assembly Procedure
• M-2750 Slide Rail Assembly Procedure
• M-series DC Power Supply Installation Procedure
• Administrative Domain Configuration Guide
• Manager Server Configuration Guide
• CLI Guide
vii
• Device Configuration Guide

• IPS Configuration Guide
• NAC Configuration Guide
• Integration Guide
• System Status Monitoring Guide
• Reports Guide
• Custom Attack Definitions Guide
• Central Manager Administrator's Guide
• Troubleshooting Guide
• Special Topics Guide—In-line Sensor Deployment
• Special Topics Guide—Sensor High Availability
• Special Topics Guide—Virtualization
• Special Topics Guide—Denial-of-Service
• NTBA Appliance Administrator's Guide
• NTBA Monitoring Guide
• NTBA Appliance T-200 Quick Start Guide
• NTBA Appliance T-500 Quick Start Guide
Contacting Technical Support

If you have any questions, contact McAfee for assistance:
Online
Contact McAfee Technical Support http://mysupport.mcafee.com.
Registered customers can obtain up-to-date documentation, technical bulletins, and quick
tips on McAfee's 24x7 comprehensive KnowledgeBase. In addition, customers can also
resolve technical issues with the online case submit, software downloads, and signature
updates.
Phone
Technical Support is available 7:00 A.M. to 5:00 P.M. PST Monday-Friday. Extended 24x7
Technical Support is available for customers with Gold or Platinum service contracts.
Global phone contact numbers can be found at McAfee Contact Information
http://www.mcafee.com/us/about/contact/index.html page.
Note: McAfee requires that you provide your GRANT ID and the serial number of
your system when opening a ticket with Technical Support. You will be provided with
a user name and password for the online case submission.
viii
CHAPTER 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, Troubleshooting Guide.
1
CHAPTER 2
Recommended Manager specifications

McAfee® Network Security Manager (Manager) software runs on a dedicated Windows
server.
The larger your deployment, the more high-end your Manager Server should be. Many
McAfee® Network Security Platform issues result from an under-powered Manager Server.
For example, to manage 40 or more McAfee® Network Security Sensors (Sensors), we
recommend larger configurations than the hardware specifications in the release notes.
Manager Server specifications

The following is the recommended minimum hardware configuration for a Manager Server
with embedded MySQL database:
Hardware Recommended Size/Speed
Physical memory 4 GB RAM

Processor 2 x 3.2 Pentium processors
Hard Disk 80 GB hard disk space (or greater)
Manager Client specifications

The Manager client is a Java Web application, which provides a Web-based user interface
for centralized and remote Sensor management. The Manager contains Java applets.
Because Java applets take advantage of the processor on the host from which they are
being viewed, we also recommend that the client hosts used to manage the Network
Security Platform solution meet the requirements in the following table:
Hardware Recommended Size/Speed
Physical memory 512 MB or more

Processor 1.5 GHz or faster CPU
Note: You will experience better performance in your configuration and data-
forensic tasks by connecting to the Manager from a browser on the client machine.
Performance may be slow if you connect to the Manager using a browser on the
server machine itself.
2
McAfee® Network Security Platform 6.0 Recommended Manager specifications
Determining your Database Requirements

The amount of space required for your database is governed by many factors, mostly
unique to the deployment scenario. These factors determine the amount of data you want
to retain in the database and the time for which the data has to be retained.
Things to consider while determining your database size requirements are:
• Aggregate alert and packet log volume from all Sensors—Many Sensors amount to higher alert
volume and require additional storage capacity. Note that an alert is roughly 200 bytes
on average, while a packet log is approximately 450 bytes.
• Lifetime of alert and packet log data: You need to consider the time before you archive or
delete an alert. Maintaining your data for a long period of time (for example, one year)
will require additional storage capacity to accommodate both old and new data.
As a best practice, McAfee recommends archiving and deleting old alert data regularly,
and attempting to keep your active database size to about 40 GB.
Note: For more information on capacity planning, see Capacity Planning, Manager
Server Configuration Guide.
3
CHAPTER 3
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.
4
CHAPTER 4
Large Sensor deployments

When you consider large McAfee® Network Security Sensor (Sensor) deployments, (where
the number of Sensors deployed range from 36 to 70) 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.
• Signature Set downloads - Signature Set downloads are applied to Sensors serially, not
concurrently. For releases prior to 3.1, the process would take approximately 3
minutes per Sensor. You must decide the point at which a signature set update
process becomes time consuming. At this point we would recommend that you utilize
a second McAfee® Network Security Manager (Manager) to minimize the time. For
example, in a deployment with 50 Sensors, with versions prior to 3.1, it will take
approximately 2.5 hours to complete a signature set update. The same is true for
policy updates. Note that from version 3.1, this process has been reduced to a matter
of minutes, not hours.
• 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 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 on the process of using TFTP to update your Sensor software,
see Upgrading Sensor software via a TFTP server, CLI Guide.
• 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.
• 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.
5
McAfee® Network Security Platform 6.0 Large Sensor deployments
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 (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 on updating the Sensor with latest software updates, see Updating the
configuration of a Sensor, Device Configuration 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, Installation Guide.
Note: Very large Sensor deployments mean that the number of Sensors deployed is
more than 71. Large Sensor deployments have Sensors numbering between 36 and
70.
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
CHAPTER 5
Troubleshooting issues with Sensor

When McAfee® Network Security Sensor (Sensor) experiences problems in the in-line
mode, one instinct is to physically pull it out of the path; to disconnect the cables and let
traffic flow unimpeded, while the device is examined elsewhere.
McAfee recommends that you first try the following techniques, to troubleshoot a Sensor
issue:
• All Sensors have a Layer2 Passthru feature. If you feel your Sensor is causing
network disruption, before you remove it from the network, issue the following
command:
layer2 mode assert
This pushes the Sensor into Layer2 Passthru (L2) mode, causing traffic to flow
through the Sensor while bypassing the detection engine. Check to see whether your
services are still affected; if they are, then you have eliminated certain Sensor
hardware issues; the problem could instead be a network issue or a configuration
issue. (The layer2 mode deassert command pushes the Sensor back to
detection mode.)
• Configure Layer2 Passthru Mode on each Sensor. This enables you to set a threshold
on the Sensor that pushes the Sensor into L2 bypass mode if the Sensor experiences
a specified number of errors within a specified time frame. Traffic then continues to
flow directly through the Sensor, without passing to the detection engine.
• Connect a fail-open kit, which consists of a bypass switch and a controller, to any GE
monitoring port pairs on the Sensor. If a kit is attached to the Sensor, disabling the
Sensor ports forces traffic to flow through the bypass switch, effectively pulling the
Sensor out of the path. For FE monitoring ports, there is no need for the external kit.
Sensors with FE ports contain an internal tap; disabling the ports will send traffic
through the internal tap, providing fail-open functionality.
Caution 1: Note that the Sensor will need to reboot to move out of L2 mode only if
the Sensor entered L2 mode because of internal errors. (It does not need a reboot if
the layer2 mode assert command was used to put the Sensor into L2 mode).
Caution 2: A Sensor reboot breaks the link connecting the devices on either side of
the Sensor and requires the re-negotiation of the network link between the two
devices surrounding the Sensor.
Caution 3: Depending on the network equipment, this disruption should range from
a couple of seconds to more than a minute with certain vendors’ devices.
Caution 4: A very brief link disruption might occur while the links are renegotiated to
place the Sensor back in in-line mode.
7
CHAPTER 6
Configuration of Speed and Duplex settings

The most common McAfee® Network Security Sensor (Sensor) deployment problems
relate to configuration of the monitoring port speed and duplex settings. Speed
determination issues may result in no connectivity between the Sensor and its network
device partners on either side.
Following sections provide you the best practices related to these issues.
Duplex mismatches
A duplex mismatch (for example, one end of the link in full-duplex and the other in half-
duplex) may result in performance issues, intermittent connectivity, and loss of
communication. It can also create subtle problems in applications. For example, if a Web
server is talking to a database server through an Ethernet switch with a duplex mismatch,
small database queries may succeed, while large ones fail due to a timeout.
Manually setting the speed and duplex to full-duplex on only one link partner generally
results in a mismatch. This common issue results from disabling auto-negotiation on one
link partner and having the other link partner default to a half-duplex configuration, creating
the mismatch. This is the reason why speed and duplex cannot be hard-coded on only one
link partner. If your intent is not to use auto-negotiation, you must manually set both link
partners' speed and duplex settings to full-duplex.
Troubleshooting a Duplex Mismatch with Cisco Devices

When troubleshooting connectivity issues with Cisco switches or routers, verify that the
Sensor and the switch/routers are using a valid configuration. The show intfport
<port> command on the Sensor CLI will help reveal errors.
Sometimes there are duplex inconsistencies between McAfee® Network Security Platform
and the switch port. Symptoms include poor port performance and frame check sequence
(FCS) errors that increment on the switch port. To troubleshoot this issue, manually
configure the switchport to 100 Mbps, half-duplex. If this action resolves the connectivity
problems, you may be running into this issue. Contact Cisco's TAC for assistance.
Use the following commands to verify fixed interface settings on some Cisco devices that
connect to Sensor:
8
McAfee® Network Security Platform 6.0 Configuration of Speed and Duplex settings
Cisco PIX® Firewall

• interface ethernet0 100full
Cisco CSS 11000

• interface ethernet-3
• phy 100Mbits-FD
Cisco Catalyst® 2900XL, 3500XL Series (Hybrid)

• interface FastEthernet0/2
• duplex full
• speed 100
Cisco Catalyst 4000, 5000, 6000 Series (Native)

• set port speed 1/1 100
• set port duplex 1/1 full
Cisco IOS® for Catalyst 4000, 6000 Series

• Router(config)# interface fastethernet slot/port
• Router(config-if)# speed 100
• Router(config-if)# duplex full
When troubleshooting Network Security Platform performance issues with Cisco switches,
view the output of the show port mod/port command, and note the counter
information.
Auto-negotiation issues
Auto-negotiation issues typically do not result in link establishment issues. Instead, auto-
negotiation issues mainly result in a loss of performance. When auto-negotiation leaves
one end of the link in, for example, full-duplex mode and the other in half-duplex (also
known as a duplex mismatch), errors and re-transmissions can cause unpredictable
behavior in the network. This can cause performance issues, intermittent connectivity, and
loss of communication. Generally these errors are not fatal—traffic still makes it through—
but locating and fixing them is a time-waster.
9
Situations that may result in Auto-negotiation issues

Auto-negotiation issues with the Network Security Platform Sensor may result from
nonconforming implementation, hardware incapability, or software defects.
Generally, if the switch used with the Sensor adheres to IEEE 802.3u auto-negotiation
specifications and all additional features are disabled, auto-negotiation should properly
negotiate speed and duplex, and no operational issues should exist.
• Problems may arise when vendor switches/routers do not conform exactly to the IEEE
specification 802.3u.
• Vendor-specific advanced features that are not described in IEEE 802.3u for 10/100
Mbps auto-negotiation (such as auto-polarity or cabling integrity) can also lead to
hardware incompatibility and other issues.
Valid Auto-negotiation and Speed Configuration settings

The table below summarizes all possible settings of speed and duplex for Sensor and
switch ports.
Network Security Configuration of Resulting Sensor Resulting Catalyst Comments

Platform Switch Speed/Duplex Speed/Duplex Speed/Duplex
Configuration 10/100
port
Speed/Duplex
100 Mbps 1000 Mbps No Link No Link Neither side
establishes link,
Full-duplex Full-duplex due to speed
mismatch
100 Mbps AUTO 100 Mbps 100 Mbps Duplex
Mismatch 1
Full-duplex Full-duplex Full-duplex
100 Mbps 1000 Mbps 100 Mbps 100 Mbps Correct Manual
Configuration2
Full-duplex Full-duplex Full-duplex Full-duplex
10 Mbps AUTO 100 Mbps 100 Mbps Link is

established, but
Half-duplex Half-duplex Half-duplex switch does not
see Fast Link
Pulse (FLP) and
defaults to 10
Mbps half-
duplex.
10 Mbps 1000 Mbps No Link No Link Neither side
establishes link,
Half-duplex Half-duplex due to speed
mismatch.
10
Explanation of CatOS show port command counters
Counter Description Possible Causes
Alignment Alignment errors are a count of the These are the result of collisions at
Errors number of frames received that do not half-duplex, duplex mismatch, bad
end with an even number of octets and hardware (NIC, cable, or port), or a
have a bad CRC. connected device generating frames
that do not end with on an octet and
have a bad FCS.
FCS FCS error count is the number of These are the result of collisions at
frames that were transmitted or half-duplex, duplex mismatch, bad
received with a bad checksum (CRC hardware (NIC, cable, or port), or a
value) in the Ethernet frame. These connected device generating frames
frames are dropped and not with bad FCS.
propagated onto other ports.
Xmit-Err This is an indication that the internal This is an indication of excessive input
transmit buffer is full. rates of traffic. This is also an
indication of transmit buffer being full.
The counter should only increment in
situations in which the switch is unable
to forward out the port at a desired
rate. Situations such as excessive
collisions and 10 Mb ports cause the
transmit buffer to become full.
Increasing speed and moving the link
partner to full-duplex should minimize
this occurrence.
Rcv-Err This is an indication that the receive This is an indication of excessive
buffer is full. output rates of traffic. This is also an
indication of the receive buffer being
full. This counter should be zero
unless there is excessive traffic
through the switch. In some switches,
the Out-Lost counter has a direct
correlation to the Rcv-Err.
UnderSize These are frames that are smaller than This is an indication of a bad frame
64 bytes (including FCS) and have a generated by the connected device.
good FCS value.
Single Single collisions are the number of This is an indication of a half-duplex

Collisions times the transmitting port had one configuration.
collision before successfully
transmitting the frame to the media.
Multiple Multiple collisions are the number of This is an indication of a half-duplex
Collisions times the transmitting port had more configuration.
than one collision before successfully
transmitting the frame to the media.
11
Counter Description Possible Causes
Late Collisions A late collision occurs when two This is an indication of faulty hardware
devices transmit at the same time and (NIC, cable, or switch port) or a duplex
neither side of the connection detects mismatch.
a collision. The reason for this
occurrence is that the time to
propagate the signal from one end of
the network to another is longer than
the time to put the entire packet on the
network. The two devices that cause
the late collision never see that the
other is sending until after it puts the
entire packet on the network. Late
collisions are detected by the
transmitter after the first time slot of
the 64-byte transmit time occurs. They
are only detected during transmissions
of packets longer than 64 bytes. Its
detection is exactly the same as it is
for a normal collision; it just happens
later than it does for a normal collision.
Excessive Excessive collisions are the number of This is an indication of over-utilization
Collisions frames that are dropped after 16 of the switch port at half-duplex or
attempts to send the packet resulted in duplex mismatch.
16 collisions.
Carrier Sense Carrier sense occurs every time an This is an indication of faulty hardware
Ethernet controller wants to send data (NIC, cable, or switch port).
and the counter is incremented when
there is an error in the process.
Runts These are frames smaller than 64 This is an indication of the result of
bytes with a bad FCS value collisions, duplex mismatch, IEEE
802.1Q (dot1q), or an Inter-Switch
Link Protocol (ISL) configuration issue.
Giants These are frames that are greater than This is an indication of faulty
1518 bytes and have a bad FCS hardware, dot1q, or an ISL
value. configuration issue.
Gigabit auto-negotiation (no link to connected device)

Gigabit Ethernet has an auto-negotiation procedure that is more extensive than that which
is used for 10/100 Mbps Ethernet (per Gigabit auto-negotiation specification IEEE 802.3z-
1998). The Gigabit auto-negotiation negotiates flow control, duplex mode, and remote fault
information. You must either enable or disable link negotiation on both ends of the link.
Both ends of the link must be set to the same value or the link will not connect.
If either device does not support Gigabit auto-negotiation, disabling Gigabit auto-
negotiation forces the link up.
12
McAfee® Network Security Platform 6.0 Effective Policy Tuning practices
CHAPTER 7
Effective Policy Tuning practices

As of McAfee® Network Security Manager (Manager) software version 2.1, all McAfee®
Network Security Sensors (Sensors) on initial deployment, have the McAfee® Network
Security Platform 'Default Inline IPS' policy loaded on all interfaces. The “Default Inline
IPS’ policy can be changed at the Root Admin level.
McAfee recommends, where appropriate, to use this or another McAfee Network Security
Platform-provide policy as a starting point, but to tune these into segment-tailored custom
policies. These tailored policies can be either cloned versions of Network Security Platform
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.
Note: 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.
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, System Status
Monitoring 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 Attack filters

When a particular alert is declared as false positive, the next decision is whether to disable
the corresponding attack altogether OR apply a particular attack filter 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.
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
13
McAfee® Network Security Platform 6.0 Effective Policy Tuning practices
cancel the possibility of finding a real attack of this nature, we recommend that you create
an attack filter for the SMS server and apply it to the attack.
Every attack filter 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 attack filters that have been applied and attacks that have been otherwise
customized.
Note: For more information on attack filters, see Managing Attack Filters and Attack
Responses, IPS Configuration 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 (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 on Sensor learning modes, see Managing DoS Learning Mode
profiles on a Sensor, IPS Configuration Guide.
14
CHAPTER 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 in-line 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.
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.
• IPS Quarantine: Sensor will quarantine/remediate a host as per the configurations in
McAfee® Network Security Manager (Manager) and the Sensor monitoring ports. IPS
Quarantine can be enabled per attack in the Policy Editors.
Note 1: For more information on other Sensor actions, see Sensor Actions, IPS
Configuration Guide.
Note 2: For more information on IPS Quarantine, see IPS Quarantine settings in the
IPS Sensor, IPS Configuration Guide.
15
CHAPTER 9
Creating 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 (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.
Note: For more information on rule set creation, see Managing Rule Sets, IPS
16
CHAPTER 10
Port clustering on Asymmetric networks

Port clustering, referred to as Interface Groups in the Manager interface, enables multiple
ports on a single McAfee® Network Security Sensor (Sensor) to be grouped together for
effective traffic monitoring.
It is a best practice to implement a port clustering configuration when dealing with

asymmetrically routed networks. 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.
Once configured, an interface group appears in the System Configuration tool's Resource
Tree as a single interface node (icon) under the Sensor where the ports are located. All of
the ports that make up the interface are configured as one logical entity, keeping the
configuration consistent.
Note: For more information on port clustering, see Port clustering (interface groups),
Getting Started Guide.
17
CHAPTER 11
Access Control Lists (ACLs)

Note the following points while working with Access Control Lists or ACLs:
• You cannot set explicit ACL permit 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 ACLs 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 ACL rules that can be supported by a McAfee®
Network Security Sensor (Sensor). The following table specifies the rule limit for
ACLs:
Sensor ACL rule limit
I-4010 1000
I-4000 1000
I-3000 1000
I-2700 400
I-1400 100
I-1200 50
Sensor ACL rule limit

M-8000 1000
M-6050 1000
M-4050 1000
M-3050 1000
M-2750 400
M-1450 100
M-1250 50
Note: For more information, see Access Control Lists, IPS Configuration Guide.
18
McAfee® Network Security Platform 6.0 SSL best practices
CHAPTER 12
SSL best practices

Note that there is a performance impact when using the SSL decryption feature. Refer the
following sections for the SSL throughput measurements and test methodologies.
SSL only traffic - throughput

• Session resumption for 4 out of 5 TCP connections
• 5 HTTP 1.1 get page requests per TCP connection with a 5K response each
• 1024-bit RSA
• 128-bit ARC4
I-2700 I-3000 I-4000 I-4010
Max. SSL Connections / 325 600 800 1200

Sec.
Throughput 85 Mbps 155 Mbps 200 Mbps 310 Mbps
SSL only traffic - throughput

• 1024-bit RSA
• 128-bit ARC4
I-2700 I-3000 I-4000 I-4010
Max. SSL Connections / 300 400 800 800

Sec.
Throughput 150 Mbps 200 Mbps 400 Mbps 400 Mbps
19
M-2750 M-3050 M-4050 M-6050 M-8000
Max. SSL Connections / 550 1300 2700 4500 8500

Sec.
Throughput 250 Mbps 600 Mbps 1200 Mbps 2 Gbps 3.8 Gbps
SSL traffic mixed with HTTP 1.1 traffic

• 1024-bit RSA
• 128-bit ARC4
I- 2700
Max. SSL Connections / Sec. 100 200
SSL Throughput 25 Mbps 50 Mbps
HTTP 1.1 Throughput 475 Mbps 350 Mbps
Total Throughput 500 Mbps 400 Mbps
I-3000
I-4000
I-4010
20
M-2750
Max. SSL Connections / Sec. 110
SSL Throughput 50 Mbps
HTTP 1.1 Throughput 500 Mbps
Total Throughput 550 Mbps
M-3050

HTTP 1.1 Throughput 1.2 Gbps
Total Throughput 1.35 Gbps
M-4050
HTTP 1.1 Throughput 2.5 Gbps
M-6050
HTTP 1.1 Throughput 4 Gbps
M-8000
HTTP 1.1 Throughput 8 Gbps
Supported SSL functionalities

Following SSL functionalities are supported.
21
Supported Web servers

SSL decryption is supported for the following web servers:
• Microsoft Internet Information Server (IIS)

• Apache
Supported cipher suites

The following SSL cipher suites (as named in their respective RFCs) are supported:
SSLv2 cipher suites
• SSL_CK_RC4_128_WITH_MD5
• SSL_CK_RC4_128_EXPORT40_WITH_MD5
• SSL_CK_DES_64_CBC_WITH_MD5
• SSL_CK_DES_192_EDE3_CBC_WITH_MD5
SSLv3/TLS cipher suites
• SSL/TLS_NULL_WITH_NULL_NULL
• SSL/TLS_RSA_WITH_NULL_MD5
• SSL/TLS_RSA_WITH_NULL_SHA
• SSL/TLS_RSA_WITH_RC4_128_MD5
• SSL/TLS_RSA_WITH_RC4_128_SHA
• SSL/TLS_RSA_WITH_DES_CBC_SHA
• SSL/TLS_RSA_WITH_3DES_EDE_CBC_SHA
• SSL/TLS_RSA_WITH_AES_128_CBC_SHA
• SSL/TLS_RSA_WITH_AES_256_CBC_SHA
SSLv3/TLS cipher suites
Unsupported SSL functionalities

The following SSL functionalities are not supported:
• iPlanet Web servers

• Diffie-Hellman ciphers (McAfee recommends that you disable acceptance of Diffie-
Hellman requests on the SSL Web server to ensure that Network Security Platform is
able to decrypt the traffic)
• Compression in the SSL records (a negotiable option in SSLv3 and TLS)
• PCT (Microsoft's extension to SSLv2)
22
CHAPTER 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.
• 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.
23
McAfee® Network Security Platform 6.0 Sensor HTTP Response Processing deployment
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 I series Sensors

Refer the following table for I-series Sensor performance numbers with HTTP response
processing:
I-4010 I-4000 I-3000 I-2700 I-1400 I-1200
- HTTP Response 2 Gbps 1.78 Gbps 1 Gbps 550 Mbps 195 Mbps 97 Mbps
Scanning Disabled
- 5 HTTP 1.1 get page
requests per TCP
connection with a 10K
response each
- HTTP Response 1 Gbps 1 Gbps 680 Mbps 430 Mbps 160 Mbps 75 Mbps
Scanning Enabled for
outbound direction
- 5 HTTP 1.1 get page
requests per TCP
connection with a 10K
response each
HTTP Response processing results for M-series Sensors

Refer the following table for M-series Sensor performance numbers with HTTP response
processing:
24
McAfee® Network Security Platform 6.0 Sensor HTTP Response Processing deployment
M-8000 M-6050 M-4050 M-3050 M-2750 M-1450 M-1250
- HTTP Response 10 Gbps 5 Gbps 3 Gbps 1.5 600 Mbps 200 Mbps 100 Mbps
Scanning Disabled Gbps
- 5 HTTP 1.1 get
page requests per
TCP connection with
a 10K response
each
- HTTP Response 5.4 2.8 2 Gbps 1 Gbps 500 Mbps 200 Mbps 100 Mbps
Scanning Enabled for Gbps Gbps
outbound direction
- 5 HTTP 1.1 get
page requests per
TCP connection with
a 10K response
each
25
CHAPTER 14
Database maintenance
McAfee recommends the following best practices for database backup and tuning:
• Perform regular manual backups of your database using the Backup feature in the
McAfee® Network Security Manager (Manager) software. Your configuration tables are
saved by default once a week on Saturday.
• Database backups are cumulative and the size of a backup file can become quite
large. Perform regular file maintenance to prevent disk space issues.
Warning: A database left untuned can, over time, lead to data corruption.
• Online database tuning operation causes the creation of temporary alert and packet
log tables; if you are using an agent that queries the database, your agent may
attempt to interact with these tables during tuning. There is a remote chance that
during the transition to the temporary tables, the SQL query will result in an error. If a
SQL query error occurs, simply retry the query. Further information on the impact of
online database tuning of the Manager database will be sent to the third-party vendors
that are directly accessing this database. If you have any specific questions, contact
Technical Support. Also note that there is no change in database SQL query behavior
if online database tuning is disabled.
• Make a regular practice of defragmenting the disk of the Manager server, as disk
fragmentation can lead to database inefficiency.
• When scheduling certain Manager actions (backups, file maintenance, archives,
database tuning), set a time for each that is unique and is a minimum of an hour
after/before other scheduled actions. Do not run scheduled actions concurrently.
• Tune your database at regular intervals using the online tuning tools.
Note: For more information on tuning your database, see Manager Server
Backup of data and configurations

For the back up of McAfee® Network Security Platform data and configurations, following
best practices are recommended:
• Back up Manager data either within the Manager server (McAfee Network Security
Platform\Backups folder) or preferably on external media.
• Back up all information, including configurations, alerts, and audits.
• Implement a schedule for backups using the Backup scheduler. Backing up config
tables weekly is recommended. (Be sure to schedule this at a time when other
processes will not be running concurrently.)
• As the 'All Tables' and 'Audit and Alert Tables' options can be rather large in size
(depending upon the amount of alert data in the database) these types of backups
should be saved off the Manager server.
• Saving the 'All Tables' settings monthly is strongly recommended.
• Protect backups from tampering by creating a digital fingerprint of the file using a hash
function such as MD5 or SHA-1.
26
McAfee® Network Security Platform 6.0 Database maintenance
• Test restoration of backups periodically to ensure that a backup was successful and
valid. The best way to do this is to perform a “test” restore of the backup on a
secondary, non-production Manager.
• The 'Config Tables' option backs up only tabled information relating to configured
tasks. This option is enabled by default to occur every Saturday night. This is set
within the Backup Scheduler action.
• Save actual configurations of Sensors (not just the config tables) using the Export
option under the Sensor_Name tab. This creates an XML file (no attempt to read this file
should be made) that can be imported to any Sensor of the same type in the future.
Save actual Sensor configurations weekly.
Tip 1: For more information on backup methods, see Backing up data and settings,
Manager Server Configuration Guide.
Tip 2: For more information on database backup, see Database backup and
Recovery, Manager Server Configuration Guide.
27
CHAPTER 15
Alerts and Disk space maintenance

Disk space maintenance is an important task that must be completed to ensure efficient
running of the McAfee® Network Security Manager (Manager).
In order to develop best practices for database maintenance it is important to understand

the lifecycle of an alert. For more information, see The lifecycle of an alert, Getting Started
Guide.
Note: For more information on Disk Space Maintenance, see Database

maintenance and tuning, Manager Server Configuration Guide.
Archiving alerts
Archive your alerts and packet logs regularly, using the Alert and Packet Log Archival
feature. McAfee recommends that you archive your alert data monthly, and that you
discard alert and packet log information from your database every 90 days to manage your
database size. Note that there is currently a 4 GB size limitation for a single archive file.
Scripts for disk space maintenance

If you have a large amount of data and wish to do your tuning offline, it is a best practice to
use the purge.bat (forces the deletion of old alerts) and dbtuning.bat (force the tuning of the
database) scripts. To do this you must stop the Manager and run the scripts. To tune while
the Manager is running, use the online tools, but ensure that you do not have another
process running concurrently during the tuning.
A best practice suggestion is to wait for 97 days of data and then on a recurring 7-day
period run the purge.bat and dbtuning.bat—this will delete alerts already marked for
deletion (from the Alert Viewer) as well as alerts older than 90 days. Scripts have to be run
off-line (that is, Manager service stopped) to release the lock from the database.
Dbtuning.bat
The dbtuning.bat utility does the following:
• Defragments tables where rows/columns are split or have been deleted

• Re-sorts indexes
• Updates index statistics
• Computes query optimizer statistics
• Checks and repairs tables
28
McAfee® Network Security Platform 6.0 Alerts and Disk space maintenance
Purge.bat
The purge.bat utility enables on-demand deletion of alerts and packet log data from your
database. Alerts and packet logs can be deleted that are older than a specified number of
days, or if they have been marked for deletion via the Threat Analyzer tool.
Purge.bat also offers to automatically start dbtuning.bat immediately after the purge is
completed.
Using File Maintenance Scheduler

Databases can be substantially overloaded, with all Alert and Packet logs, any incident
reports that have been generated, and audit and fault logs. Maintenance of this data can
be accomplished automatically using the File Maintenance scheduler.
If automatic File Maintenance is used to delete alert and packet log data it is
recommended that a large value -such as 90, as in 90 days—is entered in the “Scheduled
Deletion” column for the Alert & Packet Log Data option. This allows for long-term analysis
of alerts and logs without overloading your database with millions of alerts, which may
affect long-term and overall database performance. By setting the value to 90 days, all
alerts and packet logs older than 90 days are deleted at the weekly maintenance
scheduler time.
Apart from the database data, Manager creates a group of administration files that must be
maintained regularly. These include Diagnostic files, DoS files (profiles) and Data Mining
files (for Trend Reporting) among others. It is a best practice to schedule the deletion of
the oldest of these files on an on-going basis. This can be accomplished using the
Maintenance scheduler.
Note: For more information on setting the scheduler for file maintenance, see
Setting a schedule for file maintenance, Manager Server Configuration Guide.
29
CHAPTER 16
Manager Disaster Recovery (MDR) best practices

A newly created MDR pair does not synchronize for the first 15 minutes after creation. This
is by design because, depending on the quantity of McAfee® Network Security Sensors
(Sensors), it takes approximately 5 to 10 minutes for the newly formed pair to finish MDR-
related tasks and become stable.
If you have only one or two Sensors, you can press the Retrieve Configuration button on the
Manage MDR page of the secondary McAfee® Network Security Manager (Manager) soon
after MDR creation, to force the Managers to synchronize. In most cases, however, we
recommend you wait the 15 minutes and allow the new MDR pair to synchronize
automatically.
If you return to the user interface of the primary Manager, the details on the Manage MDR
page validate the information seen on the secondary.
Note: For more information on MDR, see MDR communication, Manager Server
30
CHAPTER 17
Performance issues
Most performance issues are related to switch port configuration, duplex mismatches, link
up/down situations, and data link errors.
Sniffer trace
A Sniffer details packet transfer, and thus a Sniffer trace analysis can help pinpoint switch
and McAfee® Network Security Platform performance or connectivity issues when the
issues persist after you have exhausted the other suggestions in this document. Sniffer
trace analysis reveals every packet on the wire and pinpoints the exact problem.
Note that it may be important to obtain several Sniffer traces from different ports on
different switches, and that it is useful to monitor (“span”) ports rather than spanning
VLANs when troubleshooting switch connectivity issues.
Data link errors

Many performance issues may be related to data link errors. Excessive errors usually
indicate a problem. For more information, see also Configuration of Speed and Duplex
settings (on page 8).
Half-duplex setting
When operating with a duplex setting of half-duplex, some data link errors such as FCS,
alignment, runts, and collisions are normal. Generally, a one percent ratio of errors to total
traffic is acceptable for half-duplex connections. If the ratio of errors to input packets is
greater than two or three percent, performance degradation may be noticeable.
In half-duplex environments, it is possible for both the switch and the connected device to
sense the wire and transmit at exactly the same time, resulting in a collision. Collisions can
cause runts, FCS, and alignment errors, which are caused when the frame is not
completely copied to the wire, resulting in fragmented frames.
Full-duplex setting
When operating at full-duplex, FCS, cyclic redundancy checks (CRC), alignment errors,
and runt counters should be minimal. If the link is operating at full-duplex, the collision
counter is not active. If the FCS, CRC, alignment, or runt counters are incrementing, check
for a duplex mismatch. Duplex mismatch is a situation in which the switch is operating at
full-duplex and the connected device is operating at half-duplex, or vice versa. The result
of a duplex mismatch is extremely slow performance, intermittent connectivity, and loss of
connection. Other possible causes of data link errors at full-duplex are bad cables, a faulty
switch port, or software or hardware issues.
31
McAfee® Network Security Platform 6.0 Vulnerability Assessment
CHAPTER 17
Vulnerability Assessment
McAfee® Network Security Platform recommends the following while performing
Vulnerability Assessment:
• Always use the latest signatures available for your vulnerability assessment (VA)
software. This will help ensure the assessment is accurate.
• Where possible, scan all hosts you expect McAfee Network Security Platform to
protect. This will help increase the probability that a relevancy status of "Unknown"
really means that the attack is not relevant.
• If the scan traffic between the Vulnerability Manager server and the hosts being
scanned passes through a Sensor monitoring port, the Sensor may consider it as
attack traffic and take the corresponding response action such as quarantining the
Vulnerability Manager server. To prevent this:
Create ACLs to exclude all traffic from the Vulnerability Manager server from
attack inspection. For information on ACLs, see Configuring ACL rules, IPS
If you have configured Network Access Control (NAC) or IPS Quarantine, then
add the Vulnerability Manager server to the NAC Exclusions list. This prevents the
Vulnerability Manager server being denied network access. See the NAC Configuration
Guide for information.
• Replace old reports with new reports on a routine basis (weekly or monthly). Given
the frequency with which new attacks appear, reports can become obsolete quickly,
and render VA integration ineffective.
• Replacing an old report with a new one might result in similar alerts having different
relevance values. For example, if Network Security Platform uses an initial scanner
report to analyze one alert and an updated scanner report to analyze the next, it may
correctly draw different conclusions for each. To avoid confusion, consider
acknowledging (or purging) all existing alerts each time you replace reports.
Note: For more information on vulnerability assessment using Network Security

PlatformMcAfee Vulnerability Manager integration, see Integration with McAfee
Vulnerability Manager, Integration Guide.
32
CHAPTER 19
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 25,000 25,000 10,000 6,250 2,000 1,000

per sec.
Concurrent SSL Flows 100,000 100,000 50,000 25,000 NA NA
Number of SSL keys that 64 64 64 64 NA NA

can be stored on the
Sensor
Virtual Interfaces (VIDS) 1,000 1,000 1,000 100 32 16
per Sensor
VLAN / CIDR Blocks per 3,000 3,000 3,000 300 64 32
Sensor
VLAN / CIDR Blocks per 254 254 254 254 64 32
Interface
Customized attacks 100,000 100,000 100,000 100,000 40,000 20,000
Attack filters 128,000 128,000 128,000 64,000 32,000 16,000
Default number of 100,000 100,000 50,000 25,000 6,000 5,000

supported UDP 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 1,000,000 1,000,000 500,000 250,000 64,000 83,000

packets per second)
ACL Rules (refer to note 1,000 1,000 1,000 400 100 50
below)
For more information on computing ACL, see Viewing ACL descriptions using Effective
ACL rules, IPS Configuration guide.
33
McAfee® Network Security Platform 6.0 I-series Sensor capacity by model number
Note for customized attacks

The signature set push from McAfee® Network Security Manager (Manager) to a Sensor
will fail 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.
a. Create a new policy.
b. Set the Inbound rule set to "File Server rule set".
c. Set the Outbound rule set to "All-inclusive with Audit rule set".
You will 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.
34
CHAPTER 20
M-series Sensor capacity by model number

Maximum Type M-8000 M-6050 M-4050 M-3050 M-2750 M-1450 M-1250 N-450
Aggregate 10 Gbps 5 Gbps 3 Gbps 1.5 Gbps 600 Mbps 200 Mbps 100 Mbps 2 Gbps
Performance
Concurrent 4,000,000 2,000,000 1,500,000 750,000 250,000 80,000 40,000 250,000
connections
Connections 120,000 60,000 36,000 18,000 10,000 4,000 2,000 66,000
established per
sec.
SSL Flow count 400,000 200,000 150,000 75,000 25,000 NA NA NA
maximum
Number of SSL 64 64 64 64 64 NA NA NA
keys that can be
stored in Sensor
Virtual 1,000 1,000 1,000 1,000 100 32 16 100

Interfaces
(VIDS) per
Sensor
VLAN / CIDR 3,000 3,000 3,000 3,000 300 64 32 300
Blocks per
Sensor
VLAN / CIDR 254 254 254 254 254 64 32 254
Blocks per
Interface
Customized 100,000 100,000 100,000 100,000 100,000 100,000 20,000 NA
attacks
Attack filters per 128,000 128,000 100,000 100,000 100,000 40,000 20,000 NA
VIDS
Attack filters per 262,144 262,144 262,114 262,144 131,072 65,536 32,768 NA
Sensor
Default number 400,000 400,000 100,000 50,000 25,000 10,000 5,000 25,000
of supported
UDP Flows
Supported UDP 3,000,000 1,500,000 750,000 375,000 187,500 60,000 30,000 187,500
Flows
35
McAfee® Network Security Platform 6.0 M-series Sensor capacity by model number
Maximum Type M-8000 M-6050 M-4050 M-3050 M-2750 M-1450 M-1250 N-450
DoS Profiles 5,000 5,000 5,000 5,000 300 120 100 NA
SYN rate (64- 5,000,000 2,500,000 2,000,000 1,500,000 600,000 250,000 200,000 NA
byte packets
per second)
ACL Rules 1,000 1,000 1,000 1,000 400 100 50 400
(refer to note
below)
Note: SSL decryption is not supported on M-1450, M-1250 and N-450 Sensors.
The number of supported SSL flows on a Sensor directly impacts the number of
TCP flows that can be processed simultaneously.
36
CHAPTER 18
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 support
supported. No negotiation with peer for internal tap. No negotiation with
devices. 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
ports to fail-close fail-close
Inline fail-open (Default) Does not require external passive Fail- Does not require external passive Fail-
open Kit open Kit
Inline fail-open (Active Supported with ports configured in fail- Supported with ports configured in fail-
Fail-open Kit) close (no dongles) close (no dongles)
Link Failure - inline fail- Ports fail-close and traffic is disrupted. Ports fail-close and traffic is disrupted.
close
Link Failure - inline fail- Ports are not admin disabled and Ports are admin disabled, put into
open traffic is disrupted 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 the Manager
Sensor Power off - inline Ports fail-close with dongles Ports fail-close and traffic is disrupted.
fail-close connected; fail-open (bypass) with no
dongles
Sensor Power off - inline Ports fail-open (bypass), no traffic Ports fail-open, put into bypass, and
fail-open disrupted (must not have dongles no traffic is disrupted.
connected.)
Warm reboot - inline fail- Ports are enabled and in the down Ports are admin disabled and put in
open (CLI reboot or state till the Sensor starts rebooting. bypass before the Sensor reboots. No
reboot due to error and Traffic is disrupted till then. traffic is disrupted.
watchdog on)
Warm reboot - inline fail- Ports remain enabled fail-close, traffic Ports remain enabled fail-close, traffic
close (CLI reboot or disruption till the Sensor is up disruption till the Sensor is up
reboot due to error and
watchdog on)
37
McAfee® Network Security Platform 6.0 Comparison Between I-1200/I-1400 and M-1250/M-1450 FE ports
Resetconfig Restores to default configuration Options to either restore defaults or to

(inline fail-open) and reboots retain the current port configuration are
available
Port link LED Normal is green and indicates up; Green indicates up and inline; OFF
interpretation - inline fail- OFF indicates down and not indicates bypass.
open necessarily bypass
Port link LED OFF indicates down and traffic is OFF indicates down and traffic is
interpretation - inline fail- disrupted disrupted
close
Port link LED OFF indicates - bypass and no traffic OFF indicates bypass and no traffic is
interpretation during disrupted. disrupted
reboot/Sensor power
down - inline fail-open
Port link LED OFF indicates down, traffic is OFF indicates down and traffic
interpretation during disrupted. disrupted.
reboot/Sensor power
down - inline fail-close
Front panel LED for Not present Green indicates up and inline; OFF
Normal/Bypass operations indicates bypass.
- inline fail-open
Front panel LED for Not present Always on (green), normal operation.
Normal/Bypass operations
- inline fail-close
- SPAN
- TAP
Link Events No support to control fail-open/bypass Has support to control fail-
operation open/bypass operation
Port density I-1200 - 1A/1B, I-1400 - 1A/1B and 1A/1B through 4A/4B
2A/2B
Auto MDIX support No support(Supported in I1200 and not Supported by default (not configurable
in I1400). 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)
38
McAfee® Network Security Platform 6.0 Comparison Between I-1200/I-1400 and M-1250/M-1450 FE ports
The Manager port config Not present Four separate bypass buttons, one
panel - Inline/Bypass button per port pair:
status color coding • Green - inline
• Yellow - bypass
The Manager port status Red Gray
at Link failure - inline fail-
open
The Manager port status Red Red
at Link failure - inline fail-
close
The Manager port status Red Red
at Link failure - SPAN
39
P
performance issues................................................ 35
Index policy tuning practices...................................... 15, 16
R
A rule set creation best practices .............................. 19
auto-negotiation issues .......................... 9, 10, 11, 13
S
B Sensor capacity by model number......................... 37
backup of data........................................................ 30
Response Management......................................... 17
sensor troubleshooting issues ................................. 7
C sniffer trace ............................................................ 35
cabling best practices............................................... 4
speed and duplex settings ....................................... 8
connectivity issues ................................................... 8
SSL best practices ............................... 23, 24, 25, 26
conventions ............................................................. vi
staging sensors........................................................ 6
D T
data link errors ....................................................... 35
technical support......................................................ix
database management best practices ....... 30, 32, 33
V
duplex mismatch ...................................................... 8
vulnerability assessment best practices................. 37

F
File Maintenance Scheduler................................... 33
full-duplex setting ................................................... 35
H
half-duplex setting .................................................. 35
HTTP ................................................................ 27, 28
I
in-line mode.............................................................. 7
interface groups ..................................................... 20
L
large sensor deployment...................................... 5, 6
Layer2 Passthru ....................................................... 7
M
Manager Disaster Recovery (MDR) best practices 34

Mcafee® Network Security Platform

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mcafee® Network Security Platform

Enviado por

Direitos autorais:

Formatos disponíveis

Best Practices Guide

McAfee® Network Security Platform

LICENSE AND PATENT INFORMATION

Issued JUNE 2010 / Best Practices Guide

Chapter 2 Recommended Manager specifications.................................... 2

Chapter 3 Cabling best practices ................................................................ 4

Chapter 4 Large Sensor deployments ........................................................ 5

Chapter 5 Troubleshooting issues with Sensor ........................................ 7

Chapter 6 Configuration of Speed and Duplex settings ........................... 8

Chapter 7 Effective Policy Tuning practices ............................................ 13

Chapter 8 Response Management ............................................................ 15

Chapter 9 Creating Rule sets ..................................................................... 16

Chapter 10 Port clustering on Asymmetric networks ............................. 17

Chapter 11 Access Control Lists (ACLs).................................................. 18

Chapter 12 SSL best practices .................................................................. 19

Chapter 13 Sensor HTTP Response Processing deployment................ 23

Chapter 14 Database maintenance ........................................................... 26

Chapter 15 Alerts and Disk space maintenance ...................................... 28

Chapter 16 Manager Disaster Recovery (MDR) best practices .............. 30

Chapter 17 Performance issues ................................................................ 31

Chapter 18 Vulnerability Assessment....................................................... 32

Chapter 19 I-series Sensor capacity by model number .......................... 33

Chapter 20 M-series Sensor capacity by model number ........................ 35

Chapter 21 Comparison Between I-1200/I-1400 and M-1250/M-1450 FE

Introducing McAfee Network Security Platform

About this Guide

• Hardware and software recommendations for Network Security Platform

Conventions used in this book

Names of keys on the keyboard Press ENTER.

Information that you must read to Warning:

• Device Configuration Guide

Contacting Technical Support

Recommended Manager specifications

Manager Server specifications

Hardware Recommended Size/Speed

Physical memory 4 GB RAM

Manager Client specifications

Hardware Recommended Size/Speed

Physical memory 512 MB or more

Determining your Database Requirements

Things to consider while determining your database size requirements are:

Cabling best practices

Also, in the most security-conscious environments, or those with congestion problems, a

Large Sensor deployments

Staging Sensors prior to deployment

Recommendations for large Sensor deployment

McAfee provides a few recommendations for this process:

Troubleshooting issues with Sensor

Configuration of Speed and Duplex settings

Troubleshooting a Duplex Mismatch with Cisco Devices

Cisco PIX® Firewall

Cisco CSS 11000

Cisco Catalyst® 2900XL, 3500XL Series (Hybrid)

Cisco Catalyst 4000, 5000, 6000 Series (Native)

Cisco IOS® for Catalyst 4000, 6000 Series

Situations that may result in Auto-negotiation issues

Valid Auto-negotiation and Speed Configuration settings

Network Security Configuration of Resulting Sensor Resulting Catalyst Comments

10 Mbps AUTO 100 Mbps 100 Mbps Link is

Explanation of CatOS show port command counters

Counter Description Possible Causes

Single Single collisions are the number of This is an indication of a half-duplex