McAfee M-1250, Network Security Platform Platform Manual

Special Topics Guide—In-line Sensor Deployment

revision 1.0

McAfee® Network Security Platform

Network Security Sensor
version 6.0

McAfee®

Network Protection

Industry-leading network security solutions

COPYRIGHT

Copyright ® 2001 - 2009 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 agree ment 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 <[e-mail]> 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. * Soft ware 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 ([e-mail]), (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 ([e-mail]), (C) 1999, 2000. *
Software copyrighted by Ronald Garcia, (C) 2002. * Software copyrighted by David Abrahams, Jeremy Siek, and Daryle Walker, (C) 1999-2001. * Softw are copyrighted by Stephen
Cleary ([e-mail]), (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 DECEMBER 2009 / Special Topics Guide—In-line Sensor Deployment

700-2381-00/ 1.0 - English

Contents

Preface ........................................................................................................... v

Introducing McAfee Network Security Platform............................................................................. v

About this Guide............................................................................................................................ v

Conventions used in this guide ..................................................................................................... v

Related Documentation.................................................................................................................vi

Contacting Technical Support......................................................................................................vii

Chapter 1 What is inline mode?................................................................... 1

Benefits of running inline............................................................................................................... 1

Chapter 2 Inline deployment walkthrough ................................................. 3

Chapter 3 Determine your high availability strategy................................. 4

Failover, or High-Availability.......................................................................................................... 4

Fail-open or fail-closed functionality.............................................................................................. 5

Chapter 4 Install and cable the Sensor....................................................... 6

Cable the Fast Ethernet monitoring ports...................................................................................... 7

Cable the Gigabit Ethernet monitoring ports................................................................................. 7

Cable a failover pair ...................................................................................................................... 7

Configure the Sensor monitoring ports.......................................................................................... 8

About Sensor port configuration.............................................................................................8

Chapter 5 Failover: configure two Sensors in inline mode .................... 11

Create a Failover Pair ................................................................................................................. 11

Download configuration, signature set, and software updates to the Sensor......................12

Chapter 6 Configure policies..................................................................... 13

Tune your policies.......................................................................................................................13

About false positives and "noise"................................................................................................14

Incorrect identification..........................................................................................................14

Correct identification; significance subject to usage policy..................................................14

Correct identification; significance subject to user sensitivity (also known as noise)...........14

Chapter 7 Block attacks ............................................................................. 16

Methods for blocking attacks....................................................................................................... 16

Block exploit traffic ...................................................................................................................... 16

How blocking works for exploit traffic...................................................................................17

Verify dropped exploit attacks using the Threat Analyzer....................................................17

Block DoS traffic.......................................................................................................................... 17

How blocking works for DoS traffic ......................................................................................18

Verify blocked DoS attacks using the Threat Analyzer........................................................18

Drop DoS Attacks from the Threat Analyzer........................................................................18

Block using ACLs........................................................................................................................18

Utilize traffic normalization .......................................................................................................... 19

Blocking based on configured TCP & IP Settings....................................................................... 20

Blocking of IP-spoofed packets................................................................................................... 20

Chapter 8 Troubleshooting........................................................................ 21

iii

Verify that traffic is flowing through the Sensor........................................................................... 21

Verify failover pair creation success............................................................................................ 21

show.....................................................................................................................................21

status....................................................................................................................................21

show failover-status .............................................................................................................22

downloadstatus ....................................................................................................................22

Index............................................................................................................. 23

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 describes the process of deploying Network Security Sensors (Sensors) in inline
mode

. The information in this guide details best practices for inline mode configuration,

information on attack blocking, and inline troubleshooting options.
This guide assumes that the reader has a working understanding of McAfee Network

Security Platform products, including McAfee Network Security Manager (nsm) and
McAfee Network Security Sensors (Sensors).

Conventions used in this guide

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

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

Arial Narrow bold

Service field on the Properties tab specifies the

The
name of the requested service.

Select My Company > Admin Domain > Summary.

v

McAfee® Network Security Platform 6.0

Convention Example

Preface

Procedures are presented as a
series of numbered steps.

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

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

Courier New

font.

Variable information that you must
type based on your specific
situation or environment is shown

italics.

in
Parameters that you must supply

are shown enclosed in angle
brackets.

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.

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

1. On the Configuration tab, click Backup.

Press ENTER.

setup and then press ENTER.

Type:

Type: S

ensor-IP-address and then press

ENTER.

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

Caution:

Warning:

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

Related Documentation

The following documents and on-line help are companions to this guide. Refer to Quick
Tour for more information on these guides

• Quick Tour

• Installation Guide

• Upgrade Guide

• Getting Started Guide

• IPS Deployment Guide

• Manager Configuration Basics Guide

• I-1200 Sensor Product Guide

• I-1400 Sensor Product Guide

• I-2700 Sensor Product Guide

• I-3000 Sensor Product Guide

Note:

vi

McAfee® Network Security Platform 6.0

• 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

• 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

• Best Practices Guide

• Troubleshooting Guide

• 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

Preface

Contacting Technical Support

If you have any questions, contact McAfee for assistance:

vii

McAfee® Network Security Platform 6.0

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

Preface

Contact Information

viii

C HAPTER 1

What is inline mode?

Inline monitoring mode provides prevention of attacks by enabling Security Administrators
to select the types of attacks/traffic to drop, thus preventing the negative end-system
impact common with today's network attacks. Inline mode is achieved when Network
Security Sensor is placed directly in the path of a network segment, becoming,
essentially, a “bump in the wire,” with packets flowing through Sensor. In this mode, the
Sensor inspects all traffic at wire-speed and can prevent network attacks by dropping
malicious traffic in real time—the Sensor actually ends the attacking transmission before it
can reach and impact the target. Preventative actions can operate at a highly granular
level, including the automated dropping of DoS traffic intended for a specific host.

When operating in inline mode, network segments are connected to two wire-matched
Sensor ports (For example: peer ports 1A and 1B), and packets are examined in real time
as they pass through the Sensor. In this mode, a packet comes in through the first
interface of the pair of the Sensor and out the second interface of the pair. The packet is
sent to the second interface of the pair unless that packet is being denied or modified by a
signature.

As of release 2.1.7, Sensor ports are configured by default for monitoring in inline mode;
that is, connected inline on a network segment (For example: between a switch and a
router or two switches). A Sensor with 2.1.7 or later software will initially come online with
its peer ports configured in pairs and in inline mode.

Note: This change will not override user-configured settings. Deployed Sensors

upgraded to 2.1.7 or later and will retain their user-configured settings.

Benefits of running inline

The benefits to using Sensors in inline mode are:

Protection/Prevention. Prevention is a feature unique to inline mode. When running inline,

•

a Sensor can drop malicious packets and not pass them through the network. This

acts sort of like an “adaptive firewall,” with your detection policy dictating what is

dropped. Furthermore, when dropping packets, Network Security Platform is very

precise and granular. The Sensor can drop only those packets it identifies as

malicious or all of the packets related to that flow (a choice that is user configurable).

Packet “scrubbing.” In addition to dropping malicious traffic, Network Security Platform

•

can

attacker may be using to try to evade detection. Current IDS products are susceptible

to these techniques, and an example of this attempt is IP fragment and TCP segment

overlaps. The Sensor can reassemble the IP fragments and TCP segments and

enforce a reassembly mode of the user’s choice to accept either the old or the new

data.

Processing at wire-speed. Sensors are able to process packets at wire rates.

•

scrub—or normalize—traffic to take out any ambiguities in protocols that the

1

McAfee® Network Security Platform 6.0

In inline mode, the Sensor logically acts as a transparent repeater with minimal

latency for packet processing. Unlike bridges, routers, or switches, the Sensor does

not need to learn MAC addresses or keep an ARP cache or a routing table.

What is inline mode?

2

C HAPTER 2

Inline deployment walkthrough

Deploying your Sensor inline consists of the following steps:

1 Determine the optimal high availability strategy for the Sensor. This indicates how you

would like the Sensor to behave when it fails (i.e., fail-open, fail-closed, or support a

failover/high-availability configuration).

2 Physically install the Sensor on your network, and cable the Sensor for the

deployment mode of your choice. For example, cable one Sensor standalone (to fail-

open, if applicable, or configure two Sensors as part of a failover pair).

3 Configure the Sensor monitoring ports.
4 Configure one or more policies for the inline ports.
5 Understand how blocking works, and configure blocking.

Note: You must use McAfee® Network Security Manager (Manager) to configure

most aspects of your Sensor(s), including port configuration, pairing two Sensors for
failover operation, and configuring and applying policies to detect and drop
malicious traffic.

3

C HAPTER 3

Determine your high availability strategy

impact of a Sensor outage and its effect on your network. In inline mode, the Sensor does
become a single point of failure. McAfee® Network Security Platform provides a variety of
options to minimize network downtime in the event of Sensor failure. For example,
Sensors support complete stateful failover, delivering the industry's first true high­availability IPS deployment, similar to what you’d find with firewalls. If you’re running the
Sensor in inline mode, McAfee recommends that you deploy two Sensors redundantly for
failover protection.

The following deployment options are available:

• Failover, or High-Availability.

• Fail-open or fail-closed functionality.

 Fail-open with external hardware.

Before you move your McAfee® Network Security Sensor (Sensor) inline, consider the

 Fail-open with the Layer 2 Passthru (L2) feature

Failover, or High-Availability

Where redundancy is an essential requirement, it is best practice to implement Network
Security Platform 'high-availability' configuration. When running Sensors inline, this option
is available to an identical pair of Sensors (same model, software image, signature set)
deployed redundantly in inline mode. Both Sensors in the pair are active and share full
state, so that the information on both Sensors is always current. Latency is very minimal;
than other devices providing failover, such as, firewalls.

The keys to the Network Security Platform failover architecture are as follows:

 Sensors configured for failover confirm a “heartbeat” once each second.

 Sensors configured for failover share flow information in real time.

 Sensors are invisible at Layer 2 and above; the monitoring ports do not have MAC

addresses.

As a result, you do not have to worry about Layer 2 and 3 topology changes when you
introduce Network Security Platform failover into the environment, and in the unlikely event
of a Sensor failure, failover is instantaneous and connection state is maintained.

All Sensor models support failover.
This subject is discussed in detail in the document

Availability

Special Topics Guide—Sensor High

.

4

McAfee® Network Security Platform 6.0

Fail-open or fail-closed functionality

Sensor ports deployed in inline mode have the option of failing open or closed. Similar in
terminology to firewall operation, ports failing open allow traffic to continue to flow. Thus,
even if the ports fail, your Sensor does not become a bottleneck. However, monitoring
ceases, allowing all traffic to continue to flow through the network, which can allow attacks
to impact systems in your network. When ports are configured to fail-closed, the Sensor
does not allow traffic to continue to flow, thus the failed ports become a bottleneck,
stopping all traffic at the Sensor.

Note: There are security consequences when the Sensor is in bypass mode. When

bypass mode is on, the traffic bypasses the Sensor and is not inspected; therefore,
the Sensor cannot prevent malicious attacks.

There are two fail-open options available:

Fail-open with external hardware

Inline fail-open mode, available for both 10/100 and GE links, guarantees that data will be
forwarded over a monitored link in the event that the Sensor's processes are temporarily
stopped for upgrades or when the Sensor fails. This guarantee is delivered for 10/100 port
pairs using an internal mechanical tap that connects the monitoring ports when hardware
failure is detected. The 10/100 configurations is a choice made per port pair. The Gigabit
fail-open implementation involves the use of the external Gigabit Fail-Open Kit, which
includes a Bypass Switch.

Determine your high availability strategy

Caution 1: Note that Sensor outage breaks the link connecting the devices on

either side of the Sensor and requires the renegotiation of the network link

between the two peer devices connected to the Sensor.

Caution 2: Depending on the network equipment, this disruption introduced by

the renegotiation of the link layer between the two peer devices may range from

a couple of seconds to more than a minute with certain vendors’ devices.

Caution 3: A very brief link disruption may also occur while the links between

the Sensor and each of the peer devices are renegotiated to place the Sensor

back in inline mode. This outage, again, varies depending on the device, and

can range from a few seconds to more than a minute.

Fail-open with the Layer 2 Passthru (L2) feature

Layer 2 Passthru is also known as “software fail-open.” The L2 feature, when triggered,
causes traffic to flow through the Sensor without being copied to the detection engine.

Note: The Layer 2 Passthru option is provided specifically to handle internal

Sensor errors; it is not provided as an alternative to other HA options, such as

the Fail-Open kit.

5

C HAPTER 4

Install and cable the Sensor

on how to set up the Sensor and configure it to communicate with the McAfee

Each McAfee® Network Security Sensor (Sensor) model are shipped with documentation

®

Network
Security Manager Manager. This documentation consists of model-specific Product
Guides and Quick Start Guides and a model-generic Sensor Configuration Guide. These
documents provide detailed installation, configuration and cabling instructions for your
Sensor.

You may need special equipment depending on your deployment strategy. Certain Sensor
models have Fast Ethernet (FE) ports. Each FE port requires a Network Security Platform
dongles for In-line Fail-closed mode. Dongles are included with FE-port Sensors. Gigabit
Ethernet (GE) port Sensors require the optional Gigabit Fail-Open Bypass Kit (Optical
Single-mode, Optical Multimode, or Copper), sold separately, for In-line Fail-Open mode.

The following table shows the monitoring port types for each Network Security Sensor
model.

Sensor Monitoring port

type

Fail-open behavior

I-4010 GE ports Fail-closed; require external Fail-Open Kit
I-4000 GE ports Fail-closed; require external Fail-Open Kit
I-3000 GE ports Fail-closed; require external Fail-Open Kit
I-2700 FE ports

GE ports

Fail-open; require no extra hardware

Fail-closed; require external Fail-Open Kit
I-1400 FE ports Fail-open; require no extra hardware
I-1200 FE ports Fail-open; require no extra hardware

Sensor Monitoring port

type

Fail-open behavior

M-8000 GE ports Fail-closed; require external Fail-Open Kit
M-6050 GE ports Fail-closed; require external Fail-Open Kit
M-4050 GE ports Fail-closed; require external Fail-Open Kit
M-3050 GE ports Fail-closed; require external Fail-Open Kit

M-2750 GE ports Fail-closed; require external Fail-Open Kit
M-1450 GE ports Fail-closed and Fail-Open built-in
M-1250 GE ports Fail-closed and Fail-Open built-in
N-450 GE ports Fail-closed; require external Fail-Open Kit

6

McAfee® Network Security Platform 6.0

Cable the Fast Ethernet monitoring ports

The FE ports available on some Sensor models fail-open and require no extra hardware;
simply connect your cables to a port pair (For example: 1A-1B).

Fail-closed mode for FE ports requires use of the fail-closed dongles on each connecting
cable of the port pair. The fail-closed dongles provided with the Sensor are designed to
complement 10/100 monitoring port functionality. You plug the dongles into a Sensor’s
10/100 monitoring port, and then connect a Cat 5/Cat 5e cable to the dongles.

Cable the Gigabit Ethernet monitoring ports

Fail-Open mode for Gigabit Ethernet (GE) ports requires use of the external Gigabit Fail­open Kit. This kit includes a Gigabit Bypass Switch and an adaptor that connects the
switch to the Sensor.

Note: Fail-closed mode for GE ports requires no extra hardware; simply connect

your fiber cables to the GE port pair (For example: 1A-1B).

Install and cable the Sensor

For information on how to cable the Sensor with a Gigabit Fail-Open Kit, see the
documentation that accompanies the kit. For example, the Gigabit Copper Kit includes the

Gigabit Copper Fail-Open Kit Guide.

Cable a failover pair

Failover requires connecting the paired Sensors via an interconnection cable or cables.
Communication between paired Sensors maintains the failover heartbeat and state
information.

There is no standard heartbeat port across all the Sensor models. The port or ports you
use to connect the two Sensors depends on the Sensor model. The Sensor models and
their failover interconnection ports are described below.

Sensor Failover port

I-4010 HA1 and HA2 (6A and 6B)
I-4000 2A and 2B
I-3000 HA1 and HA2 (6A and 6B)
I-2700 4A
I-1400 Response port 1 (R1)
I-1200 Response port 1 (R1)

7

McAfee® Network Security Platform 6.0

Sensor Failover port

M-8000 HA1 and HA2 (3A and 3B)
M-6050 HA1 (4A). Note that HA2 (4B)

M-4050 2A
M-3050 2A
M-2750 10A
M-1450 4A
M-1250 4A
N-450 10A and 10B

The following is a quick summary of the rules for cabling:

• Cabling for the heartbeat connection must be direct; you may not cable the heartbeat
through another network device, such as a switch.

• When 2 ports are used on each Sensor for the heartbeat connection, always cable
between identical port names. For example, port 2A on Sensor 1 must be cabled to
port 2A on Sensor 2 (not 2B).

remains unused

Install and cable the Sensor

Configure the Sensor monitoring ports

Once you have installed and cabled the Sensor(s), you must configure the Sensor’s ports.
The following list summarizes the port configuration requirements:

• The port configuration must match the Sensor cabling; for example, if you cable the
port with no Fail-Open Kit, the port must be configured as In-line, Fail-closed, not Fail­open.

• The ports must be set to “In-line,” AND to “Fail-open” or “Fail-closed” as appropriate

• The ports must be enabled.

About Sensor port configuration

Before you configure the Sensor ports, you must have installed the Sensor and added to
the Manager interface as described in the

Configure inline mode for a single Sensor
This section contains recommendations for deploying a single Network Security Sensor in

inline mode.

Note: Configuration for a fail-open kit is described in the fail-open kit documentation.

For example, to configure the Sensor to work with the copper fail-open kit, see the

Gigabit Copper Fail-Open Bypass Kit Guide.

To view/configure the settings of your monitoring ports, do the following:

Sensor Configuration Guide.

8

McAfee® Network Security Platform 6.0

1 In the Manager interface, select / My Company / Device List / Sensor_Name > Physical Device >

Port Settings

2 Click a numbered port (For example: 4A) from

window displays current port settings.

Install and cable the Sensor

.

Monitoring Ports. View Monitoring Port

Figure 1: Verifying Ports and Bypass Switch Status for GE In-line Fail-Open Mode

3 Set the Administrative Status to Disable (off).
4 Select the Port

Speed.

5 Do one of the following:

 For inline fail-closed operation, select
 For inline fail-open operation, select

C

onfirm (Yes) that you have already connected the bypass switch and controller or

In-line Fail-closed (Port Pair) as the Operating Mode.

In-line Fail-open (Port Pair) as the Operating Mode.

control cable

Figure 2: GE Interface Optical Bypass Switch connection confirmation

9

McAfee® Network Security Platform 6.0

6 Select the area of your network to which the current port is connected: Inside (traffic

initiating internally, destined for the external network) or
externally, destined for the internal network).

7 Set the
8 Click
9 Click

OK.
Commit Changes.

10 Repeat for any other ports you need to configure.
11 Download the changes to your Sensor as described in

signature set, and software updates to the Sensor.

Administrative Status to Enable (on).

Install and cable the Sensor

Outside (traffic initiating

Download configuration,

(on page 12)

10

C HAPTER 5

Failover: configure two Sensors in inline mode

In a failover configuration, the two Sensors are placed inline, connected to each other via
cables, and configured to act as a
them in order to maintain state. Sensor A copies the packets received on its monitoring
ports to Sensor B using the interconnection ports and vice versa. Since both Sensors see
all traffic and build state based on it, their state information is synchronized at all times.

All packets are seen by both Sensors (when both are operational); however, only one
Sensor in the pair raises an alert whenever an attack is detected.

When deploying the two Sensors in failover mode, you must ensure the following:

• The Sensor interconnection ports must be cabled appropriately so the two Sensors
can communicate.

• Both Sensors must be of the identical model type, and have the same signature set
and software loaded. (One of the two Sensors may be a “Fail-over (FO)” Sensor
model, which is a fully functional Sensor limited to operation as part of a failover pair;
it cannot operate standalone.)

• Additionally, all ports on both the Sensors must be configured to run in inline mode.

Note: The exceptions are the ports that will be used for the heartbeat. For example,

on the I-2700, you do not need to explicitly configure ports 4A/4B to run in inline
mode because 4A will be automatically configured for the heartbeat and 4B will be
disabled when the failover pair is created.

Failover Pair. All traffic is copied and shared between

Create a Failover Pair

You can create a Failover Pair using McAfee® Network Security Manager (Manager)
System Configuration tool. Failover Pair creation happens in real time; there is no need to
explicitly update the configuration.

Note 1: By design, the configuration of the primary Sensor is copied to the

secondary Sensor, overwriting the original configuration on the secondary. If you
intend to configure both Sensors to fail-closed or fail open, you need only configure
the ports on the Sensor you intend to designate as the primary during the Failover
Pair creation.

Note 2: If you intend to have one Sensor fail-closed and the other fail open,

however, you must revisit the Port Configuration page of each Sensor after Failover
Pair creation and make the appropriate changes.

11

McAfee® Network Security Platform 6.0

1 Click / My Company / Device List > Device List > Failover Pairs.
2 Click

New. The Add a Failover Pair dialog opens.

3 Select the Sensor
4 Type a failover pair
5 Select the Primary Sensor Template Device from the drop-down menu.
6 Select the Secondary Sensor
7 Click

Create. Upon saving, a message informs you that the failover pair creation will

take a few moments.

8 Click

OK. The new failover pair appears as a child node of the Sensors node under

which it was created. That node contains icons for each interface taking part in the
failover process. Also within the Failover Pair node is a list of its member Sensors.

Most configuration options are hereafter done at the Failover Pair node level. For example,
you can now apply a policy, update the configuration, or even create an ACL rule at the
Failover Pair node level and it will automatically propagate to each of the member
Sensors. On the other hand, you still configure the port settings, view interface statistics,
and upgrade the Sensor software at the Sensor node level. The easiest way to get a feel
for the Failover Pair configuration process is to examine the user interface once the Pair
has been created.

Note: The Sensors must be running the same software version to run in a failover

configuration. However, you upgrade software at a Sensor level, even those that are
part of a Failover Pair. The recommended upgrade procedure is to therefore
upgrade the software version on both Sensors, and then reboot them sequentially.
That is, once the upgrade process is complete on both, reboot (for example) the
secondary, confirm that it has rebooted without error, and reboot the primary.

Model type. Both Sensors in a failover pair must be the same model.

Name that will uniquely identify the grouping.

Peer Device from the drop-down menu.

Failover: configure two Sensors in inline mode

Download configuration, signature set, and software updates
to the Sensor

After configuring your ports for inline mode, setting the TCP/IP parameters, and
customizing and applying policy, you will need to download this configuration to the Sensor
in order for all of your changes to be active. This process is described in detail in the
section

• Configuration changes, including port configuration, policy, and signature set updates:

• Software updates only: / My Company / Device List / Sensor_Name > Physical Device > Software

Updating the Configuration of a Sensor in the Sensor Configuration Guide.

/ My Company / Device List / Sensor_Name> Physical Device > Configuration Update

Upgrade

12

C HAPTER 6

Configure policies

(Sensor) will perform. McAfee

Your policy determines what traffic analysis your McAfee® Network Security Sensor

®

Network Security Platform provides a number of policy
templates to get you started toward your ultimate goal: prevent attacks from damaging
your network, and limit the alerts displayed in the Threat Analyzer to those which are valid
and useful for your analysis.

There are two stages to this process: initial

policy configuration and policy tuning. Policy
tuning is renowned to be a tedious task. However, because networks and attacks
constantly evolve, the policy tuning process is never truly complete. Instead, you might
equate it to a disk defragmentation; the more often you do it, the less time each check
takes. The ultimate goal of policy tuning is to eliminate

false positives and noise and avoid

overwhelming quantities of legitimate, but anticipated alerts.

Tune your policies

The default McAfee Network Security Platform policy templates are provided as a generic
starting point; you will want to customize one of these policies for your needs. So the first
step in tuning is to clone the most appropriate policy for your network and your goals, and
then customize it. (You can also edit the policy directly.) This process is involved, and is
discussed in detail in IPS Configuration Guide. Some things to remember when tuning your
policies:

• We ask that you set your expectations appropriately regarding the elimination of false

positives and noise. A proper Network Security Platform implementation includes
multiple tuning phases. False positives and excess noise are routine for the first 3 to 4
weeks. Once properly tuned, however, they can be reduced to a rare occurrence.

• When initially deployed, Network Security Platform frequently exposes unexpected

conditions in the existing network and application configuration. What may at first
seem like a false positive might actually be the manifestation of a misconfigured router
or Web application, for example.

• Before you begin, be aware of the network topology and the hosts in your network, so

you can enable the policy to detect the correct set of attacks for your environment.

• Take steps to reduce false positives and noise from the start. If you allow a large

number of “noisy” alerts to continue to sound on a very busy network, parsing and
pruning the database can quickly become cumbersome tasks. It is preferable to all
parties involved to put energy into preventing false positives than into working around
them. One method may be is to disable all alerts that are obviously not applicable to
the hosts you will protect. For example, if you use only Apache Web servers, you may
wish to disable IIS-related attacks.

13

McAfee® Network Security Platform 6.0

About false positives and "noise"

The mere mention of false positives always causes concern in the mind of any security
analyst. However, false positives may mean quite differently things to different people. In
order to better manage the security risks using any IDS/IPS devices, it's very important to
understand the exact meanings of different types of alerts so that appropriate response
can be applied.

With Network Security Platform, there are three types of alerts that are often taken as
“false positives:”

• Incorrectly identified events

• Correctly identified events subject to interpretation by usage policy

• Correctly identified events uninteresting to the user.

Incorrect identification

These alerts typically result from overly aggressive signature design, special
characteristics of the user environment, or system bugs. For example, typical users will
never use nested file folders with a path more than 256 characters long; however, a
particular user may push the Windows' free-style naming to the extreme and create files
with path names more than 1024 characters. Issues in this category are rare. They can be
fixed by signature modifications or software bug fixes.

Configure policies

Correct identification; significance subject to usage policy

Events of this type include those alerting on activities associated with Instant Messaging
(IM), Internet Relay chat (IRC), and Peer to Peer programs (P2P). Some security policies
forbid such traffic on their network; for example, within a corporate common operation
environment (COE); others may allow them to various degrees. Universities, for example,
typically have a totally open policy for running these applications. Network Security
Platform provides two means by which to tune out such events if your policies deem these
events uninteresting. First, you can define a customized policy in which these events are
disabled. In doing so, the Sensor will not even look for these events in the traffic stream to
which the policy is applied. If these events are of interest for most of the hosts except a
few, creating attack filters to suppress alerts for the few hosts is an alternative approach.

Correct identification; significance subject to user sensitivity
(also known as noise)

There is another type of event that you may not be interested in, due to the perceived
severity of the event. For example, Network Security Platform will detect a UDP-based
host sweep when a given host sends UDP packets to a certain number of distinct
destinations within a given time interval. Although you can tune this detection by
configuring the threshold and the interval according to their sensitivity, it's still possible that
some or all of the host IPs being scanned are actually not live. Some users will consider
these alerts as
activity. Another example of noise would be if someone attempted an IIS-based attack
against your Apache Web server. This is a hostile act, but it will not actually harm anything
except wasting some network bandwidth. Again, a would-be attacker learns something he

noise, others will take notice because it indicates possible reconnaissance

14

McAfee® Network Security Platform 6.0

can use against your network: the fact that the attack failed can help him zero in on the
type of Web server you use. Users can also better manage this type of events through
policy customization or installing attack filters.

The noise-to-incorrect-identification ratio can be fairly high, particularly in the following
conditions:

• The configured policy includes a lot of Informational alerts, or scan alerts which are

based on request activities (such as the All Inclusive policy)

• Deployment links where there is a lot of hostile traffic, such as in front of a firewall

• Overly coarse traffic VIDS definition that contains very disparate applications. For

example: a highly aggregated link in dedicated interface mode

Users can effectively manage the noise level by defining appropriate VIDS and customize
the policy accordingly. For dealing with exceptional hosts, such as a dedicated pentest
machine, attack filters can also be used.

Configure policies

15

C HAPTER 7

Block attacks

The ability to drop and deny is available only with a Sensor running in inline mode. The
most efficient way to block exploits is to customize one or more of McAfee
Security Platform’s
Security Platform’s pre-configured policies includes this functionality by default. The

Inline IPS policy

to the Manager. This policy contains a number of attacks that Network Security Platform
has categorized as “Recommended For Smart Blocking” (RFSB), and which are pre­configured with the “Drop attack packets” response.

With other provided policies, the default Sensor response is to send alerts and log
packets.

The first step towards prevention is typically to block attacks that have not caused false
positives, have a high severity level, and have a low benign trigger probability. When you
know which attacks you want to block, you can configure your policy to perform the “Drop
attack packets” response for those attacks.

IPS Policies to pro-actively drop malicious traffic. One of McAfee Network

is automatically applied to Sensor interfaces when the Sensor is first added

®

Network

Default

Methods for blocking attacks

The Network Security Platform IPS offers a variety of ways to block malicious traffic.
These options include the following:

• Block exploit traffic (based on policy configuration)

• Block DoS traffic (behavior-based detection)

• Block using ACLs (based on configured ACL rules)

• Utilize Network Security Platform’s traffic normalization feature—block based on

configured TCP flow violation (out-of-order packets, deny…)

• Block IP-spoofed packets (configured)

Tip: Attack filters can be configured to override the blocking criteria—to permit

particular source IPs, for example.

Note: Each of the options listed is described at a high-level in this document. For

step-by-step procedures on how to perform the tasks described, see the IPS

Configuration Guide

Block exploit traffic

Exploit refers to attacks that are discovered through a set of parameters, or rules, that are
matched against data within a packet.

.

Signatures, specific strings used to match data in

16

McAfee® Network Security Platform 6.0

offending packets, are the key method in discovering an exploit. An attack can have
multiple signatures; thus, enabling more than one chance at attack detection.

Using the Policy Editor, you can select a specific attack(s) to block by selecting Drop
Packets from the
information on this procedure, see

How blocking works for exploit traffic

• The Sensor applies the configured inbound or outbound policy depending on the

traffic direction, which is determined via the Sensor cabling and port configuration.

• The Sensor analyzes the traffic and, based on the policy, determines whether the

traffic is “good” (does not match an attack configured in the policy) or “bad” (matches
an attack configured in the policy). If the traffic is bad, the Sensor then applies the
configured “drop packets” action. When Network Security Platform identifies a
malicious flow, it blocks only the flow; not all the traffic from the source IP (Sensor
behavior is unlike that of a firewall).

• For UDP and ICMP traffic, only the attack packet is blocked. With TCP traffic, the

entire attack flow is blocked; we recommend that you also configure a TCP Reset
action in the policy to reset the flow.

/ My Company / IPS Settings > Policies > IPS Policies section. For more

IPS Configuration Guide.

Block attacks

Note: When inline, the TCP resets always go out the inline ports. Response ports

are used when the device is configured for tap or span mode.

Verify dropped exploit attacks using the Threat Analyzer

The Alert Result Status graph within the Threat Analyzer's Consolidated View displays the
results of detected attacks as determined by target response (i.e., Successful, Failed) or
Network Security Platform action (i.e., Blocked). “Blocked” specifically refers to the attacks
that have been dropped due to policy response settings. Within a Threat Analyzer query,
you can see the number of attacks that have been blocked during the query's time period.

• The result status “blocked” will increment for each blocked attack.

• If you drill down by “Status” in a particular alert, the result status will show as

“Blocked.”

Block DoS traffic

Denial-of-Service (DoS) attacks interrupt network services by flooding a system or host
with spurious traffic, which can overflow your system buffers and force you to take the
system offline for repairs. Sensors support both Learning- and Threshold-based
capabilities for combating DoS attacks. The Sensor uses complex algorithms to
differentiate the bad DoS packets from good packets, and drop the bad packets when
running in inline mode.

Note: The Sensor must be in detection mode to detect and block attacks.

17

McAfee® Network Security Platform 6.0

How blocking works for DoS traffic

A DoS policy applies to inbound, outbound, and bidirectional traffic. Inbound traffic is that
traffic received on the port marked “Outside” (that is, originating from outside the network)
in inline mode. Typically inbound traffic is destined to the protected network, such as an
enterprise intranet.
is on the port marked “Inside” (that is, originating from inside the network) in inline mode.

Bidirectional attacks reflect changes in the distribution of ECHO requests and replies in
both inbound and outbound. For example, if the Sensor normally sees 50% inbound
replies and 50% outbound replies, but then the distribution changes to 70%/30%, the
change might raise an alert.

Note: There are also Learning Mode attacks that do not have a directional

association, specifically ICMP ECHO Anomaly and TCP Control Anomaly. Note that
these attacks cannot be blocked.

The Sensor applies the outbound or inbound DoS policy depending on the traffic direction
(which is determined via the Sensor cabling and port configuration). The “Drop attack
packets” response action must be enabled by traffic type (protocol type) within the DoS
policy.

When the Sensor detects an attack traffic condition, the block action will persist until the
attack condition ends and will repeat whenever the attack condition is present.

Outbound traffic is that traffic sent from a system in your intranet, and

Block attacks

Verify blocked DoS attacks using the Threat Analyzer

Alerts reflecting a DoS condition continue to be sent to the Threat Analyzer for the duration
of the attack.

In Threat Analyzer, the result status displays “Blocking activated” for the duration of the
attack condition.

Drop DoS Attacks from the Threat Analyzer

The IPS Policy Editor enables you to selectively drop DoS Learning Mode attacks, but in
the event you have not set the dropping response, the Threat Analyzer provides the ability
to drop further DoS attacks after a recent attack has been detected.

Block using ACLs

Access Control List (ACL) consists of ordered rules for permitting and denying traffic from

reaching a Sensor’s inspection engine and continuing on through the network. ACLs
complement policies and attack filters to help tune a deployment. You can use ACLs with a
Sensor in inline mode to drop or deny traffic from or to specific hosts or within a range of
hosts, or traffic that meets particular requirements such as protocol type or port.

Some details about ACLs:

• ACL rules match on a combination of source IP, destination IP, protocol, and

destination port.

18

McAfee® Network Security Platform 6.0

• Each rule has a response action associated with it. Response actions include permit,

drop (discard silently), and deny (send a TCP reset to the source).

• Rules are analyzed from the top down and work on a first-match basis. That is,

Network Security Platform responds according to the response action associated with
the first rule it matches - no subsequent rules are considered. It follows that the most
specific rules should be added to the top of the list.

• Network Security Platform ACLs are stateful. That is, connections are tracked, so if

you explicitly permit outbound HTTP requests, for example, inbound HTTP responses
that are part of the same flow are implicitly permitted as well.

• Knowing your traffic is important before configuring an ACL. There are cases where

you may have to set two rules where one rule might seem sufficient. For example,
some FTP servers are configured to send AUTH requests to the client immediately
after the initial TCP handshake. AUTH requests use IDENT, thus are negotiated on a
different port (113). If you apply an outbound “deny all” ACL rule, the FTP connection
originated inbound takes a while to get established. This is because the AUTH
request (SYN) is outbound and is denied by the ACL rule.

• ACLs follow strict rules of inheritance. ACL rules created at the Sensor level are

inherited at the physical port/port pair and interface level. Port-level rules are inherited
by the interface and sub-interface levels. Interface rules only apply to interfaces, and
sub-interface rules only apply to sub-interfaces.

Block attacks

Utilize traffic normalization

Traffic normalization—available when the system is operating in inline mode—removes
any traffic protocol ambiguities, protecting the end systems by cleaning up potentially
harmful traffic in real time. Traffic normalization consists of two Sensor techniques:
cleaning up malformed packets, and dropping illegal packets—for example, packets where
the IP header is smaller than 20bytes, IP fragments smaller than 64K, and so on. Traffic
normalization also thwarts any attempts to evade the system while boosting attack
detection accuracy. This feature, also known as protocol scrubbing or packet scrubbing
allows Network Security Platform systems to prevent hackers from
system. Often attackers send abnormal traffic in the hope that the end system responds in
a way that allows the attacker to determine what environments and technologies are
deployed at a particular site. This makes it easier to launch subsequent attacks against
known vulnerabilities in host network hardware or software resources.

Specifically, when enabled, normalization does the following:

• When the TCP Timestamp option is not negotiated in the SYN/SYN_ACK packet for a

connection, but appears in any of the packets for the rest of the connection, the TCP
Timestamp is removed from the headers of these packets.

• The MSS option is permitted only in the SYN/SYN_ACK packets for a TCP

connection. If any other packets in the flow contain the MSS option, the Sensor
removes it.

In both cases, Network Security Platform performs an incremental checksum of the TCP
header and regenerates the CRC integrity check value.

Note: Packet scrubbing must be manually enabled (navigate to / My Company / IPS

Settings / Sensor_Name > Advanced Scanning > TCP Settings and enable Normalization On/Off
Option

); packet dropping of illegal packets is default Sensor behavior.

fingerprinting a host

19

McAfee® Network Security Platform 6.0

Blocking based on configured TCP & IP Settings

Network Security Sensors have the intelligence to keep a number of TCP/IP connection
parameters, as well as complete state information. The

Sensor_Name > Advanced Scanning > TCP Settings
Advanced Scanning > IP Settings

as the number of supported UDP flows, the TCB inactivity timer length, and accepting old
data or new data for TCP or IP overlaps. All of the TCP/IP Settings parameters relate to
the handling of monitored transmissions while in inline mode. You can use these settings
to deny or drop certain traffic.

Two of the more notable parameters are as follows:

Cold Start Drop Action: When starting a Sensor for the first time, you can decide to allow

•

(forward) or drop all packets that do not have a flow control block recognized by the
Sensor. You have the choice to Forward Flows or Drop Flows.

•

TCP Flow Violation: How to handle a packet received for a connection that doesn't exist,

such as an ACK packet when no SYN for a connection has been received. Choices
are:



Permit: reassembles out-of-order packets and processes them. It forwards traffic if

strict TCP protocol violations and if State Not Established on Sensor fails.



Permit out-of-order: allows out of order packets to continue to transmit without

processing.

Note: 'Permit out-of-order' should be selected if your Sensor is deployed in an

asymmetrical environment in order to avoid session dropping.

 Deny: checks the flow for strict TCP protocol violations; if it discovers violations, it

drops the packet and reassembles out-of-order packets.



Deny no TCB (Deny if State Not Established): drops the session only if state has not

been established. It forwards traffic only if strict TCP protocol violations fails.

/ My Company / IPS Settings /

Block attacks

and / My Company / IPS Settings / Sensor_Name >

action enables you to configure 16 TCP/IP parameters, such

Blocking of IP-spoofed packets

When enabled, the anti-spoofing option will drop packets containing invalid source IP
addresses. Network Security Platform determines the validity of a source IP by comparing
it against a configured list of internal networks. Thus, as a pre-requisite, you must define
CIDR blocks for each and every internal network that will send traffic through the Sensor
interface in question. Without a comprehensive set of CIDR blocks defined, especially if
outbound anti-spoofing is enabled, Network Security Platform may block valid packets.

Anti-spoofing is available only for Sensors in inline mode.
The way in which Network Security Platform determines the validity of a packet depends

directly on the direction of that packet, as follows:

Inbound: When a packet arrives on the outside interface, its source IP is compared to

•

the CIDR blocks associated with the interface. If the source IP of the inbound packet
matches one of the CIDR blocks, the packet is considered spoofed and dropped.

• Outbound: When a packet arrives on the inside interface, its source IP is compared to

the CIDR blocks associated with the interface. If the source IP of the outbound
packet does not match one of the CIDR blocks, the packet is considered spoofed and
dropped.

20

C HAPTER 8

Troubleshooting

This section contains information that may help you solve problems you may experience
with your inline mode deployment.

Verify that traffic is flowing through the Sensor

For any inline Sensor, you can look at the statistics for each Sensor port to confirm that
traffic is properly flowing through it, by launching the Threat Analyzer.

Note: For step-by-step procedures on verifying how to verify traffic is flowing

through the Sensor, see the System Status Monitoring Guide.

Verify failover pair creation success

If you have configured a failover pair prior to cabling the heartbeat connection, you will
notice Failover peer status errors appearing on the
the heartbeat connection. These messages will not appear if the two communicate
properly.

The status of the communication between the Sensors can be monitored on the

View Details

The Network Security Sensor command line interface (CLI) is a valuable tool for verifying
correct configuration as well as diagnosing possible problems.

page of the Manager interface or directly from the CLI of either Sensor.

Operational Status page until you cable

Sensors >

Note: See full list of Sensor CLI commands in the CLI Guide.

show

Shows all of the current configuration settings on the Sensor. You can use the show
command to verify information such as the Sensor's management port IP address, the
version of software currently running, McAfee® Network Security Manager's (Manager's) IP
address, and the gateway IP address that connect the Sensor to the Manager.

status

Shows Sensor system status, such as Operational Status, total number of alerts detected,
and total number of alerts sent to the Manager. The status command is useful for verifying
that trust has been established between the Sensor and the Manager, and for verifying the
Sensor is detecting attacks and sending alerts to the Manager.

21

McAfee® Network Security Platform 6.0

• If trust is not established, check the Sensor name and shared secret on both the

Sensor and the Manager.

• If the Sensor is not seeing attacks for a significant period of time, check status for

Sensor health and established trust. Also, check your port configuration and cabling
setup.

show failover-status

This command shows whether failover is enabled on the Sensor and the status of the peer
Sensor. You can run the command from either Sensor. The output includes the fields
Failover Enabled (must be YES) and Peer Status (must be UP). The former indicates
whether the Sensor on which the command is issued has been configured to be part of a
Failover Pair, and the latter shows the current state of the communication between the two
Sensors.

downloadstatus

This command displays the status of various download/upload operations: signature,
software image, and DoS profile downloads (from Manager to Sensor) and DoS profile and
debug trace uploads (from Sensor to Manager).

Troubleshooting

Lists the number of times you have performed the operation, status of your previous
attempt to perform the operation (including-if the operation failed-the cause of failure), and
the time the command was executed.

22

failover port.............................................................. 7

false positives ........................................................ 14

Index

Fast Ethernet Ports.............................................. 6, 7

1

10/100 monitoring port functionality.........................7

A

Access List.................................................. See ACL

ACL........................................................................18

Administrative Status ...............................................8

Alert Result Status graph.......................................17

B

blocking DoS traffic..........................................17, 18

blocking exploit attacks..........................................17

bypass mode............................................................5

Bypass Switch..........................................................5

C

cabling failover pair..................................................7

Cold Start Drop Action ...........................................20

configuring policies for failover pair........................ 13

conventions.............................................................. v

G

Gigabit Ethernet Ports.......................................... 6, 7

Gigabit fail-open implementation ............................. 5

H

heartbeat.................................................................. 4

I

inline fail-open mode................................................ 8

in-line mode ............................................................. 1

M

monitoring ports....................................................... 8

N

noise ...................................................................... 14

noise-to-incorrect-identification ratio...................... 14

O

optimal high availability strategy.............................. 3

D

detection mode.......................................................17

downloading configuration .....................................12

dropping attack packets.........................................16

F

fail-closed.................................................................5

fail-closed dongle.....................................................7

fail-open behavior.....................................................6

fail-open functionality ...............................................5

fail-open with external hardware ..............................5

fail-open with the Layer 2 Passthru (L2) ..................4

failover pair node....................................................11

P

packet scrubbing...................................................... 1

policy tuning........................................................... 13

port configuration................................................. 7, 8

R

renegotiation............................................................ 5

S

sensor outage.......................................................... 5

software fail-open..................................................... 5

T

technical support....................................................viii

traffic normalization................................................19

W

wire rates..................................................................1

wire-matched sensor ports.......................................1