Professional Documents
Culture Documents
Mcafee® Network Security Platform
Mcafee® Network Security Platform
Mcafee® Network Security Platform
revision 3.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 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.
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
iii
Best methods for rule set creation............................................................................................... 16
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.
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.
Best practices are provided for the following topics/issues in Network Security Platform:
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.
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.
vi
McAfee® Network Security Platform 6.0 Preface
Convention Example
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
• I-1400 Sensor Product Guide
• I-2700 Sensor Product Guide
• I-3000 Sensor Product Guide
• I-4000 Sensor Product Guide
• I-4010 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
• M-6050 Sensor Product Guide
• M-6050 Quick Start Guide
• M-8000 Sensor Product Guide
• M-8000 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
McAfee® Network Security Platform 6.0 Preface
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
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.
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:
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
• 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
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.
4
CHAPTER 4
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
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.
• 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
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
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.
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
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
McAfee® Network Security Platform 6.0 Configuration of Speed and Duplex settings
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.
10
McAfee® Network Security Platform 6.0 Configuration of Speed and Duplex settings
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.
11
McAfee® Network Security Platform 6.0 Configuration of Speed and Duplex settings
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.
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
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.
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.
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.
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.
• 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
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).
Note: For more information on rule set creation, see Managing Rule Sets, IPS
Configuration Guide.
16
CHAPTER 10
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
• 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
Note: For more information, see Access Control Lists, IPS Configuration Guide.
18
McAfee® Network Security Platform 6.0 SSL best practices
CHAPTER 12
19
McAfee® Network Security Platform 6.0 SSL best practices
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
Max. SSL Connections / Sec. 200 400
SSL Throughput 50 Mbps 105 Mbps
HTTP 1.1 Throughput 860 Mbps 475 Mbps
Total Throughput 910 Mbps 580 Mbps
I-4000
Max. SSL Connections / Sec. 400 800
SSL Throughput 100 Mbps 200 Mbps
HTTP 1.1 Throughput 1550 Mbps 780 Mbps
Total Throughput 1650 Mbps 980 Mbps
I-4010
Max. SSL Connections / Sec. 400 800
SSL Throughput 100 Mbps 200 Mbps
HTTP 1.1 Throughput 1740 Mbps 860 Mbps
Total Throughput 1840 Mbps 1060 Mbps
20
McAfee® Network Security Platform 6.0 SSL best practices
M-2750
Max. SSL Connections / Sec. 110
SSL Throughput 50 Mbps
HTTP 1.1 Throughput 500 Mbps
Total Throughput 550 Mbps
M-3050
Max. SSL Connections / Sec. 220
M-4050
Max. SSL Connections / Sec. 440
SSL Throughput 200 Mbps
HTTP 1.1 Throughput 2.5 Gbps
Total Throughput 2.7 Gbps
M-6050
Max. SSL Connections / Sec. 880
SSL Throughput 440 Mbps
HTTP 1.1 Throughput 4 Gbps
Total Throughput 4.4 Gbps
M-8000
Max. SSL Connections / Sec. 1750
SSL Throughput 800 Mbps
HTTP 1.1 Throughput 8 Gbps
Total Throughput 8.8 Gbps
21
McAfee® Network Security Platform 6.0 SSL best practices
• 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
22
CHAPTER 13
• 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.
• 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.
- 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
24
McAfee® Network Security Platform 6.0 Sensor HTTP Response Processing deployment
- 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
Configuration Guide.
• 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
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.
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:
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.
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
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
Configuration Guide.
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.
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
Configuration Guide.
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.
32
CHAPTER 19
Aggregate Performance 2 Gbps 2 Gbps 1 Gbps 600 Mbps 200 Mbps 100 Mbps
33
McAfee® Network Security Platform 6.0 I-series Sensor capacity by model number
34
CHAPTER 20
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
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
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
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.
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
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
Front panel LED for Not present Always on (green), normal operation.
Normal/Bypass operations
- SPAN
Front panel LED for Not present Always on (green), normal operation.
Normal/Bypass operations
- 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
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
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