Issuu on Google+

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, tabs, options, selections, and commands on the User Interface (UI) are shown in Arial Narrow bold font.

The Service field on the Properties tab specifies the name of the requested service.

Menu or action group selections are indicated using a right angle bracket.

Select My Company > Admin Domain > Summary.

Procedures are presented as a series of numbered steps.

1. On the Configuration tab, click Backup.

Names of keys on the keyboard are denoted using UPPER CASE.

Press ENTER.

Text such as syntax, key words, and values that you must type exactly are denoted using Courier New font.

Type: setup and then press ENTER.

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 are shown enclosed in angle brackets.

set Sensor ip <A.B.C.D>

Information that you must read before beginning a procedure or that alerts you to negative consequences of certain actions, such as loss of data is denoted using this notation.

Caution:

vi


McAfee® Network Security Platform 6.0

Preface

Convention

Example

Information that you must read to prevent injury, accidents from contact with electricity, or other serious consequences is denoted using this notation.

Warning:

Notes that provide related, but non-critical, information are denoted using this notation.

Note:

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

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 dataforensic 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 startup 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 halfduplex) 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, autonegotiation 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

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 Platform Configuration 10/100 port Speed/Duplex

Configuration of Switch Speed/Duplex

100 Mbps

1000 Mbps

Full-duplex

Full-duplex

100 Mbps

AUTO

Full-duplex

Resulting Sensor Speed/Duplex

Resulting Catalyst Speed/Duplex

No Link

No Link

Neither side establishes link, due to speed mismatch

100 Mbps

100 Mbps

Full-duplex

Full-duplex

Duplex Mismatch 1

100 Mbps

1000 Mbps

100 Mbps

100 Mbps

Full-duplex

Full-duplex

Full-duplex

Full-duplex

10 Mbps

AUTO

100 Mbps

100 Mbps

Half-duplex

Half-duplex

No Link

No Link

Half-duplex

10 Mbps

1000 Mbps

Half-duplex

Half-duplex

10

Comments

Correct Manual Configuration2 Link is established, but switch does not see Fast Link Pulse (FLP) and defaults to 10 Mbps halfduplex. Neither side establishes link, due to speed mismatch.


McAfee速 Network Security Platform 6.0

Configuration of Speed and Duplex settings

Explanation of CatOS show port command counters Counter

Description

Possible Causes

Alignment Errors

Alignment errors are a count of the number of frames received that do not end with an even number of octets and have a bad CRC.

These are the result of collisions at half-duplex, duplex mismatch, bad hardware (NIC, cable, or port), or a 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 frames that were transmitted or received with a bad checksum (CRC value) in the Ethernet frame. These frames are dropped and not propagated onto other ports.

These are the result of collisions at half-duplex, duplex mismatch, bad hardware (NIC, cable, or port), or a connected device generating frames with bad FCS.

Xmit-Err

This is an indication that the internal transmit buffer is full.

This is an indication of excessive input 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 buffer is full.

This is an indication of excessive 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 Collisions

Single collisions are the number of times the transmitting port had one collision before successfully transmitting the frame to the media.

This is an indication of a half-duplex configuration.

Multiple Collisions

Multiple collisions are the number of times the transmitting port had more than one collision before successfully transmitting the frame to the media.

This is an indication of a half-duplex configuration.

11


McAfee速 Network Security Platform 6.0

Counter

Configuration of Speed and Duplex settings

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 Collisions

Excessive collisions are the number of This is an indication of over-utilization 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 Ethernet controller wants to send data and the counter is incremented when there is an error in the process.

This is an indication of faulty hardware (NIC, cable, or switch port).

Runts

These are frames smaller than 64 bytes with a bad FCS value

This is an indication of the result of 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.3z1998). 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 autonegotiation 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 subinterface) 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

IPS Quarantine: Sensor will quarantine/remediate a host as per the configurations in

and all subsequent packets in the same flow. 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. â&#x20AC;˘

â&#x20AC;˘

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 Configuration Guide.

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 / Sec.

325

600

800

1200

Throughput

85 Mbps

155 Mbps

200 Mbps

310 Mbps

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 10K response each 1024-bit RSA 128-bit ARC4

I-2700

I-3000

I-4000

I-4010

Max. SSL Connections / Sec.

300

400

800

800

Throughput

150 Mbps

200 Mbps

400 Mbps

400 Mbps

19


McAfee® Network Security Platform 6.0

SSL best practices

M-2750

M-3050

M-4050

M-6050

M-8000

Max. SSL Connections / Sec.

550

1300

2700

4500

8500

Throughput

250 Mbps

600 Mbps

1200 Mbps

2 Gbps

3.8 Gbps

SSL traffic mixed with HTTP 1.1 traffic • • • •

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

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

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

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

I-3000

I-4000

I-4010

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

SSL Throughput

100 Mbps

HTTP 1.1 Throughput

1.2 Gbps

Total Throughput

1.35 Gbps

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

Supported SSL functionalities Following SSL functionalities are supported.

21


McAfee® Network Security Platform 6.0

SSL best practices

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 DiffieHellman 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

- HTTP Response Scanning Disabled

I-4000

I-3000

I-2700

I-1400

I-1200

2 Gbps

1.78 Gbps 1 Gbps

550 Mbps

195 Mbps

97 Mbps

1 Gbps

1 Gbps

430 Mbps

160 Mbps

75 Mbps

- 5 HTTP 1.1 get page requests per TCP connection with a 10K response each - HTTP Response Scanning Enabled for outbound direction

680 Mbps

- 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

- HTTP Response Scanning Disabled

M-6050

M-4050

M-3050

M-2750

M-1450

M-1250

10 Gbps 5 Gbps

3 Gbps

1.5 Gbps

600 Mbps

200 Mbps 100 Mbps

5.4 Gbps

2 Gbps

1 Gbps

500 Mbps

200 Mbps 100 Mbps

- 5 HTTP 1.1 get page requests per TCP connection with a 10K response each - HTTP Response Scanning Enabled for outbound direction

2.8 Gbps

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

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

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

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 per sec.

25,000

25,000

10,000

6,250

2,000

1,000

Concurrent SSL Flows

100,000

100,000

50,000

25,000

NA

NA

Number of SSL keys that can be stored on the Sensor

64

64

64

64

NA

NA

Virtual Interfaces (VIDS) per Sensor

1,000

1,000

1,000

100

32

16

VLAN / CIDR Blocks per Sensor

3,000

3,000

3,000

300

64

32

VLAN / CIDR Blocks per Interface

254

254

254

254

64

32

Customized attacks

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 supported UDP Flows

100,000

100,000

50,000

25,000

6,000

5,000

Supported UDP Flows

750,000

750,000

375,000

187,500

60,000

30,000

DoS Profiles

5,000

5,000

5,000

300

120

100

SYN rate (64-byte packets per second)

1,000,000

1,000,000

500,000

250,000

64,000

83,000

ACL Rules (refer to note below)

1,000

1,000

1,000

400

100

50

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

Aggregate Performance

10 Gbps

Concurrent connections

M-6050

5 Gbps

M-4050

M-3050

M-2750

M-1450

M-1250

N-450

3 Gbps

1.5 Gbps

600 Mbps

200 Mbps

100 Mbps

2 Gbps

4,000,000 2,000,000

1,500,000

750,000

250,000

80,000

40,000

250,000

Connections established per sec.

120,000

60,000

36,000

18,000

10,000

4,000

2,000

66,000

SSL Flow count maximum

400,000

200,000

150,000

75,000

25,000

NA

NA

NA

Number of SSL 64 keys that can be stored in Sensor

64

64

64

64

NA

NA

NA

Virtual Interfaces (VIDS) per Sensor

1,000

1,000

1,000

1,000

100

32

16

100

VLAN / CIDR Blocks per Sensor

3,000

3,000

3,000

3,000

300

64

32

300

VLAN / CIDR Blocks per Interface

254

254

254

254

254

64

32

254

Customized attacks

100,000

100,000

100,000

100,000

100,000

100,000

20,000

NA

Attack filters per 128,000 VIDS

128,000

100,000

100,000

100,000

40,000

20,000

NA

Attack filters per 262,144 Sensor

262,144

262,114

262,144

131,072

65,536

32,768

NA

Default number of supported UDP Flows

400,000

400,000

100,000

50,000

25,000

10,000

5,000

25,000

Supported UDP Flows

3,000,000 1,500,000

750,000

375,000

187,500

60,000

30,000

187,500

35


McAfee速 Network Security Platform 6.0

Maximum Type

M-8000

DoS Profiles

5,000

SYN rate (64byte packets per second) ACL Rules (refer to note below)

M-6050

5,000

M-series Sensor capacity by model number

M-4050

M-3050

M-2750

M-1450

M-1250

N-450

5,000

5,000

300

120

100

NA

5,000,000 2,500,000

2,000,000

1,500,000

600,000

250,000

200,000

NA

1,000

1,000

1,000

400

100

50

400

1,000

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 supported. No negotiation with peer devices.

External tap is supported; no support for internal tap. No negotiation with peer devices.

SPAN

Dongles required

Dongles not required

Inline fail-close

Dongles required on both A and B ports to fail-close

Dongles not required for both ports to fail-close

Inline fail-open (Default)

Does not require external passive Fail- Does not require external passive Failopen Kit open Kit

Inline fail-open (Active Fail-open Kit)

Supported with ports configured in fail- Supported with ports configured in failclose (no dongles) close (no dongles)

Link Failure - inline failclose

Ports fail-close and traffic is disrupted.

Ports fail-close and traffic is disrupted.

Link Failure - inline failopen

Ports are not admin disabled and traffic is disrupted

Ports are admin disabled, put into bypass, and no traffic is disrupted

Port Speed/Duplex

10/100, Full/Half

10/100/1000, Full/Half only for 10/100

Auto negotiation

Not supported

Supported and can be configured from the the Manager

Sensor Power off - inline fail-close

Ports fail-close with dongles connected; fail-open (bypass) with no dongles

Ports fail-close and traffic is disrupted.

Sensor Power off - inline fail-open

Ports fail-open (bypass), no traffic disrupted (must not have dongles connected.)

Ports fail-open, put into bypass, and no traffic is disrupted.

Warm reboot - inline failopen (CLI reboot or reboot due to error and watchdog on)

Ports are enabled and in the down state till the Sensor starts rebooting. Traffic is disrupted till then.

Ports are admin disabled and put in bypass before the Sensor reboots. No traffic is disrupted.

Warm reboot - inline failclose (CLI reboot or reboot due to error and watchdog on)

Ports remain enabled fail-close, traffic disruption till the Sensor is up

Ports remain enabled fail-close, traffic disruption till the Sensor is up

37


McAfee® Network Security Platform 6.0

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

Operating Condition/Mode

I-1200/I-1400

M-1250/M-1450

Resetconfig

Restores to default configuration (inline fail-open) and reboots

Options to either restore defaults or to retain the current port configuration are available

Port link LED interpretation - inline failopen

Normal is green and indicates up; OFF indicates down and not necessarily bypass

Green indicates up and inline; OFF indicates bypass.

Port link LED interpretation - inline failclose

OFF indicates down and traffic is disrupted

OFF indicates down and traffic is disrupted

Port link LED interpretation during reboot/Sensor power down - inline fail-open

OFF indicates - bypass and no traffic disrupted.

OFF indicates bypass and no traffic is disrupted

Port link LED interpretation during reboot/Sensor power down - inline fail-close

OFF indicates down, traffic is disrupted.

OFF indicates down and traffic disrupted.

Front panel LED for Not present Normal/Bypass operations - inline fail-open

Green indicates up and inline; OFF indicates bypass.

Front panel LED for Not present Normal/Bypass operations - inline fail-close

Always on (green), normal operation.

Front panel LED for Not present Normal/Bypass operations - SPAN

Always on (green), normal operation.

Front panel LED for Not present Normal/Bypass operations - TAP

Always on (green), normal operation.

Link Events

No support to control fail-open/bypass Has support to control failoperation open/bypass operation

Port density

I-1200 - 1A/1B, I-1400 - 1A/1B and 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 configuration panel - link status color coding

The color codes are:

The color codes are:

• • • •

• • • •

Yellow- not active Green - up Red - enabled but down Gray - disabled and down

38

1A/1B through 4A/4B

Yellow - not active Green - up Red - enabled but down Gray - disabled and down (applicable for inline fail-open only)


McAfee® Network Security Platform 6.0

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

Operating Condition/Mode

I-1200/I-1400

M-1250/M-1450

The Manager port config panel - Inline/Bypass status color coding

Not present

Four separate bypass buttons, one button per port pair:

The Manager port status at Link failure - inline failopen

Red

Gray

The Manager port status at Link failure - inline failclose

Red

Red

The Manager port status at Link failure - SPAN

Red

Red

• •

39

Green - inline Yellow - bypass


P performance issues................................................ 35

Index

policy tuning practices...................................... 15, 16

A

R rule set creation best practices .............................. 19

auto-negotiation issues .......................... 9, 10, 11, 13

B backup of data........................................................ 30

C cabling best practices............................................... 4 connectivity issues ................................................... 8 conventions ............................................................. vi

D data link errors ....................................................... 35

S Sensor capacity by model number......................... 37 Response Management......................................... 17 sensor troubleshooting issues ................................. 7 sniffer trace ............................................................ 35 speed and duplex settings ....................................... 8 SSL best practices ............................... 23, 24, 25, 26 staging sensors........................................................ 6

T technical support......................................................ix

database management best practices ....... 30, 32, 33 duplex mismatch ...................................................... 8

V

F

vulnerability assessment best practices................. 37

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 NSP Best Practices v6.0