Getting Started Guide

revision 1.0

®
McAfee IntruShield IPS System ®

version 3.1

McAfee ®

Network Protection
Industry-leading intrusion prevention solutions
COPYRIGHT
© 2002 - 2005 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. To obtain
this permission, write to the attention of the McAfee, Inc. legal department at: 5000 Headquarters Drive, Plano, Texas 75024, or call +1-972-963-8000.

TRADEMARK ATTRIBUTIONS
Active Firewall, Active Security, ActiveSecurity (in Katakana), ActiveHelp, ActiveShield, AntiVirus Anyware and design, Bomb Shelter, Certified Network
Expert, Clean-Up, CleanUp Wizard, ClickNet, CNX, CNX Certification Certified Network Expert and design, Covert, Design (Stylized E), Design (Stylized
N), Disk Minder, Distributed Sniffer System, Distributed Sniffer System (in Katakana), Dr Solomon's, Dr Solomon's label, Entercept, Enterprise
SecureCast, Enterprise SecureCast (in Katakana), ePolicy Orchestrator, EZ SetUp, First Aid, ForceField, GMT, GroupShield, GroupShield (in Katakana),
Guard Dog, HomeGuard, Hunter, IntruShield, Intrusion Prevention Through Innovation, IntruVert Networks, LANGuru, LANGuru (in Katakana), M and
Design, McAfee, McAfee (in Katakana), McAfee and design, McAfee.com, McAfee VirusScan, NA Network Associates, Net Tools, Net Tools (in Katakana),
NetCrypto, NetOctopus, NetScan, NetShield, NetStalker, Network Associates, Network Associates Coliseum, NetXray, NotesGuard, Nuts & Bolts, Oil
Change, PC Medic, PCNotary, PrimeSupport, Recoverkey, Recoverkey - International, Registry Wizard, RingFence, Router PM, SecureCast, SecureSelect,
Sniffer, Sniffer (in Hangul), SpamKiller, Stalker, TIS, TMEG, Total Network Security, Total Network Visibility, Total Network Visibility (in Katakana), Total Virus
Defense, Trusted Mail, UnInstaller, Virex, Virus Forum, ViruScan, VirusScan, WebScan, WebShield, WebShield (in Katakana), WebSniffer, WebStalker,
WebWall, What's The State Of Your IDS?, Who's Watching Your Network, WinGauge, Your E-Business Defender, Zip Manager are registered trademarks
or trademarks of McAfee, Inc. and/or its affiliates in the US and/or other countries. Sniffer® brand products are made only by McAfee, Inc. All other
registered and unregistered trademarks herein are the sole property of their respective owners.

PATENTS
Protected by US Patents 5,361,359; 5,557,742; 6,275,942; 6,301,699; 6,412,071; 6,496,875; 6,510,448; 6,513,122; 6,546,493; 6,584,508; 6,587,888;
6,668,289; 6,684,329

LICENSE INFORMATION
License Agreement
NOTICE TO ALL USERS: CAREFULLY READ THE APPROPRIATE LEGAL AGREEMENT CORRESPONDING TO THE LICENSE YOU PURCHASED, WHICH SETS FORTH THE
GENERAL TERMS AND CONDITIONS FOR THE USE OF THE LICENSED SOFTWARE. IF YOU DO NOT KNOW WHICH TYPE OF LICENSE YOU HAVE ACQUIRED, PLEASE
CONSULT THE SALES AND OTHER RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTS THAT 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, INC. OR THE PLACE OF PURCHASE FOR A FULL REFUND.

Attributions
This product includes or may include:

Š 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, Inc. 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 developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

Š Cryptographic software written by Eric A. Young ([email protected]) and software written by Tim J. Hudson ([email protected]).

Š OpenSSH software copyrighted by University of California, © 1980, 1993 The Regents of the University of California.

Š Software copyrighted by Markus Friedl, Theo de Raadt, Niels Provos, Dug Song, Aaron Campbell, Damien Miller, Kevin Steves.

Š Software copyrighted CORE SDI S.A., © 1998 Buenos Aires, Argentina.

Š Software copyrighted by David Mazieres, © 1995, 1996.

Š Software copyrighted by Gary S. Brown, © 1986.

Š Software copyrighted by Tatu Ylonen, © 1995.

Š Net-SNMP software copyrighted by Carnegie Mellon University; © 1989, 1991, 1992, and The Regents of the University of California © 1996, 1998-2000.

Š Software copyrighted by Cambridge Broadband Ltd., © 2001, All rights reserved.

Š MySQL software copyrighted by MySQL, AB.

Š Software developed and copyrighted by the Apache Software Foundation, © 1999, 2000, which software consists of voluntary contributions made by many individuals on
behalf of the Apache Software Foundation and was originally based on software copyright © 1999, International Business Machines, Inc., <http://www.ibm.com>.

Š JOnAS software originally created and copyrighted by Bull S.A., © 1999 Bull S.A.

Š SUN Java Secure Socket Extension software copyrighted by Software copyrighted by Sun Microsystems®, Inc.
Š Software copyrighted by RSA Data Security, Inc.

Š Software copyrighted by Lumos Technologies, © 2000-2002 Lumos Technologies, Inc. All rights reserved.

Š Software owned by Broadcom Corporation which is licensed by not sold. Title to and ownership of these portions and any portion thereof remain with Broadcom Corporation.
All express and implied warranties are disclaimed on behalf of Broadcom. Broadcom and its licensors disclaim any liability for any special, indirect, exemplary, incidental or
consequential damages.

Š Software copyrighted by Wind River Systems, Inc., © 2000.

Š Software developed by Cypress Semiconductor Corporation. All rights to the Cypress Semiconductor Corporation development software belong to Cypress Semiconductor
Corporation, owner of the former Lara Technology, Inc. No part of this Cypress Semiconductor Corporation development software code may be used, modified, reproduced,
transmitted, distributed, displayed or translated without the express written consent of Cypress Semiconductor Corporation. Proprietary legends within such code are to be
preserved in all copies thereof. Cypress Semiconductor Corporation makes no warranty of any kind, express or implied, with regards to this code, including, but not limited
to, the implied warranties of merchantability and fitness for a particular purpose.

Š Software copyrighted by PMC-Sierra, Inc., © 1998-2002. All rights to the PMC-Sierra development software belongs to PMC-Sierra, Inc. No part of this code may be used,
modified, reproduced, transmitted, distributed, displayed or translated without the express written consent of PMC-Sierra, Inc.

Š Software copyrighted by Vitesse Semiconductor Corporation, © 1997-2000. No part of this Vitesse Semiconductor Corporation code may be used, modified, reproduced,
transmitted, distributed, displayed or translated without the express written consent of Vitesse Semiconductor Corporation.

Š 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 OCTOBER 2005/ McAfee IntruShield IPS System version 3.1.0
700-1246-00 / DOCUMENT BUILD 1.0 - English
Contents

Preface iii
Welcome! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Contents of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
On-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

SECTION 1

An Overview of the IntruShield System

1 Intrusion Prevention and IntruShield 3
What is an attack? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
When attackers attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Detecting attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
What is an Intrusion Detection System (IDS)? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
What is an Intrusion Prevention System (IPS)? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Detection and prevention with IntruShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 IntruShield System Basics 10

IntruShield system components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
IntruShield sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
The IntruShield Security Management system . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Manager components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
The IntruShield Update Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Configuring software and attack signature updates . . . . . . . . . . . . . . . . . . . . .15
Modes of sensor deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
In-line mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
SPAN operating mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Tap mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Failover (high-availability) via in-line mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Port clustering (interface groups) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Manager Disaster Recovery (MDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Entercept integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Basics of Using IntruShield 24

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Deciding where to deploy sensors and in what operating mode . . . . . . . . . . . . . 24
Setting up your sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Establish sensor-to-Manager communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Viewing and working with data generated by IntruShield . . . . . . . . . . . . . . . . . . . 27
Configuring your deployment using the Manager . . . . . . . . . . . . . . . . . . . . . . . . . 28
Updating your signatures and software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Tuning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

iii
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

SECTION 2

Getting Ready to Deploy IntruShield

4 Pre-Installation Considerations 33
Pre-deployment questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
What is the size of your network? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
How many access points are there between your network and the extranets or
Internet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Where are the critical servers that require protection within your network? . 34
How complex is your network topology? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
How much traffic typically crosses your network? . . . . . . . . . . . . . . . . . . . . . 35
Where are your security operations located? . . . . . . . . . . . . . . . . . . . . . . . . . 35
Where should I deploy sensors? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 IntruShield Sensor Deployment Modes 38

Flexible deployment options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Multi-port sensor deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Supported deployment modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Full-duplex and half-duplex monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Deploying sensors in in-line mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Fail-open versus fail-closed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Deploying sensors in tap mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
SPAN port and hub monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
High-Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Understanding failover in IntruShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Interface groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

SECTION 3

Working with IntruShield Resources

6 Working with IntruShield Resources 50
IntruShield resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
The Resource Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Working with the Resource Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Relationship between sensors and resources in the Resource Tree . . . . . . . . . . 52

7 Administrative Domains 56
What is an administrative domain? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Parent and child admin domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Admin domain hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Alert and fault notification and forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8 Working with Security Policies 60

What are security policies? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
IntruShield policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Policy application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
VIPS—applying policies at the Interface and Sub-interface level . . . . . . . . . . 61
Pre-configured policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Configuring policies in IntruShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
About rule-based policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Attacks vs. signatures in IntruShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Creating or customizing a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Reassigning policies across sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Exporting and importing policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

iv
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Policy inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Response management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Response types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
The Global Attack Response Editor (GARE) . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Denial of Service (DoS) modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Learning mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Threshold mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Countering SYN floods with SYN cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Access control lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ACL logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
IP spoofing detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Decrypting SSL for IPS inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Supported Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Supported Cipher Suites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Unsupported SSL Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Vulnerability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9 Managing Users in IntruShield 79

User management in IntruShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
What is a role? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Creating a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Roles within IntruShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Role relationships between parent and child domains . . . . . . . . . . . . . . . . . . 81
Role descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

10 Working with Alerts 83

What are alerts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
The lifecycle of an alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Suppressing alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
About the Alert Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Drilling down—sorting alerts by categories . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Show the details of a specific alert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
About the Incident Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Utilizing the Incident Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Creating user-generated incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Viewing an incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
About the Report Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
IDS reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Configuration reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Scheduled reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Alert and packet log archival . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

SECTION 4

Deployment for Beginner, Intermediate, and Advanced Users

11 Deployment for Beginner, Intermediate, and Advanced Users 94
Deployment flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Deployment scenario for beginners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Deployment scenario for intermediate users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Deployment scenario for advanced users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Glossary 97

Index 108

v
Preface

Welcome!
Welcome to McAfee IntruShield, McAfee’s integrated network-based Intrusion
Prevention System (IPS). IntruShield is a comprehensive IPS, providing wire-speed
prevention of attacks in your network.

This guide provides an overview of the IntruShield system, including the concepts and
terminology you will encounter while using IntruShield products. This guide also
discusses best network security deployment practices. We recommend that you read
this guide before attempting to install and configure any component of the IntruShield
system.

Contents of this Guide

This Preface provides a roadmap of where to find information within the IntruShield
documentation set, and information on how to contact McAfee.

This guide is organized as described below:

Part One: An Overview of the IntruShield System

„ Chapter 1: Intrusion Prevention and IntruShield describes intrusions, the process of
intrusion detection, and IntruShield’s IPS capabilities at a high level.

„ Chapter 2: IntruShield System Basics provides a basic overview of the IntruShield

system and its various components.

„ Chapter 3: Basics of Using IntruShield is a high-level, step-by-step description of

how to interact with IntruShield.

Part Two: Getting Ready to Deploy IntruShield

„ Chapter 4: Pre-Installation Considerations lists planning considerations to help you
prepare to deploy the IntruShield system in your network.

„ Chapter 5: IntruShield Sensor Deployment Modes describes some of the

deployment options available with IntruShield sensors.

iii
McAfee® IntruShield® IPS System 3.1
Getting Started Guide Related Documentation

Part Three: Working with IntruShield Resources

„ Chapter 6: Working with IntruShield Resources describes the IntruShield resources
and how they appear in the IntruShield Manager System Configuration tool.

„ Chapter 7: Administrative Domains describes the IntruShield method of organizing

your security environment into protected administrative domains and subdomains,
so as to delegate management of your resources to specific individuals.

„ Chapter 8: Working with Security Policies describes how to construct the policies
that govern detection and countermeasures for the system.

„ Chapter 9: Managing Users in IntruShield describes how to assign roles/grant

privileges to IntruShield users.

„ Chapter 10: Working with Alerts is an overview of alerts, the notifications triggered
when your system detects attacks, and how you interact with them in the
IntruShield Manager.

Part Four: Deployment for Beginner, Intermediate, and Advanced Users

„ Chapter 11: Deployment for Beginner, Intermediate, and Advanced Users is a an
overview of how to get the system up and running quickly, and then fine tune it over
time to meet the demands of your network.

Related Documentation
Refer to this list to determine where to find information about the IntruShield system.

Document Type of Information Location

Quick Start Guides „ System setup and installation overview Printed, located in sensor
and Manager product boxes.
(<sensornum> Quick Start31.pdf)

e.g., I-2700_Quick_Start31.pdf

Getting Started Guide „ Product overview Located on the product CDs.

(Getting_Started_31.pdf) „ Product concepts
„ Deployment best practices
Sensor Configuration Guide „ System requirements Located on the product CDs.
(Sensor_Config_Guide_31.pdf) „ Installing and initializing a sensor
„ Upgrading or replacing a sensor
„ Removing a sensor
„ Troubleshooting
„ Sensor Command Line Interface (CLI)
reference
Sensor Product Guides „ System requirements Located on the product CDs.
(<sensornum> Prod_Guide_31.pdf) „ Cabling a sensor
„ Upgrading or replacing a sensor
e.g., I-1200ProdGuide.pdf
Manager Installation Guide „ System requirements Located on the product CDs.
(Manager_Install_Guide_31.pdf) „ Installing and upgrading the software
„ Removing the software

iv
McAfee® IntruShield® IPS System 3.1
Getting Started Guide Typographical Conventions

Document Type of Information Location

Manager Administrator’s Guide „ Configuration information Located on the product CDs.
(Manager_Admin_Guide_31.pdf) „ Usage information
Troubleshooting Guide „ System Troubleshooting Located on the product CDs
(Troubleshooting_Guide_31.pdf) „ Fault message interpretation
Manager On-line Help „ Context-sensitive help on the Integrated with IntruShield
IntruShield Manager interface. Manager.
Attack Encyclopedia „ Comprehensive list of attack Integrated with IntruShield
signatures, with descriptions Manager.
Release Notes „ System requirements Printed, located in the sensor
„ Resolved issues and Manager product boxes.

„ Known issues
„ Technical support
„ Last-minute additions or changes to
the product or documentation.

Typographical Conventions
This document contains the following typographical conventions.

Convention Example
Procedures are presented as a series of 1 On the Configuration tab, click Backup.
numbered steps.
Terms that identify elements, options, The Service field on the Properties tab specifies the name of the
selections, and commands on the screen requested service.
are shown in bold.
Menu or action group selections are Select Sensors > Configuration > Add/Delete Sensor.
indicated using a right angle bracket.
New terminology is shown in italics. Intrusion detection is the discovery of, and response to, an
attack or intrusion.
Terms that identify elements, options, The Service field on the Properties tab specifies the name of the
selections, and commands on the screen requested service.
are shown in bold.
Information that you must read before
beginning a procedure or that alerts you to
negative consequences of certain actions, Caution

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 Warning

denoted using this notation.

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

Helpful information such as shortcuts and

alternatives are denoted using this notation.
Tip

v
McAfee® IntruShield® IPS System 3.1
Getting Started Guide Contacting Technical Support

Contacting Technical Support

On-line
Contact McAfee Technical Support at http://mysupport.nai.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:00am to 5:00pm PST Monday-Friday. 24x7 Technical
Support is available for customers with PrimeSupport Priority or Enterprise service
contracts.

Phone: 1-800-338-8754 (US Toll Free) or +1.972.963.8000 (Outside US)

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
Note
username and password for the online case submission.

vi
SECTION 1

An Overview of the
IntruShield System
An overview of the system and usage basics.

Chapter 1, Intrusion Prevention and IntruShield

Chapter 2, IntruShield System Basics
Chapter 3, Basics of Using IntruShield
1 Intrusion Prevention and IntruShield

In the early days of computers, information stored on a computer was very difficult to
get to without physical access to the computer itself. In those days, you hired security
guards to deter intruders, put a sturdy lock on the door, turned on the security alarm,
and your data was safe and sound. Attacks on the data was expensive, usually physical,
and required great planning and technical savvy.

Unfortunately, the many advances in technology changed all that. Back then, intrusion
or attacks on computers was viewed as something unlikely, infeasible. These days a
corporate network is prey even to pre-teens sitting in their bedrooms at home. The
Internet is crawling with people from all walks of life who are continuously trying to test
the security of various systems and networks. Some are simply seeking some sort of
intellectual high, while others are fueled by more treacherous motives, such as revenge
or stealing for profit.

It is now much more important to make sure all of the doors and windows to your
network are locked, the alarm is turned on, and that your security system knows what
to look for. Because these days the question of intrusion is no longer if it will happen,
but when.

What is an attack?
An attack is any unauthorized action taken with the intent of hindering, damaging,
incapacitating, or breaching the security of a network. An attack typically prepares for
or carries out threats to your critical assets.

Some attempts to infiltrate a network are relatively harmless, but others can bring the
network to a grinding halt and cripple a business. Individuals who intrude on or attack
a system are known by a number of names, but are generally referred to as crackers,
or more popularly, hackers. In this documentation set, these individuals are referred to
as attackers.

Intrusion detection is the discovery of an attack or intrusion. Intrusion prevention is

blocking an attack before it reaches its target. Attacks are actions performed by an
attacker that pose a threat to the security state of a protected entity in terms of
confidentiality, integrity, authenticity, availability, authorization, and access policies.
Attacks can be active, wherein the goal is to directly exploit some vulnerability in a

3
McAfee® IntruShield® IPS System 3.1 Intrusion Prevention and IntruShield 1
Getting Started Guide What is an attack?

system or software package. In contrast, passive attacks generally consist of

monitoring or eavesdropping on traffic with the intention of viewing or capturing
sensitive data. The result of a successful active attack is an intrusion—disruption of the
normal services, unauthorized access, and/or some form of tampering with the
system.

Intrusion detection can also identify security-related events in a system that may not be
triggered by an attack, such as server malfunctions.

When attackers attack

When attackers attack a network, they “abuse rules” established by the network. The
rules are broken in a way that makes the attack appear to be a normal transmission.

Active attacks can generally be divided into the following categories:

„ Exploits—An exploit is an attempt by an attacker to take advantage of hidden

features or bugs in a system in order to gain unauthorized access. Examples include
buffer overflows, directory traversal, and DNS cache poisoning.

„ Denial-of-service (DoS) and Distributed Denial-of-service (DDoS) attacks—In a

DoS attack, the attacker attempts to crash a service (or the machine), overload
network links, overload the CPU, or fill up the disk. The attacker does not always try
to gain information, but to simply act as a vandal to prevent you from making use of
your machine. Ping floods and Smurf attacks are examples of DoS attacks. DDoS
attacks usually consist of DoS attacks orchestrated by attackers covertly controlling
many, sometimes hundreds, of different machines.

„ Reconnaissance—These include host sweeps, TCP or UDP port scans, e-mail

recons, brute force password guessing, and possibly indexing of public Web servers
to find CGI holes or other system vulnerabilities that might later be exploited.

„ Policy Violations—All activities for which the underlying traffic content may not be
malicious by itself, but are explicitly forbidden by the usage policies of the network
as defined by a security policy. These can include “protocol violations” wherein
packets do not conform to network protocol standards. (For example, they are
incorrectly structured, have an invalid combination of flags set, or contain incorrect
values.) Examples might include TCP packets with their SYN and RST flags enabled,
or an IP packet whose specified length doesn’t match its actual length. A protocol
violation can be an indication of a possible attack, but can also be triggered by buggy
software or hardware.

Some attackers are looking for specific information or targeting a specific company.
Others are simply seeking an easy target. Some are advanced users who develop their
own tools and leave behind sophisticated “backdoors.” Others have no idea what they
are doing and only know how to start the script they’re playing with.

Regardless of their skill level, they all share a common strategy: use tools to search the
entire Internet for a specific weakness, then exploit that weakness. Sooner or later they
find someone vulnerable. Anyone can be a target in a search, at any time—from
established companies with networks developed over decades, to companies whose
network has been up for two days. Sooner or later, you will be probed.

4
McAfee® IntruShield® IPS System 3.1 Intrusion Prevention and IntruShield 1
Getting Started Guide What is an attack?

Because networks are typically running 24 hours a day, attacks can occur at any time.
Attacks often occur at night when domestic attackers who have “day jobs,” go to
school, or do other things during the day that preclude attacking. Attacks can also occur
during the day when it is evening in other parts of the world, such as Eastern Europe
and Korea, which have become origins of numerous attacks.

Detecting attacks
Early intrusion detection was performed strictly using pattern matching schemes. Most
attackers implement techniques that are tried, true, and well known in the security
community. Unless the attacker is writing his own tools, she/he must rely on available,
existing tools, each of which has limitations peculiar to its particular design. Thus, from
the victim's point of view, all attacks using such tools will look basically the same. For
example, seeing “default.ida” in the URL field of an HTTP packet along with a specific
pattern in the URL argument name field implies a Code Red attack and thus fits a
standard—or signature—attack pattern.

Pattern matching relies upon knowing all of the ways the rules can be broken, and
works by comparing network traffic to a database of attack patterns, which are called
signatures. Signature-based detection, also known as misuse detection or rule-based
detection, attempts to capture the manifestation of attacks in signatures and, if
configured to do so, apply specific countermeasures based on each signature. This is
very effective for known attacks with well-known signatures.

However, this method of detection is flawed in three ways: first, it works only for known
attacks. Attackers tend to be clever, and they continuously create new ways to hack a
system, which quickly outdates the pattern-matching database. Second, pattern
matching uses significant computing cycles to work effectively, and this can be
exploited by hackers through overloading, which obscures the pattern-matching
system’s visibility. Relying on signature detection alone leaves you unprotected against
new or especially complex attacks.

Anomaly detection is another detection method, used to more effectively protect

against unknown, or first-strike attacks. Anomaly detection attempts to capture the
long-term normal behavior of the protected system in profiles (specifications of the
behavior of traffic over a short- or long-term), and sends an alarm when significant
deviation from the normal behavior is discovered. Profiles are created using statistical
measures or other behavior specifications that can be applied to multiple platforms and
operating systems. There are multiple learning disciplines that make it possible to
create and maintain profiles – statistical, neural nets, fuzzy logic, genetic, and so forth.
Anomaly detection is particularly useful when confronted with distributed denial of
service (DDoS) and slow-scans attacks, which can affect a system over an extended
period of time.

Another special method of detection is denial of service (DoS) detection. A DoS attack
disrupts service to a network or computer, and often occurs at the firewall or in the
DMZ, particularly DMZ Web and mail servers. There are two ways to detect DoS
attacks. First, there is threshold-based detection, wherein the IDS monitors for traffic
volumes exceeding a threshold pre-configured by a network administrator. (This
method requires you to fully understand your typical traffic pattern in order to pick
“good” threshold values, otherwise it can produce a lot of false alarms due to traffic
fluctuations, such as “flash crowds”—e.g., everyone logging on the network at 9
a.m.—or other legitimate increased traffic.) The second method is by learned
behavior—learning long-term normal behavior and comparing it to short-term observed
behavior. Combining the methods greatly improves the reliability of detection.

5
McAfee® IntruShield® IPS System 3.1 Intrusion Prevention and IntruShield 1
Getting Started Guide What is an Intrusion Detection System (IDS)?

What is an Intrusion Detection System (IDS)?

An Intrusion Detection System (IDS) is software or a hardware/software combination
that attempts to detect and respond to attempted intrusions into a system or network.
An IDS complements firewalls or anti-virus software by providing thorough network
packet content inspection and protecting against attacks “embedded” within what a
firewall might perceive as seemingly benign network traffic.

There are several classifications of IDS.

„ Host- or Network-based. A host-based IDS is concerned with what is happening

on each individual computer or “host” and is able to detect such things as repeated
failed access attempts or changes to critical system files. A network-based IDS
(NIDS) examines all of the packets flowing through your network. A NIDS is able to
understand all of the details of many protocols such as headers or protocol fields
within a packet and can thus detect maliciously crafted traffic content. There are
various types of network-based IDS—these can take the form of software agents
running at various points throughout the network, or hardware sensors placed at
strategic locations to examine network traffic.

„ Signature, Anomaly, and Denial of Service detection. Another classification

describes the types of misuse that an IDS detects. As described in the section
Detecting attacks on page 5, signature detection techniques systematically scan
network traffic looking for signature patterns of known attacks, comparing these
patterns against an extensive database of signatures. Anomaly detection
determines a baseline of normal behavior of network traffic, and then attempts to
detect intrusions by noting significant departures from normal behavior.
Signature-based detection concentrates on known attack patterns, while anomaly
detection is best at picking up new or unknown attacks. Denial of Service (DoS)
attack detection characterizes normal traffic using pre-programmed thresholds or
real-time, self-learning distributions, and then using this data to detect what might
constitute a maliciously excessive consumption of network bandwidth, host
processing cycles or other resources.

„ Passive, reactive, or preventive IDS. Passive intrusion detection systems sniff

packets as they traverse your network. They can detect the potential security
breach, log the information about the attack, and raise an alert. Reactive systems are
designed to respond to the intrusion—for example, by logging off a user or by
reprogramming the firewall to disallow network traffic from a suspected hostile
source. Both types of technology enable you to respond only after the attack has
occurred. A preventive system sits in the path of your network traffic and thus is
able to detect and drop hostile packets before they reach their target.

What is an Intrusion Prevention System (IPS)?

The IntruShield system is a network-based Intrusion Prevention System (IPS) that
combines network sensor appliances and management software for the accurate
detection and prevention of known attacks using signature detection, unknown (first
strike) attacks using anomaly detection, denial of service (DoS) attacks, and distributed
denial of service (DDoS) attacks. The IntruShield IPS couples real-time IDS with
prevention—the ability to block attacks before they reach their target—to offer the most
powerful, comprehensive and effective network security system in the market.

6
McAfee® IntruShield® IPS System 3.1 Intrusion Prevention and IntruShield 1
Getting Started Guide What is an Intrusion Prevention System (IPS)?

IntruShield offers multi-gigabit performance, flexible deployment, robust scalability, and

easy-to-use intrusion detection and prevention.

„ Comprehensive Intrusion Detection. IntruShield is the only comprehensive

network-based IPS solution available. Only IntruShield encompasses all of today’s
applicable IPS technologies to allow customers to detect known (using signatures),
new/unknown (using anomaly techniques) and Denial-of-Service (DoS) attacks
(using hybrid algorithms employing statistical and heuristic methods). The
combination of these techniques significantly increases the capability and accuracy
of the IPS. The majority of current products are exclusively signature-based and have
little to no anomaly or DoS detection capabilities. No product on the market has the
breadth or depth of coverage of IntruShield. For example, IntruShield can inspect
SSL traffic and HTTP response traffic. In addition, IntruShield also detects attacks
with unprecedented accuracy thanks to:

„ Full protocol analysis and state tracking

„ Multi-trigger, multi-field pattern matching

„ Hardware acceleration to deliver wire-speed detection

„ IntruShield’s ability to see all of the traffic in a variety of deployment modes,

including active/active, active/passive, and asymmetrically-routed traffic
environments.

„ Intrusion Prevention. IntruShield can run in-line, so you can mediate the traffic flow
and block malicious traffic before reaching its target. Current IDS products operate
in a monitoring-only mode (operating as a “sniffer”) and cannot effectively and
reliably block the malicious traffic before the damage is done. In sniffing mode, you
see the attack at the same time it hits the target. You can apply some
countermeasures, like TCP resets and firewall rule reconfiguration, but these are
reactive actions. When running in-line, IntruShield can proactively drop malicious
packets and not pass them through the network, so they never reach their target.

In addition to dropping malicious traffic, IntruShield provides “packet scrubbing”

functionality to remove protocol inconsistencies resulting from varying
interpretations of the TCP/IP specification, which can be used by hackers to evade
IDS systems and other security devices.

„ Flexible Deployment Options. Existing products were designed when shared

media networks were common and are not easy to deploy in today's switched
environments. Furthermore, the IntruShield product line allows customers to
protect today's higher speed network segments ranging from 100Mbps up to
multi-Gbps, whereas current products are primarily limited to sub-100Mpbs
environments. IntruShield provides wire-speed monitoring and analysis up to
multi-Gbps network segments in three flexible modes of deployment, enabling you
to easily integrate it into your network and adapt to any network or security changes
that you may encounter in the future.

Some IntruShield sensor models contains built-in 10/100Mbps Ethernet taps, thus
making it extremely easy to switch between tap and in-line modes through software
reconfiguration; no physical rewiring is required.

The multi-port configuration of all IntruShield sensors empowers comprehensive

network-wide IDS deployment with significantly fewer sensors.

7
McAfee® IntruShield® IPS System 3.1 Intrusion Prevention and IntruShield 1
Getting Started Guide Detection and prevention with IntruShield

„ Virtual IPS™. Most products enable you to implement a single security policy per
sensor. IntruShield’s Virtualization feature (called VIDS or VIPS) enables you to
segment an IntruShield sensor into a large number of virtual sensors with each
implementing a custom security policy, including individualized attack selection and
associated response actions. This capability allows you to implement and enforce a
heterogeneous set of security policies with a single sensor, better serving the
differing security needs within an organization. It further reduces the number of
sensors required for a network-wide IPS deployment, and it reduces the number of
irrelevant alerts.

„ High-Availability. Sensors support high-availability deployment, using stateful

sensor failover between two hot-standby sensors. The sensors are interconnected,
copy traffic between themselves, and maintain synchronization. If one sensor fails,
the standby sensor automatically takes over and continues to monitor the traffic
with no loss of session state or degradation of protection level. IntruShield also
supports Manager disaster recovery. If, for any reason, the primary Manager goes
off-line, its secondary can automatically take its place, processing alerts and
managing sensor configuration.

„ Scalable IPS Management. A scalable Web-based architecture allows customers

to efficiently manage their IPS deployment while reducing operational costs. The
configurable IntruShield real-time signature and software update mechanism
automates the process of keeping the complete system current with little or no
human intervention, thus reducing on-going operating costs.

Detection and prevention with IntruShield

Detection with the IntruShield IPS goes beyond the simple string matching used in
many current IDS signature engines. IntruShield sensors analyze and validate the traffic
to its basic protocol elements and inspect specific protocol fields to improve accuracy,
while maintaining full flow and application state. The sensors perform IP fragment
reassembly and TCP stream reassembly, and perform thorough protocol analysis all the
way up to the Application Layer. The signature engine searches in a flow for multiple
triggers (that is, sub-signatures) in multiple fields of a protocol using IntruShield’s
embedded signature files to increase the precision by which an attack can be
unambiguously detected.

Once the packet is captured, it is analyzed into its corresponding protocol fields. The
sensor analyzes a frame completely and thoroughly from Layers two through seven,
and understands the semantics of the protocol fields even at the Application Layer.
After it analyzes the protocols, it verifies that the packet conforms to the protocol
specification. IntruShield then passes the parsed packet through its DoS, Signature, and
Anomaly detection engines. This enables IntruShield to be very efficient in terms of
packet processing because the packet is “peeled” only once and then fed to the
corresponding detection engines. All these processes are hardware-accelerated to
provide the required wire-speed performance.

8
McAfee® IntruShield® IPS System 3.1 Intrusion Prevention and IntruShield 1
Getting Started Guide Detection and prevention with IntruShield

If the detection engines detect something, they pass an alert and corresponding data
to the Management process that is running on the sensor. The Management process
can then trigger the appropriate response, based on policy, and send alerts to the
central IntruShield Manager platform. This response can include averting the attack
entirely. If an IntruShield sensor is running in in-line mode on the network, you can
enable blocking, which causes the sensor to drop the attack so that the attack never
reaches its goal.

9
2 IntruShield System Basics
An overview of the system and its components

IntruShield system components

The IntruShield system consists of the following major components:

„ IntruShield sensor appliances, described below.

„ the IntruShield Security Management System, with its Web-based graphical user
interface, described on page 11.

„ the IntruShield Update Server, described on page 14.

IntruShield sensors
IntruShield sensors are high-performance, scalable, and flexible content processing
appliances built for the accurate detection and prevention of intrusions, misuse, denial
of service (DoS) attacks, and distributed denial of service (DDoS) attacks. IntruShield
sensors are specifically designed to handle traffic at wire-speed, efficiently inspect and
detect intrusions with a high degree of accuracy, and flexible enough to adapt to the
security needs of any enterprise environment. When deployed at key network access
points, an IntruShield sensor provides real-time traffic monitoring to detect malicious
activity and respond to the malicious activity as configured by the administrator.

Once deployed and once communication is established, sensors are configured and
managed via the central IntruShield Manager server, described in the section The
IntruShield Security Management system on page 11.

Sensor functionality
The primary function of an IntruShield sensor is to analyze traffic on selected network
segments and to respond when an attack is detected. The sensor examines the header
and data portion of every network packet, looking for patterns and behavior in the
network traffic that indicate malicious activity. The sensor examines packets according
to user-configured policies, or rule sets, which determine what attacks to watch for, and
how to react with countermeasures if an attack is detected.

If an attack is detected, the sensor raises an alert to describe the event, and responds
according to its configured policy. Sensors can perform many types of attack
responses, including generating alerts and packet logs, resetting TCP connections,
blocking traffic at firewalls, “scrubbing” malicious packets, and even dropping packets
entirely before they reach their target.

10
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide The IntruShield Security Management system

McAfee offers several types of sensor platforms providing different bandwidth and
deployment strategies. These are the IntruShield 1200,1400, 2600, 2700, 3000, 4000,
and 4010 sensors.

Each sensor is described in its own Sensor Product Guide.

Table 2-1 IntruShield Sensor Information

Monitoring Ports Response Failover Port(s)

Ports
Sensor Aggregate 10/100 GBIC SFP Internal 10/100 Posts Used
Performance Base-T GBIC Taps Base-T
I-1200 100Mbps 2 Yes 1 Response port
I-1400 200Mbps 4 Yes 1 Response port
I-2600 600Mbps 6 2 Yes 3 4A
I-2700 600Mbps 6 2 Yes 3 4A
I-3000 1Gbps 12 No 2 HA1 and HA2
(6A and 6B)
I-4000 2Gbps 4 No 2 2A and 2B
I-4010 2Gbps 12 No 2 HA1 and HA2
(6A and 6B)
4 Fail-open Control Ports (I-3000 and I-4010 only)
1 10/100 Base-T Management Port
1 Console Port and 1 Auxiliary Port
Redundant power supply (I-2700, I-3000, I-4000, I-4010)

The IntruShield Security Management system

The IntruShield Security Management (ISM) system consists of the hardware and
software resources that are used to configure and manage your IntruShield
deployment.

There are three software versions of the ISM system:

„ McAfee® IntruShield® Global Manager—best suited for global IPS deployments

of more than six sensors. The Global Manager is supported on Windows Server
2003 (Standard Edition).

„ McAfee® IntruShield® Manager—can support large or distributed deployments

of up to six sensors. IntruShield Manager is supported on Windows Server 2003
(Standard Edition).

„ McAfee® IntruShield® Manager Starter—can support a single sensor.

IntruShield Manager Starter is supported on Windows Server 2003 (Standard
Edition).

Functionally, the products are otherwise identical. The license file provided to you by
McAfee determines which version of ISM you install.

11
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide The IntruShield Security Management system

Manager components
This document uses the term “Manager” to describe either version.
Note

The IntruShield Manager is a term that represents the hardware and software
resources that are used to configure and manage the IntruShield system. The Manager
consists of the following components:

„ a hardware/OS server platform (Windows Server 2003, Standard Edition)

„ the Manager software. See The IntruShield Security Management system on

page 11 for details.

„ a backend database to persist data (MySQL or Oracle9i). See page 13 for details.

„ a connection to the IntruShield Update Server. See page 14 for details.

The Manager server platform

The IntruShield Manager server is a dedicated Windows Server 2003 system running
the Manager software. You remotely access the Manager interface from a Windows XP
system using an Internet Explorer browser session.

IntruShield sensors use a built-in 10/100 Management port to communicate with the
Manager server. You can connect a segment from a sensor Management port directly
to the Manager; however, this means you can only receive information from one sensor
(typically, your server has only one 10/100 network port). McAfee recommends using a
separate, dedicated management subnet to interconnect the sensors and the Manager
to isolate and protect your management traffic. During sensor configuration, described
in the Sensor Configuration Guide, you will establish communication between your
sensor(s) and your Manager server.

The IntruShield Manager Software

The IntruShield Manager software has a Web-based user interface for configuring and
managing the IntruShield system. IntruShield users connect to the Manager server
from a Windows XP system using the Internet Explorer browser program. The
Manager interface runs with Internet Explorer version 5.5 or later. The Manager
functions are configured and managed through a GUI application, the Manager
interface, which includes complementary interfaces for system status, system
configuration, report generation, and fault management. All interfaces are logically
parts of the Manager program.

The Manager has five components:

„ Network Console. The Network Console is the first screen displayed after the user
logs on to the system. The Network Console displays system health—i.e., whether
all components of the system are functioning properly, the number of
unacknowledged alerts in the system, and the configuration options available to the
current user. Options available within the Network Console are determined by the
current user’s assigned role(s).

„ System Health. The System Health viewer displays the status of the Manager,
database, and any deployed sensors; including all system faults.

12
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide The IntruShield Security Management system

„ System Configuration tool. The System Configuration tool provides all system
configuration options, and facilitates the configuration of your sensors, failover pairs
of sensors, administrative domains, users, roles, attack policies and responses,
user-created signatures, and system reports. Access to various activities, such as
user management, system configuration, or policy management is based on the
current user’s role(s) and privileges.

„ Alert Viewer. The Alert Viewer displays detected security events that violate your
configured security policies. The Alert Viewer provides powerful drill-down
capabilities to enable you to see all of the details on a particular alert, including its
type, source and destination addresses, and packet logs where applicable.

„ Report Generator. The Report Generator enables a user to generate reports for the
security events detected by the system and reports on system configuration.
Reports can be generated manually or automatically, saved for later viewing, and/or
emailed to specific individuals.

Other key features of the Manager include:

„ The Incident Generator. The Incident Generator enables creation of attack incident
conditions, which, when met, provide real-time correlative analysis of attacks. Once
incidents are generated, view them using the Incident Viewer, which is within the
Alert Viewer tool.

For more detailed information on IntruShield Manager components, see the

Administrator’s Guide.
Note

„ Integration with third-party products: IntruShield enables the use of multiple

third-party products for analyzing faults, alerts, and generated packet logs.

„ Fault/Alert forwarding and viewing: You have the option to forward all fault
management events and actions, as well as IPS alerts to a third-party application.
This enables you to integrate with third-party products that provide trouble
ticketing, messaging, or any other response tools you may wish to incorporate.
Fault and/or alert forwarding can be sent to the following ways:

„ Syslog Server: forward IPS alerts and system faults

„ SNMP Server (NMS): forward IPS alerts and system faults
„ Java API: forward IPS alerts
„ Crystal Reports: view alert data from database
„ via email, email pager, or script

„ Packet log viewing: view logged packets/flows using third-party software, such
as Ethereal.

The Manager database

The IntruShield Manager server operates with an RDBMS (relational database
management system) for storing persistent configuration information and event data.
The compatible databases are as follow:

„ MySQL: The IntruShield Manager for Windows (only) includes a MySQL database
that can be installed (embedded) on the target Windows server during Manager
software installation.

13
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide The IntruShield Update Server

Your MySQL database can be tuned on-demand or by a set schedule via Manager
interface configuration. Tuning promotes optimum performance by defragmenting
split tables, re-sorting and updating indexes, computing query optimizer statistics,
and checking and repairing tables.

To graphically administrate and view your MySQL database, you can download the
MySQL administrator at http://dev.mysql.com/downloads/administrator.

„ Oracle9i: You can use an Oracle9i database that is running on a remote Solaris
server with IntruShield Global Manager only.

McAfee recommends that you employ an Oracle DBA for all database-related
maintenance and management.

For recommendations on deploying an Oracle database for IntruShield, see the

Oracle9i Deployment Guide, available on the product CD.

The IntruShield Update Server

For your IntruShield IPS to properly detect and protect against malicious activity, the
Manager and sensors must be frequently updated with the latest signatures and
software patches available. Thus, the IntruShield team constantly researches and
develops performance-enhancing software and attack-detecting signatures that
combat the latest in hacking, misuse, and denials of service (DoS). When a
severe-impact attack happens that cannot be detected with the current signatures, a
new signature update is developed and released. Since new vulnerabilities are
discovered regularly, signature updates are released frequently.

New signatures and patches are made available to customers via the IntruShield
Update Server. The Update Server is a McAfee-owned and -operated file server that
houses updated signature and software files for IntruShield Managers and sensors in
customer installations. The Update Server securely provides fully automated, real-time
signature updates without requiring any manual intervention.

Communication between the Manager and the Update Server is SSL-secured.

Note

You have the following options for obtaining updates from the Update Server:

To configure Update Server settings from the Manager interface, refer to Chapter 6 of
the Manager Administrator’s Guide.
Note

1 Connecting directly from your Manager server (via Manager interface action).

2 Connecting via proxy server (via Manager interface action). You will then
authenticate as in option 1.

3 Connecting from any Windows XP system via browser, downloading updates to that
system, and then importing the update to the Manager. This method can provide
your Manager server with the safest defense against Internet attacks since no
Internet connection is used by your Manager server. The import feature is a
Manager interface action.

14
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Modes of sensor deployment

4 Connecting from any Windows XP system via browser, downloading software

updates to a TFTP server, and then loading the updates directly onto the sensor
using the sensor’s command line interface (CLI). This is for sensor software updates
only. Refer to the Sensor Configuration Guide.

Configuring software and attack signature updates

You configure interaction with the Update Server using the Manager’s System
Configuration tool. You can pull updates from the Update Server on demand or you can
schedule update downloads. With scheduled downloads, the IntruShield Manager polls
the Update Server (over the Internet) at the desired frequency. If an update has been
posted, that update is registered as “Available” in the Manager interface for on-demand
downloaded. Once downloaded to the Manager, you can immediately download (via an
encrypted connection) the update to deployed sensors or deploy the update based on
a sensor update schedule you define. Acceptance of a download is at the discretion of
the administrator.

You have a total of five update options:

„ Automatic update to the Manager, manual update from the Manager to

sensors. This option enables the Manager server to receive updates automatically,
but allows the administrator to selectively apply the updates to the sensors.

„ Manual update to the Manager, automatic update from the Manager to

sensors. This option enables the administrator to select updates manually, but once
the update is selected, it is applied to the sensors automatically, without reboot.

„ Fully manual update. This option allows the security manager to determine per
update which signature update to apply and when to push the update out to the
sensor(s); in essence, the management system is completely customizable. You
may wish to manually update the system when you make some configuration
change, such as updating a policy or response.

„ Fully automatic update. This option enables every update to pass directly from the
Update Server to the IntruShield Manager, and from the IntruShield Manager to the
IntruShield sensor(s) without any intervention by the security administrator. Note
that fully automatic updating still happens according to scheduled intervals.

„ Real-time update. This option is similar to fully automatic updating. However,

rather than wait for a scheduled interval, the update is pushed directly from Update
Server to Manager to sensor. No device needs to be rebooted; the sensor does not
stop monitoring traffic during the update, and the update is active as soon as it is
applied to the sensor.

Modes of sensor deployment

With today’s complex network configurations, deploying sensors at all of the necessary
points of protection in your network can become both very complex and very
expensive. The IntruShield system makes deployment easy and cost-effective by
requiring fewer sensors and offering several flexible modes of sensor deployment:

„ In-line mode on page 16

„ Tap mode on page 18

15
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Modes of sensor deployment

„ SPAN operating mode on page 17

„ Failover (high-availability) via in-line mode on page 19

„ Port clustering (interface groups) on page 19

IntruShield sensors, by default, are configured to operate in in-line mode. The operating
mode can be changed via the Manager interface.

Each of these modes is described briefly below and in more detail in IntruShield Sensor
Deployment Modes on page 38.

Although the sensors are configured to run in-line by default, many new IntruShield
users choose to operate in SPAN mode initially, and then move to tap or in-line mode
Note
later as they become more familiar with the product and are ready to “tune” their
deployments.

In-line mode
In-line Mode, illustrated in Figure 2-1, places a sensor directly in the network traffic
path, inspecting all traffic at wire-speed as it passes through the sensor. In-line mode
enables you to run the sensor in a protection/prevention mode, where packet
inspection is performed in real time, and intrusive packets can be dealt with
immediately; you can actively drop malicious packets because the sensor is physically
in the path of all network traffic. This enables you to actually prevent an attack from
reaching its target. You cannot prevent attacks from reaching their target in any
other deployment mode.

All IntruShield sensor ports are configured to run in-line by default; when a sensor
comes online for the first time, it is in in-line mode. IntruShield sensors are also
configured to block certain attacks by default. Thus an IntruShield system can begin
blocking attacks right out-of-the-box.

All IntruShield sensor models can be deployed in In-line Mode, and all offer the option
of operating in fail-open or fail-closed mode when monitoring traffic in-line.

Fail-open and fail-close refer to whether or not the sensor will allow traffic to continue
to pass in the event of port or sensor failure. For more information on these options,
Note
refer to Fail-open versus fail-closed on page 42.

Figure 2-1 In-line mode

For more information about deploying sensors, see the section IntruShield Sensor
Deployment Modes on page 38 of this Guide.

16
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Modes of sensor deployment

SPAN operating mode

Most current IDS products are deployed in SPAN mode. An advantage of deploying
sensors in SPAN mode is that it merely requires connecting the sensor and
reconfiguring a setting on the switch—thus it is also the operating mode chosen by
most beginning IntruShield users. Other modes of sensor deployment—in-line mode
or tap mode—involve connecting the sensors within the flow of traffic, which requires
brief network downtime. Thus most beginners prefer to ‘get used’ to IntruShield while
operating in SPAN mode, to tweak and tune their systems, and move to tap or in-line
mode later.

The Switch Port Analyzer (SPAN) port on a switch is designed specifically for security
monitoring so that an attached network analyzer—like a sensor or a sniffer—can receive
a copy of every single packet that is sent from one host to another through the switch.
The SPAN port forwards all incoming and outgoing traffic within the switch to a
predetermined port where the sensor or a sniffer is connected. This is called port
forwarding or port mirroring, and it allows an attached device to monitor all traffic of that
switch.

The downside of monitoring via a SPAN port is that it is very easy to saturate a SPAN
port. A SPAN port really only operates in a half-duplex mode (transmit to the sensor
only), so the maximum bandwidth the port can handle is 100Mbps (when using a Fast
Ethernet port), and when you exceed the 100Mbps limit of the port, you are not copying
all the packets seen on the switch. When all packets are not copied to the IDS, the IDS
can report false alarms or miss real attacks. In addition, most switches only support one
or two SPAN ports and there is a lot of competition for them (e.g., for RMON probes,
sniffers, etc.).

SPAN mode is also a “sniffing” mode, which—unlike in-line mode—does not enable
you to prevent attacks from reaching their targets.

Figure 2-2 SPAN Port Monitoring

17
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Modes of sensor deployment

Tap mode
While Figure 2-2 demonstrates that you can issue response packets via the sensor’s
response ports, some switches allow response packets to be injected by an IPS back
Note
through the SPAN port.

Tap mode, illustrated in Figure 2-3, works through installation of an external fiber tap
(for GBIC ports) or built-in internal taps (for 10/100 Monitoring ports). An IntruShield
sensor deployed in tap mode monitors or “sniffs” the packet information as it traverses
the full-duplex network segment.

Full-duplex taps split a link into separate transmit and receive channels. IntruShield
sensors provide multiple sensor ports, wired in pairs to accommodate full-duplex taps.

The downside of tapped mode is that, unlike in-line mode, you cannot prevent attacks.
Like SPAN mode, Tap mode is passive; the sensor essentially sees malicious traffic as
it passes.
Figure 2-3 Full-duplex Tap Mode

You cannot inject response packets back through an external tap, so IntruShield
sensors offer Response ports through which a response packet (such as a TCP reset)
Note
can be injected to close a malicious connection. Sometimes the attacker can succeed
in causing the intended damage when the attack packet reaches its intended victim
host before the TCP reset closes the connection. Hence, in-line mode is more
effective in preventing an attack.

About taps
A tap is a device that permits unimpeded traffic flow while simultaneously copying all
the traffic from a full-duplex link and sending the information to a sensor for analysis.
Taps are used to monitor full-duplex links, and they split the link into separate transmit
and receive channels. To monitor the two channels that the tap produces, you use two
monitoring interfaces on the sensor; one interface monitors the transmit channel, one
monitors the receive channel—neither monitoring interface transmits back to the tap.

You cannot inject response packets back through a tap; you must connect a sensor
response port to another device, namely a switch or router, to respond to malicious
Note
packets.

18
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Modes of sensor deployment

Taps are hardwired to the sensor. One sensor can monitor traffic from multiple taps
without degradation or overloading up to the specified maximums.

Failover (high-availability) via in-line mode

Enterprises often deploy fully redundant networks to maintain high network availability.
In a redundant network, also known as an active/passive or active/standby
configuration, two identical machines are deployed; one is designated as the active
machine that performs the task while the other(s) is in standby in case of the active
machine’s failure. If the active machine fails, it fails over to the standby machine.
System redundancy ensures the network is always available even if the hardware fails.

This reduces lapses in service to employees and customers that may lead to loss of
productivity and revenue. IntruShield sensors are built to meet the needs of redundant
networks. When running sensors in-line, the option is available to you to use one
sensor as an active unit, with an identical sensor standing by, should the active sensor
fail. Both sensors share full state, so that the information on the standby sensor is
always current. Latency is very minimal; less, in fact, than many other devices providing
failover, such as firewalls.

For more information on deploying sensors for high availability, see the section
High-Availability on page 46 of this Guide.

Port clustering (interface groups)

Port clustering, referred to as Interface Groups in the IntruShield Manager interface,
enables multiple ports on a single sensor to be grouped together for effective traffic
monitoring, particularly useful for asymmetrically routed networks. You cluster ports
when you want the traffic across multiple interfaces to be analyzed as if it were a single
interface. 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.

When is clustering used?

If a company has two different active paths to and from the Internet passing through
two different sensor interfaces, for example, the traffic on each path will be analyzed
independently. If a single communication flow is divided across paths, each interface
will receive and analyze part of the conversation and therefor be susceptible to false
positives and false negatives. When you create an interface group that contains both
interfaces, you allow the sensor to receive and properly analyze the entire
communication.

19
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Manager Disaster Recovery (MDR)

Figure 2-4 Port Clustering

Manager Disaster Recovery (MDR)

Sometimes the worst happens. In this age, where outages to IT systems can cost
millions of dollars in lost revenue, lost productivity, and legal issues, every organization
must face the near certainty of a system failure occurring at a future date. Anticipating
these events and planning corrective courses of action is now a prerequisite to
business success. Most organizations now employ some manner of business
continuity planning (BCP), a subset of which is disaster recovery planning (DRP). To this
end, IntruShield has long provided a sensor high-availability configuration; but what if
the worst should happen to your Manager server? Most companies are not willing to
rely on the manual method of Manager data archival, restoration of backups, and
importing of exported policies to recover their Manager as part of their IPS DRP.

Enter the MDR feature. With MDR, two Manager servers are deployed as part of the
overall IntruShield system. One host is configured as the Primary system; the other as
the Secondary. Each uses the same major release Manager software with mirrored
databases; however, the two hosts’ hardware configuration does not need to be
identical. The Secondary Manager can be deployed anywhere—for example, at a
disaster recovery site, far from the Primary Manager.

The Primary Manager is the active Manager by default; this Manager communicates
with the Update Server, pushes configuration data to the sensors, and receives alerts
from the sensors.

The Secondary Manager remains in a standby state by default. While in standby mode
it monitors the health status of the Primary Manager and retrieves sensor configuration
information from the Primary Manager at configured intervals of time.

20
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Manager Disaster Recovery (MDR)

The standby Manager receives no data from the sensors while in standby mode.
Note

The Secondary Manager is a warm standby system; it will not guarantee state
synchronization with the Primary Manager. It does update configuration information at
regular intervals (every 15 minutes), but it does not maintain state. (You can also
manually update Secondary Manager configuration rather than waiting for the
automatic update.)

The sensor, for its part, maintains a connection with both Managers; however, only the
active Manager can control sensors and receive alert data, and sensors can only be
added to an active Manager. (A new sensor added to the active Manager in an MDR
pair establishes trust first with the Primary Sensor, and then attempts on its own to
establish trust with the Secondary.)

Figure 2-5 An MDR pair’s communication with sensors

Primary Secondary
(Active) (Standby)
Manager Manager
Alert, packet log
connections
Alert, packet log without data
connections
with data

Sensors in the deployment

Switchover
Switchover, or failover from the Primary to the Secondary, can be manual/voluntary or
involuntary.

In a situation where you have planned manual downtime and the downtime is
expected to be brief, McAfee recommends that you manually suspend MDR,
Note
preventing the Secondary sensor from taking over and becoming active. You can then
resume MDR when the downtime period is over.

The Secondary Manager performs regular “health checks” on the Primary Manager. If
the Primary Manager is found to be unavailable during a health check by the Secondary
Manager, the Secondary Manager waits for a configurable time interval. If the Primary
Manager is still unavailable after that time period elapses, control then switches over to
the Secondary Manager.

You can switch over the Secondary manually, as well.

Note

21
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Entercept integration

Once the Secondary Manager is active, the Primary moves to standby. The sensors are
made aware of the switchover, communicate with the Secondary Manager, and the
system continues to function without interruption.

All “in-flight transactions” are lost upon failover from Primary to Secondary Manager.
For instance, if the Primary Manager failed while a user was in the middle of a policy
edit, the Secondary Manager will not be able to resume the policy edit.

The MDR feature, in fact, assumes that the Secondary Manager is a standby system,
and that it will NOT assume control indefinitely. The Primary Manager should be
Note
diagnosed and repaired, and be brought back online.

While the Secondary Manager is active, McAfee recommends against making any
configuration modifications on the Secondary Manager, as these modifications could
cause potential data synchronization problems when the Primary Manager is
resurrected.

Once the Primary Manager has recovered, you can switch control back to the Primary
system. During this switch back, if you have made configuration changes on the
Secondary, you have a choice whether to retain the configuration on the Primary or
overwrite with changes made on the Secondary. Data is re-synchronized, the sensors
return to communicating with the Primary, and the system is restored with the Primary
Manager active and the Secondary Manager in standby mode.

You can easily dissolve the MDR relationship between the two Managers and return
either Manager to stand-alone mode.
Note

For more information on MDR, see the Manager Administrator’s Guide.

Entercept integration
McAfee Entercept™ is a host-based intrusion prevention system (HIPS). IntruShield can
accept alerts forwarded by an Entercept Management Server, thereby centralizing
management of both products.

Within the IntruShield context, the Entercept Manager functions like an IntruShield
sensor. That is, it forwards events to the Manager, which the Manager incorporates into
its database. Entercept events can therefore be viewed and manipulated like any other
IntruShield alert in the Alert Viewer.

Entercept provides a software development kit (SDK) for Java called the Entercept
Integration Framework, for sending alert information to third-party products, in this
case, IntruShield. The Manager formats Entercept alert information automatically for
viewing in the Alert Viewer and Report Generator.

The Entercept Integration Framework, or Integrator, can be run as a service or

standalone Java application on the Entercept Management Server system. If run as a
service, no interface is presented for the Integrator after communication is established
between Entercept and the Manager. The service runs as long as the Entercept
Management Server system is up. If run as an application, a Java application window
displays the up-time, number of alerts sent, and so forth. If the application window is
closed, alerts are not sent until the application is restarted.

22
McAfee® IntruShield® IPS System 3.1 IntruShield System Basics 2
Getting Started Guide Entercept integration

Each time a new Entercept event occurs, the Manager passes the alert to the
Integrator, which forwards selected information in real time or in batches.

To configure Entercept integration, refer to Chapter 8 of the Manager Administrator’s

Guide.

23
3 Basics of Using IntruShield
A high-level overview of system usage

The tasks described in this chapter provide pointers to more detailed information in the
other books of the McAfee IntruShield IPS System documentation set.

Most of your interaction with the IntruShield system is via the IntruShield Manager.
Note

Overview
The process of setting up and running an IntruShield system falls into these basic
stages:

1 Deciding where to deploy sensors and in what operating mode

2 Setting up your sensors

3 Installing the Manager software and establishing sensor-to-Manager

communication

4 Configuring your deployment using the Manager

5 Updating your signatures and software

6 Viewing and working with data generated by IntruShield

7 Tuning your deployment

Each of these stages consists of a number of tasks; some are simple, some are
complex. You will generally perform steps 1 through 3 only once per sensor.

Deciding where to deploy sensors and in what

operating mode
Where you deploy your sensors and which sensor model to use depends on your
network topology, the amount of traffic on the network, and your security goals, which
– ideally – are specified in your company’s security policy.

24
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Setting up your sensors

„ Determine where you will place the sensors. This is an individual decision your
company will need to make. Questions to ask yourself in making this decision are
covered at a high level in Pre-Installation Considerations on page 33. Some things to
consider are what assets you want to protect, the configuration of your network, the
location of your aggregation points, the type of traffic, how the traffic is routed, and
so on.

„ Establish a naming convention for your sensors. The sensor name is used to
identify the sensor in the Manager interface, in certain reports, and in the alert data
generated by the sensor. McAfee recommends you establish a naming convention
that is easy to interpret by anyone working with the IntruShield deployment. Once
you name a sensor, you cannot rename it without de-installing and reinstalling it.

Setting up your sensors

The process of setting up a sensor is described below at a high level. You perform these
tasks on the sensor.

For detailed instructions on these tasks, see the Sensor Configuration Guide.
Note

1 Position the sensor.

„ Unpack the sensor and place on a sturdy, level counter top.

„ Attach the provided rack mounting ears to the sensor.

„ Install the sensor in a rack. The I-1200, I-1400 and I-2600 are 1-RU boxes; the
I-2700, I-3000, I-4000 and I-4010 are 2-RU boxes.

2 Install any additional hardware.

„ Install GBICs or SFP GBICs (not included) in the GBIC slots.

Table 3-1 GBIC slots per sensor model

Sensor model Number of slots
I-2600 2
I-2700 2
I-3000 12 (SFP slots)
I-4000 4
I-4010 12 (SFP slots)

To ensure compatibility, McAfee supports only those GBIC or SFP GBIC modules
purchased through McAfee or from a McAfee-approved vendor. For a list of approved
Note
vendors, see the on-line KnowledgeBase.

„ (Optional) If you have purchased a redundant power supply for the I-4000 or
I-4010, install the power supply.

25
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Establish sensor-to-Manager communication

Table 3-2 Models supporting a redundant power supply

Sensor model Power supply
I-1200 1 internal
I-1400 1 internal
I-2600 1 internal
I-2700 1 included
1 redundant available separately
I-3000 1 included
1 redundant available separately
I-4000 1 included
1 redundant available separately
I-4010 1 included
1 redundant available separately

3 Cable the sensor for configuration.

„ Attach network cables to the sensor as described in each sensor’s Product

Guide. You must cable the sensor Management and Console ports, respectively,
to communicate with the Manager server and the console machine you will use
to configure the sensor. You can cable the sensor Monitoring and Response ports
at a later time.

„ Power on the sensor to initialize it.

Establish sensor-to-Manager communication

The process of setting up a sensor is described below at a high level.

1 Set up the Manager software on the server machine.

„ Install the Manager software on the server machine. This process is

described in detail in the Manager Installation Guide.

„ Start the Manager software as described in the Administrator’s Guide. You can
establish communication with a sensor via the Manager server or from a browser
on a client machine that can connect to the Manager server.

McAfee recommends you connect to the Manager server via browser session
from a separate client machine to perform your configuration tasks.

„ You can choose a specific policy to apply by default to the Root Admin Domain
(and thus all monitoring interfaces on the sensor). By default, the provided
Default policy is applied to all of your sensor ports upon sensor addition.

For a description of admin domains, see Administrative Domains on page 56. For a
discussion of policies, see Working with Security Policies on page 60.
Note

Whatever policy you’ve specified will apply until you make specific changes; the
Default policy gets you up and running quickly. Most users tune their policies over
time, in conjunction with VIPS, to best suit their environments and reduce the
number of irrelevant alerts.

26
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Viewing and working with data generated by IntruShield

„ Open the System Configuration tool and add the sensor, providing the sensor
with a name and a shared secret key value. This process is described in detail in
Chapter 8 of the Administrator’s Guide.

2 Configure the sensor.

„ From a serial console connected physically or logically to the sensor, configure

the sensor with network identification information (i.e., IP address, IP address of
the Manager server, and so on), and configure it with the same case-sensitive
name and shared secret key value you provided in the Manager.

For detailed instructions on configuring the sensor using the sensor CLI, see the
Sensor Configuration Guide.
Note

3 Verify communication between the sensor and the Manager.

„ Verify on the sensor CLI the health of the sensor and that sensor has established
communication with the Manager. Use the status command.

„ Verify in the Manager interface that a node representing the sensor appears in
the Resource Tree under the Sensors node. Viewing the Resource Tree is
described in The Resource Tree on page 51.

4 Troubleshoot any problems you run into.

„ If you run into any problems, check your configuration settings, and ensure that
they’re correct. For some troubleshooting tips, see the Troubleshooting chapter
of the Sensor Configuration Guide.

5 Verify the operating mode of the ports on your sensor.

„ Your IntruShield sensor ports are configured by default for monitoring in in-line
mode; that is, connected via a port pair on the sensor to a segment of your
network. If you’ve cabled the sensor to monitor in in-line mode, check your
settings to make sure everything is correct.

Verifying port configuration is described in detail in Chapter 8 of the

Administrator’s Guide.

Viewing and working with data generated by IntruShield

Once you’ve completed the steps in the previous sections, you’re up and running.
While actively monitoring network traffic, your sensor will generate alerts for traffic that
is in violation of the set security policy.

IntruShield displays a summary view of the count of alerts in the Network Console,
organized by severity (High, Medium, Low, and Informational). IntruShield provides two
tools for examining and viewing the alerts:

27
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Configuring your deployment using the Manager

„ The Alert Viewer enables you to drill down to the details of an alert such as what
triggered the alert, when, what sensor detected it, the source IP address of the
attack that triggered the alert, the destination IP address of the attack, and so on.
You use the Alert Viewer to perform forensic analysis on the alert to help you tune
the IntruShield system, provide better responses to attacks, and otherwise shore up
your defenses.

„ The Report Generator enables you to provide detailed reports based on your alerts,
and reports on your IntruShield configuration. You can use these reports to
communicate incidents to other members of your team and to your management.

Both tools are described in detail in the Manager Administrator’s Guide.

Note

Configuring your deployment using the Manager

Once you’re up and running and reviewing the data generated by the system, you can
further configure and maintain your system. For example, you can do the following:

„ Apply security policies to each interface of your multi-port IntruShield sensor

(instead of applying one policy to all interfaces, as when you chose the default policy
in Establish sensor-to-Manager communication on page 26, above). You can ensure
all of your interfaces use policies specifically for the areas of your network they are
monitoring. For example, you can apply the Web Server policy to one interface, a Mail
Server policy to another, the Internal Segment policy to another, and so on. For more on
the provided policies, see IntruShield policies on page 60.

„ Configure responses to alerts. Developing a system of actions, alerts, and logs

based on impact severity is recommended for effective network security. For
example, you can configure IntruShield to send a page or an email notification,
execute a script, disconnect a TCP connection, send an “ICMP Host Not Reachable”
message to the attack source for ICMP transmissions, or send address-blocking
filters to a firewall.

For more information on response actions, see Response management on page 70.
For information on configuring pager, email, or script notification, or configuring a
firewall response, see Chapter 5 of the Administrator’s Guide.

„ Filter alerts. An alert filter limits the number of alerts generated by the system by
excluding certain Source and Destination IP address parameters. If these address
parameters are detected in a packet, the packet is not analyzed further (and is
automatically forwarded when in In-line Mode). For more information on alert filters,
see Chapter 7 of the Administrator’s Guide.

„ View the system’s health. The System Health viewer details the functional status
for all of your installed IntruShield system components. Messages are generated to
detail system faults experienced by your IntruShield Manager, sensors, or database.
For more information, see Chapter12 of the Administrator’s Guide.

„ View a port’s performance. The Performance Statistics action enables you to view
performance data for a port on a sensor. The data collected is a reflection of the
traffic that has passed through the port. For more information, see Chapter 8 of the
Administrator’s Guide.

28
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Updating your signatures and software

„ Back up all or part of your Manager configuration information to your server or

other location. IntruShield provides three backup options:

„ All Tables: all IntruShield data (configuration, audit, and alert).

„ Config Tables: all information related to system configuration, such as port

configuration, users, admin domains, policies for all IntruShield resources in all
domains.

„ Audit and Alert Tables: all information related to user activity and alerts.

The All Tables and Audit and Alert Tables options can be rather large in size, depending
upon the amount of alert data in your database. McAfee recommends saving these
Note
types of backups to an alternate location.

For information on how to back up your data, see Chapter 6 of the Administrator’s
Guide.

Updating your signatures and software

An essential element to a reliable IPS is updating the system signature and software
images. McAfee periodically releases new Manager software and sensor signature and
software images, and makes these updates available via the IntruShield Update Server
to registered support customers.

29
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Updating your signatures and software

Figure 3-1 Update Options

Manager software installation includes a default signature set image.

Note

There are several options for loading updates to your Manager and sensors.

1 Download images from the update server to your Manager.

„ You can use the Manager interface to download sensor software and signature
updates from the Update Server to the Manager server, and then download the
sensor image to the sensor. These actions are explained in the Administrator’s
Guide.

2 Import image files from a remote workstation to your Manager.

„ If your Manager server is not connected to the Internet, you can download the
updates from the Update Server to any host, then do one of the following:

30
McAfee® IntruShield® IPS System 3.1 Basics of Using IntruShield 3
Getting Started Guide Tuning your deployment

„ Download the image to a remote host, then log in to the Manager via
browser session on the remote host and import the image to the
Manager server. You can then download the sensor image to the
sensor. See Chapter 6 of the Manager Administrator’s Guide.
„ Similar to above, download the image from the Update Server to any
host, put it on a disk, take the disk to the Manager server, and then
import the image and download it to the sensor.

3 Download sensor software from the Update Server to a TFTP client then to a
sensor.

„ You can download the software image from the Update Server onto a TFTP
server, and then download the image directly to the sensor using commands on
the sensor CLI. This is useful if you prefer not to update sensor software via the
Manager, or you may encounter a situation wherein you cannot do so. This
method is described in the Sensor Configuration Guide.

Tuning your deployment

Once you become familiar with the basics of the IntruShield Manager program, you can
further enhance your deployment by utilizing some of the more advanced features.
These features include:

„ Cloning and modifying an IntruShield-provided policy. See Working with

Security Policies on page 60.

„ Deploying your sensor to monitor traffic in Tap mode or, ultimately, in In-line
mode. See IntruShield Sensor Deployment Modes on page 38.

„ Adding users and assigning management roles. See Managing Users in

IntruShield on page 79.

„ Adding admin domains for resource management. See Administrative Domains

on page 56.

„ Changing your interface type to CIDR or VLAN depending on your network

configuration. See Chapter 9 of the Administrator’s Guide.

„ Using Access Control Lists (ACLs) to block traffic or pass traffic without
sending it through the IDS engine. See Chapter 9 of the Administrator’s Guide.

31
SECTION 2

Getting Ready to Deploy

IntruShield

Chapter 4, Pre-Installation Considerations

Chapter 5, IntruShield Sensor Deployment Modes
4 Pre-Installation Considerations
Before you deploy the IntruShield system

This chapter discusses the considerations and pre-installment steps that require
planning and completion before you deploy the IntruShield IPS.

If you are a beginner and want some strategies for deploying IntruShield, you should
also read Deployment for Beginner, Intermediate, and Advanced Users on page 94.
Tip

Pre-deployment questions
Deployment of an IntruShield IPS requires specific knowledge of your network’s
security needs. Answering these questions will determine which sensor model will
best suit your environment, and what in what operating mode you’ll need to employ
each sensor port.

Consider the following questions as you plan your IntruShield deployment:

„ What is the size of your network?

„ How many access points are there between your network and the extranets or
Internet?

„ Where are the critical servers that require protection within your network?

„ How complex is your network topology?

„ How much traffic typically crosses your network?

„ Where are your security operations located?

„ Where should I deploy sensors?

What is the size of your network?

The size of your network will determine the number of sensors you will require to
successfully and efficiently protect your network. A large network with many access
points, file servers, and machines in use may require a larger level of IPS deployment
than a small office with just a single access point and few machines.

33
McAfee® IntruShield® IPS System 3.1 Pre-Installation Considerations 4
Getting Started Guide Pre-deployment questions

Knowing how your business will grow can help determine the amount of equipment
you will require and the proper strategy for network placement. IntruShield products
are built with growth in mind. The IntruShield Security Management system can
manage multiple sensors, and IntruShield sensors can scale in performance from
100Mbps to multi gigabits per second for monitoring network segments.

How many access points are there between your network and
the extranets or Internet?
Large corporations have several points of access that can be exploited by parties with
malicious intent. Protecting the various points of access to your network is key to any
successful IDS install. You’re only as strong as your weakest link.

Intrusions coming in from the Internet are important to combat, but misuse and
intrusions attempted through the extranets or inside the corporate network are equally
as critical to defend against. In fact, research statistics show that insiders are the most
common source of attacks.

Where are the critical servers that require protection within your
network?
File servers containing financial, personnel, and other confidential information need
protection from those people wishing to exploit your critical information. These
machines are extremely appealing targets. And, as discussed in the previous section,
insiders pose a threat that must be addressed.

You should also consider whether you need different levels of security for different
parts of the organization. Assess how much of your sensitive material is on-line, where
it is located, and who has access to that material.

How complex is your network topology?

Asymmetrically routed networks are complex environments that require careful
planning and execution.

Figure 4-1 on page 35 shows a network protected by an IntruShield sensor in tap

operating mode. Since both links are monitored by the same sensor, the state machine
remains in sync. An IntruShield sensor can support an Active-Active configuration as
long as the aggregate bandwidth does not exceed the total processing capacity of the
sensor.

Furthermore, a sensor can also monitor asymmetrically routed traffic where the traffic
comes in on one link and goes out another link, because the state machine on the
sensor associates the inbound and outbound traffic efficiently. For more information on
monitoring asymmetrically routed traffic, see the section Interface groups on page 48.

34
McAfee® IntruShield® IPS System 3.1 Pre-Installation Considerations 4
Getting Started Guide Pre-deployment questions

Figure 4-1 Tap Monitoring of Active-Passive Links

How much traffic typically crosses your network?

Bandwidth and traffic flow are crucial to running a successful enterprise network.
Bandwidth requirements will vary in an enterprise network, as different applications
and business functions have different needs. Bandwidth utilization on the network
segments that you need to monitor will determine what type of sensor will work best
for you. IntruShield offers multiple sensors providing different bandwidths:
Table 4-1 IntruShield sensor bandwidth
Sensor Aggregate Performance
I-1200 100Mbps
I-1400 200Mbps
I-2600 600Mbps
I-2700 600Mbps
I-3000 1Gbps
I-4000 2Gbps
I-4010 2Gbps

Where are your security operations located?

To successfully defend against intrusions, McAfee recommends dedicated monitoring
of the security system. Network intrusions can happen at any given moment, so having
a dedicated 24-hour-a-day prevention system will make the security solution complete
and effective.

Where are your security personnel? How many users are involved? Knowing who will
be configuring your policies, monitoring events, running reports, and performing other
configuration tasks will help you manage your users and determine where you locate
your Manager server. The Manager should be placed in a physically secure location,
should be logically accessible to users, and must have reliable connectivity so as to be
able to communicate with all deployed sensors.

35
McAfee® IntruShield® IPS System 3.1 Pre-Installation Considerations 4
Getting Started Guide Pre-deployment questions

Where should I deploy sensors?

Should you deploy sensors at the perimeter of your network, in front of the servers you
want to protect, or at a convenient nexus where all traffic passes?

Deployment at the perimeter does not protect you from internal attacks, which are
some of the most common source of attacks. Perimeter monitoring is also useless if a
network has multiple ISP connections at multiple locations (such as one Internet
connection in New York and one in San Jose) and if you expect to see asymmetric traffic
routing (i.e., incoming traffic comes through New York and outgoing traffic goes out
through San Jose). The IPS simply will not see all the traffic to maintain state and detect
attacks. Deployment in front of the servers that you want to protect both detects
attacks from internal users and deals effectively with the geographically diverse
asymmetric routing issue.

An illustration of the advantage of IntruShield sensors’ multiple segment monitoring is

to consider the question of installing IPS sensors with respect to firewalls. It is very
common to deploy IDS sensors around firewalls to inspect the traffic that is permitted
by the firewall. A common question when installing sensors around the firewall is, “do
you put the sensors on the inside (Private and DMZ) or put them outside (Public) the
firewall?” There are benefits to both scenarios, and the more complete solution
includes both. For example, if you detect an attack on the outside of the firewall and
you detect the same attack on the inside of the firewall, then you know your firewall
has been breached. This is obviously a much higher severity event than if you were just
to see the attack on the outside and not on the inside, which means that your firewall
blocked the attack.

When using the existing, single monitoring port products available today, you would
have to deploy multiple sensors to get the required coverage (as shown on the left side
of Figure 4-2 on page 37). Furthermore, you’d need to figure out how to connect them
to the segments that you want to monitor, and only via a SPAN or hub port.

Consider the same scenario using the I-2600 sensor (as shown on the right side of
Figure 4-2). You can simultaneously monitor all three segments with one sensor, and,
with the integrated taps, you can easily monitor the full-duplex uplinks between your
routers and the firewall. You can also run the inside connections in in-line mode, which
provides intrusion protection/prevention, while running the outside connection in
tapped mode.

36
McAfee® IntruShield® IPS System 3.1 Pre-Installation Considerations 4
Getting Started Guide Pre-deployment questions

Figure 4-2 Comparing IDS Sensor Deployment Scenarios

Other Vendors’ Sensor Deployment IntruShield Sensor Deployment

37
5 IntruShield Sensor Deployment
Modes

This chapter presents suggestions for implementing IntruShield products in a variety of

network environments.

Flexible deployment options

IntruShield offers unprecedented flexibility in sensor deployment. IntruShield sensors
can be deployed in a variety of topologies and network security applications, providing
industry-leading flexibility and scalability. Most PC-based IDS sensors on the market
today can monitor only one network segment at a time, and only via the SPAN port on
a switch. Thus, to monitor a switched environment with multiple segments and
multiple switches deployed in a high-availability environment, you would need multiple
sensors.

Multi-port sensor deployment

Unlike single-port sensors, a single multi-port IntruShield sensor can monitor many
network segments (up to twelve, in the case of the I-3000 or I-4010) in any combination
of operating modes—that is, the monitoring or deployment mode for the sensor
—SPAN, Tap, or In-line mode. Additionally, IntruShield’s Virtual IPS (VIPS) feature
enables you to further segment a port on a sensor into many “virtual sensors.”

This makes deployment easy; not only can you use one sensor to monitor multiple
network segments, but you also can configure the sensor to run whatever mode best
suits each network segment.

Supported deployment modes

Every port on an IntruShield sensor supports the following deployment modes:

„ SPAN or Hub

„ Tap

„ In-line, fail-closed

„ In-line, fail-open

Additionally, IntruShield provides features vital to today’s complex networks: interface

groups (also called port clustering), and high-availability.

38
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Flexible deployment options

In the example illustrated in Figure 5-1, a single IntruShield I-2600 sensor is deployed
to monitor the several external and internal points of exposure of an enterprise
network. This includes the Web Presence, Corporate Internet Access for employees,
employee Remote Access, Extranet connections, and internal attacks on critical
department servers such as Finance and HR.

Figure 5-1 IntruShield IPS protecting enterprise network

In this example, the ports on this I-2600 sensor might be configured as such:

„ Tap 1: Ports 1A and 1B run in Tap mode and respond to attacks via Response port R1.

„ Tap 2: Ports 2A and 2B run in Tap mode and respond to attacks via Response port R2.

„ SPAN from Switch A: Port 3B runs in SPAN mode and inject response packets back
to the switch through the SPAN port.

„ SPAN from Switch B: Port 3A runs in SPAN mode and responds to attacks via
Response port R3.

Full-duplex and half-duplex monitoring

IntruShield sensors are equipped with multiple Monitoring and Response ports. By
default, the sensor ports are internally wire matched (i.e., 1A and 1B) to monitor traffic
in full-duplex pairs, that is, two detection ports work together to monitor traffic flowing
in both directions.

39
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Deploying sensors in in-line mode

To monitor a full-duplex segment in In-line or Tap mode, you use two sensor ports (one
port for transmit, one for receive). SPAN port monitoring receives on one port and can
respond via the same port (if the switch supports this feature).

Sensor Model Supported number of Supported number of

full-duplex links half-duplex links
I-1200 1 2
I-1400 2 4
I-2600 4 8
I-2700 4 8
I-3000 6 12
I-4000 2 4
I-4010 6 12

„ In-line mode and tap mode both can both monitor full-duplex links.

„ SPAN monitoring works in either half- or full-duplex mode (depending on the switch).

„ Hub monitoring works in half-duplex mode.

Deploying sensors in in-line mode

In-line mode is achieved when an IntruShield sensor is placed directly in the path of a
network segment, becoming, essentially, a “bump in the wire,” with packets flowing
through the sensor. In this mode, the sensor can prevent network attacks by dropping
malicious traffic in real time. Preventative actions can be at a highly granular level,
including the automated dropping of DoS traffic intended for a specific Web server.

IntruShield sensors are configured by default to run in in-line mode.

Note

When running in in-line mode, network segments are connected to two matched ports
of the sensor (e.g., ports 1A and 1B), and packets are examined in real time as they
pass through the sensor.

The benefits to using IntruShield sensors in in-line mode are:

„ Protection/Prevention. Prevention is a feature unique to in-line mode. Basically, if

you’re running in any “sniffing” mode, there is no way for the IPS to prevent
malicious packets from reaching their intended target. In a sniffing mode, the sensor
sees the attack at the same time it hits the target. You can apply some
countermeasures, like TCP Resets and reconfiguring firewall rules, but these are
post-detection actions. The only way to prevent the malicious packets from reaching
the target is to mediate the traffic flow.

When running in-line, an IntruShield 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,
IntruShield 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).

40
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Deploying sensors in in-line mode

One of the problems with using firewall reconfiguration actions with current IDS
products is that an attacker can spoof large address ranges and mislead you into
blocking legitimate traffic with the firewall, creating your own denial of service
condition. IntruShield only drops the malicious packets, so spoofed traffic doesn’t
have the same effect.

„ Packet “scrubbing.” In addition to dropping malicious traffic, IntruShield can

scrub—or normalize—traffic to take out any ambiguities in protocols that the
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. An obvious requirement with running in-line is to avoid

dropping packets and your IDS sensor becoming a bottleneck. IntruShield sensors
are able to process packets at wire rates.

„ High-availability. In in-line mode, the sensor does become a single point of failure,
so the sensors support complete stateful fail-over, delivering the industry's first true
high-availability IPS deployment, similar to what you’d find with firewalls. If you’re
running in-line, McAfee recommends that you deploy two sensors redundantly for
failover protection.
Figure 5-2 In-line mode

In in-line mode (seen in Figure 5-2), the IntruShield 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.

When deployed in-line, you must specify whether the sensor port is monitoring inside
or outside of the network it is protecting. For example, the sensor shown in Figure 4-1
on page 35 is monitoring links both inside and outside the network.

41
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Deploying sensors in in-line mode

Fail-open versus fail-closed

IntruShield sensor ports deployed in In-line 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 which may allow bad traffic 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.

Fail-open option for GE ports

Gigabit Ethernet ports on IntruShield sensors require the connection of an optional
optical bypass switch and controller card for In-line Fail-open functionality; no extra
hardware is required for In-line Fail-closed mode. This hardware is contained in the
Optical Bypass Gigabit Fail-open Kit, sold separately.

Refer to the Optical Bypass Gigabit Fail-open Kit Quick Guide for hardware connection
information. Then see the Administrator’s Guide for port configuration information.

Fail-open option for FE ports

Fast Ethernet ports require the use of fail-closed dongles for fail-closed mode; no extra
hardware is required for In-line Fail-open mode for FE ports.

Fail-open option: Layer 2 Passthru mode

Fail-open operation provides a measure of network integrity when a sensor fails. When
a sensor with ports operating in In-line Fail-Open Mode experiences a critical fault, the
sensor reboots; during the reboot, the sensor goes into fail-open mode until it restarts.
If a critical fault occurs again, another reboot cycle is initiated. This can continue until
acted upon through human intervention.

You can enable a failure threshold to automatically initiate fail-open, or passthru, mode
by configuring the Layer 2 Passtrhu (L2) feature from the Manager interface. This feature
enables you to set a threshold on the number of critical failures within a configured
period of time that the sensor can experience before being forced into passthru mode
at Layer 2.

For example, you configure Layer 2 Passthru mode to enable if there are three critical
faults in any 10-minute period. At minutes 1, 3, and 7, faults occur; L2 mode is enabled.
Here is another scenario: at minutes 1, 4, 11, and 13, faults occur. In this case, the last
three faults occurred within 10 minutes of each other, thus the sensor enters L2 mode.

Sensor reboot may take a few minutes to complete. This downtime is not counted
against the L2 duration; only sensor uptime is counted.

The L2 feature is supported by all models of sensor. For enabling Layer 2 Passthru
Mode, refer to Chapter 9 of the Manager Administrator’s Guide.

42
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Deploying sensors in tap mode

Deploying sensors in tap mode

A tap—internal or external—is a passive wiring device that copies traffic on full-duplex
Ethernet segments, and sends this copied traffic information to the sensor processors
for analysis.

Full-duplex taps split a link into separate transmit and receive channels. IntruShield
sensors provide multiple monitoring interfaces to monitor the two channels, and sensor
ports are wired in pairs in order to accommodate full-duplex taps. Two monitoring ports
are used to monitor one full-duplex link using a tap.

Tap monitoring (Figure 5-3 on page 43) can work in one of two ways for the 10/100
Monitoring ports on the I-1200 and I-2600 sensors: the internal tap can be enabled, or
the interface can be connected to an external tap. Sensor GBIC ports must use an
external tap.

The benefits to using IntruShield sensors in tap mode are:

„ Monitor uplinks passively. Taps cause no latency in your network traffic. You
essentially sniff traffic as it passes.

„ No need for SPAN ports. On most switches, the SPAN port operates in half-duplex
mode, so the maximum bandwidth a Fast Ethernet port can handle is 100Mbps
before it begins dropping packets. If the uplink is running at more than 100Mbps
aggregate, a Fast Ethernet SPAN port can’t handle it; a full-duplex tap can. Another
issue is that there are a limited number of SPAN ports supported on most switches,
and there is typically a lot of competition for them (e.g., for RMON probes, sniffers,
etc.).

„ Traffic continues to flow if the tap fails. Completely passive and fault tolerant, taps
provide fail-safe operation with no impact on network connectivity or performance.
Taps fail open, meaning that a failed sensor permits traffic to continue to flow
unimpeded.

The downside of tapped mode is that, unlike in-line mode, you cannot prevent attacks.
Tap mode is passive; the sensor essentially sees malicious traffic as it passes, so
sensing an attack in tap mode triggers a response post-attack. You also cannot inject
response packets back through a tap; the sensor provides Response ports to inject
response packets.

Figure 5-3 Tap mode

43
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Deploying sensors in tap mode

Deploying the sensors with FE ports in internal tap mode

The 10/100 (FE) monitoring ports can process network traffic in full-duplex stealth mode
by enabling internal taps. in this mode, network segments are connected as in in-line
mode, but the sensor handles the traffic differently. The enabled internal tap receives
the traffic, makes a copy of the incoming packets, and sends the copy to the sensor’s
detection processor as it forwards the packets.

By sensor default, the ports (xA and xB, illustrated with 1A and 1B in Figure 5-4) are
matched for full-duplex tap mode monitoring. Data is looped back within the tap and a
copy is forwarded to the rest of the sensor per port. Responses are sent through a
Response port to a switch or router.

The internal taps of these three sensors fail open; thus if the sensor should fail, data
will continue to flow unimpeded.

You can easily reconfigure the 10/100 monitoring ports of the I-1200, I-1400 and I-2600
to disable the internal tap and monitor in In-line Mode at any time via the Manager. This
process is described in the section, Shifting from tap mode to in-line mode on page 45.
When in-line, the sensor can block malicious traffic from reaching its intended target
host.

Figure 5-4 I-2600 Sensor: Internal Tap Mode

Deploying sensors with GE ports in external tap mode

Sensors with GE monitoring ports require external taps. The external taps are
full-duplex; they connect in-line with the network segment, copy the traffic, and send
the copies to the sensor for analysis.

44
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Deploying sensors in tap mode

Figure 5-5 I-4000 sensor deployed in tap mode

Shifting from tap mode to in-line mode

You can easily shift from tapped to in-line mode. If you are running a sensor with built-in
taps in internal tap mode, you can toggle between tap and in-line mode with a simple
software configuration command from the Manager’s System Configuration tool. Thus,
you can run in tap mode until you feel comfortable with the sensor’s reliability, and then
shift into in-line mode without needing to touch the sensor. You can also mix modes
with the ports on the I-2600. You can run one pair in In-line Mode and others in Tap
mode. With the GE port-sensors, you’ll have to do some minimal re-cabling to convert
from tap to in-line mode.

SPAN port and hub monitoring

IntruShield sensors can connect to the SPAN port of a switch or to a port on a hub. Most
vendors’ IDS sensors are deployed in this manner, and many beginning IntruShield
users choose to deploy in this mode. The Switch Port Analyzer (SPAN) port is designed
for troubleshooting and network analysis so that an attached network analyzer can
receive a copy of every single packet that is sent from one host to another through the
switch. The SPAN port forwards all incoming and outgoing traffic within the switch to a
predetermined port where a sensor or a sniffer is connected. This is called port
forwarding or port mirroring, and it allows an attached device to monitor all traffic of that
switch.

When monitoring SPAN ports and hubs, traffic is typically half-duplex. Only one
monitoring port is required to monitor each SPAN or hub port. You can send a response
back through a hub; if you choose to send a response back through the SPAN port, you
can do so if the switch supports transmit back through the SPAN port.

If the switch does not support transmit back through the SPAN, you can send a
response via a sensor response port.
Note

45
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide High-Availability

SPAN port and hub monitoring

When monitoring a SPAN or hub port, sensors with internal taps disabled.

McAfee recommends cabling your Fast Ethernet ports with fail-closed dongles if
deploying in SPAN or Hub mode.
Note

In Figure 5-6 on page 46, which shows an I-4000 sensor, Port 1A receives data from the
SPAN port of SwitchA. Port 1B gets data from the SPAN port of SwitchB. Two distinct
network links from two separate switches are monitored by the one active I-4000
sensor with a 1Gbps rate per link to the sensor, allowing a total of 2Gbps traffic to the
IPS engine.

Figure 5-6 SPAN Port Monitoring

High-Availability
Redundancy is a key element for any network requiring 24x7 uptime. Using an identical
pair of sensors (same model, software image, signature set) deployed redundantly in
In-line Mode, IntruShield can provide high availability with no administrator intervention.

Understanding failover in IntruShield

In typical failover configurations, one device is the “Active” device while the other is the
“Standby.” As its name implies, the active device performs normal network functions
while the standby monitors, ready to take control should the active device fail.

In IntruShield, because both failover sensors must be ready to process packets on their
monitoring ports at all times, both sensors are actually active at all times; neither sensor
is inoperative, or ‘standing by’ unless the unit has failed. Instead, both sensors operate
normally.

46
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide High-Availability

In Figure 5-7 on page 47, for example, two sensors are placed in-line, connected to
each other via cables, and configured to act as a Failover Pair. All traffic is copied and
shared between 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.

Figure 5-7 Two I-4000s in a High-Availability configuration

“Primary” versus “active”

You configure a Failover Pair using the Manager’s System Configuration tool. You
designate one sensor as the Primary sensor and the other as Secondary. This
designation is used purely for configuration purposes and has no bearing on which
sensor considers itself active.

Once configured, the two sensors exchange information to determine their respective
roles; the sensor that has been online the longest becomes the active sensor. If they
have been online for exactly the same amount of time, the sensor with the higher serial
number takes the active role. The sensors communicate every second to determine if
their peer is available. If the failover pair cannot communicate with each other, each
sensor will assume its peer sensor is down, and both will issue alerts. If communication
is re-established, the two sensors communicate to determine their respective failover
roles.

When one sensor is brought up well after the other, the new sensor synchronizes state
with the old sensor and builds on the synchronized state based on the packets received
on its monitoring and interconnect ports.

This Active-Active configuration provides the added benefit of supporting asymmetric

traffic flows (i.e., when packets belonging to the same TCP/UDP flow are divided
across sensors). Thus, an IntruShield failover pair will detect attacks even when the
traffic is asymmetric. This topic is discussed below, in the section Interface groups on
page 48.

47
McAfee® IntruShield® IPS System 3.1 IntruShield Sensor Deployment Modes 5
Getting Started Guide Interface groups

Interface groups
An interface group, also known as port clustering in networking parlance, combines the
traffic processed on separate sensor interfaces—or, in the case of a Failover Pair, on
separate sensors—into a single logical interface for state and intrusion analysis.
Asymmetric routing is a good example of where an interface group is recommended.
In asymmetric routing, a TCP connection does not always send and receive along the
same network path. Therefore, a single-interface sensor monitoring this transmission
may only see the traffic received, not the traffic sent in response; thus not seeing all
data from a transmission.

IntruShield sensors’ multiple interfaces make the monitoring of asymmetric traffic

possible. For example, as shown in Figure 5-8, an I-4000 has four ports that are wired
in pairs by default, and therefore two interfaces. Peer ports 1A and 1B can monitor one
direction of an asymmetric transmission, while peer ports 2A and 2B can monitor the
other direction. By making an interface group of 1A-1B and 2A-2B, the sensor is able to
see all the traffic for all sessions in the asymmetrically routed network and still is able
to maintain state and accurately detect all attacks.

Figure 5-8 Interface groups in an asymmetric network

For more information on creating interface groups, see Chapter 8 of the

Administrator’s Guide.
Note

48
SECTION 3

Working with IntruShield

Resources

Chapter 6, Working with IntruShield Resources

Chapter 7, Administrative Domains
Chapter 8, Working with Security Policies
Chapter 9, Managing Users in IntruShield
Chapter 10, Working with Alerts
6 Working with IntruShield Resources
Relationships between IntruShield resource components

IntruShield resources
An IntruShield deployment consists of the following resources and relationships
between resources.

The resources described here are documented in later chapters of this Guide, and in
more detail in the Administrator’s Guide.
Note

„ Admin Domains. Administrative Domains, or admin domains for short, are optional
organizational tools that enable you to logically partition your IPS into discrete
portions and delegate their management to specific users. (For example, your
company might have a New York office and a San Jose office. You can create a NY
admin domain, organize all of the resources protecting the New York office in that
domain, and delegate its management to the New York administrator.)

The entire IntruShield deployment is organized under the Root Admin Domain, which
is represented in the Resource Tree illustrations in this chapter as My Company.

For more information on Admin Domains, see Administrative Domains on page 56.

„ The Manager. The Manager is the overall system orchestrator.

You use the Manager to add, configure, administer, and manage the physical
resources (hardware and software server, OS, and software components running
on the server) that comprise the IntruShield system. Within the Manager resource,
you can also configure global properties, such as update schedules, data backups,
proxy server settings, and so forth. You can also deploy two Managers for a
high-availability configuration.

For more information on Manager HA, see Manager Disaster Recovery (MDR) on
page 20

„ Users and Roles. You can specify users of the system, and then assign them roles
in an admin domain that permit them to perform the management and/or
configuration tasks available to the role within that admin domain. For fine-grained
customization of user roles, you can create custom roles and assign specific abilities
to each role.

For more information on users and roles, see Managing Users in IntruShield on
page 79.

50
McAfee® IntruShield® IPS System 3.1 Working with IntruShield Resources 6
Getting Started Guide IntruShield resources

„ Sensors. Sensors are the monitoring devices you configure to detect attacks. Each
sensor resource enables a variety of actions. Sensors are represented logically in
the Manager by a user-given name with all corresponding interfaces and
sub-interfaces displayed as hierarchical children. Sensor interfaces and
sub-interfaces are the manifestation of the IntruShield’s Virtual IPS (VIPS) feature.
Two sensors of the same model can also be grouped into failover pairs, to provide
high network availability.

Sensor node actions include exporting and importing of individual sensor

configuration files, correspondence with a firewall, configuration of sensor ports,
and updating of a sensor’s configuration.

„ Interfaces. An interface has both physical and logical attributes.

An interface is represented as a single physical port on the sensor (i.e., port 1A) or
a pair or ports (i.e., ports 1A and 1B).

An interface also has a logical connotation in that it allows the user to describe how
they wish to segment the traffic flowing through it. A logical interface allows the
user to configure it to be dedicated (unspecified, undefined traffic), VLAN (traffic
marked with specific VLAN tags), or CIDR (traffic within a block of specific IP
addresses). You can also logically group interfaces into an interface group to monitor
an asymmetric traffic flow.

Interface nodes enable application of IPS policy, creation of sub-interfaces for more
granular policy application, as well as creation of granular Denial of Service policies.

„ Sub-Interfaces. Sub-interfaces are logical subdivisions of interfaces. If an interface

is connected to a segment that is transmitting VLAN or CIDR traffic, the interface
can be segmented into several smaller groupings called sub-interfaces. One would
normally configure a sub-interface for the purpose of applying a different policy than
what is applied to the rest of the interface or to group various unique traffic
instances with others that have common characteristics. Sub-interface node actions
are a subset of the interface node actions.

„ Policies. Policies are the rule sets that instruct the sensor on what events to detect
and what to do when the event occurs. You can apply separate policies to an admin
domain (wherein it would be applied to all interfaces on any sensors in that domain),
to interfaces, and to sub-interfaces.

Policy node actions include creation of alert filters, rule sets, policies, and
user-defined signatures, viewing of applied policy(ies), and export/importing of
policy from/to the Manager.

For more information on policies, see Working with Security Policies on page 60.

The Resource Tree

The Resource Tree, which is located in the IntruShield Manager’s System
Configuration tool, is a hierarchical view of all your physical and virtual IntruShield
resources reporting to the Manager. (The Manager is also depicted in the Resource
Tree).

When you first log in, the System Configuration tool displays four primary nodes on the
Resource Tree: the Root Admin Domain node (which displays a user-configured name
representing the overall system—in Figure 6-1, the name is My Company), the Manager
node, the Policies node, and the Sensors node.

51
McAfee® IntruShield® IPS System 3.1 Working with IntruShield Resources 6
Getting Started Guide Relationship between sensors and resources in the Resource Tree

The hierarchical view within the Resource Tree applies to the way the nodes are
managed by IntruShield users and not necessarily to any networking or physical
Note
relationship between the resources. Nodes and the inheritance relationship between
nodes are described in Nodes on page 58, and Inheritance on page 58.

Figure 6-1 The Resource Tree with the basic nodes displayed

Root Admin Domain Node

Manager Node
Policies Node
Sensors Node

As you configure your deployment, additional resources—such as sensors—will appear

in the tree. Multiple new nodes may display as you leverage their features within
IntruShield: the Failover Pairs node, the Interface node, and the Sub-Interface node.

User-configured resources are represented with the same or a similar icon as one of
the primary nodes, but labeled with the name you specified when you created the
resource. For example, if you add a sensor to the Manager, and name the sensor
“Bldg1Sensor,” the sensor appears in the list labeled as Bldg1Sensor.

Resources are described in more detail in the chapter on using the System
Configuration tool in the Administrator’s Guide.

Working with the Resource Tree

To configure your system, you click on one of the nodes in the Resource Tree.
Configuration options specific to that resource appear in the right pane of the System
Configuration tool.

As you make configuration changes to resources, bear in mind that many

configuration changes do not take effect until you push the changes to the sensor.
Note

For more information on configuring your resources, see Chapter 4 of the

Administrator’s Guide.

Relationship between sensors and resources in the

Resource Tree
Several icons in the Resource Tree reflect the sensors deployed in your network. This
section describes the relationship between the sensor and the icons that visually
reflect the sensor’s configuration.

As described in the section IntruShield resources on page 50, multiple nodes reflect
aspects of a sensor: Sensors, Sensor_Name, Failover Pairs, Interface, and Sub-Interface.

Sensors icon
This node represents the available IntruShield sensor(s).

52
McAfee® IntruShield® IPS System 3.1 Working with IntruShield Resources 6
Getting Started Guide Relationship between sensors and resources in the Resource Tree

The Sensors node is a logical parent: all of the actions (configuring non-standard ports,
updating all sensors at once) configured at this level logically apply to every sensor
managed by this node, including any sensors configured to act as a Failover Pair.
Sensors nodes are admin-domain specific, that is, configured Sensors rules only apply to
the sensors of a single admin domain.

Sensor_Name icons
The Sensor_Name icons represent the sensors you add to the system. These sensors are
labeled with the names you specify when you create them.

Sensors have multiple ports, or interfaces. These interfaces can be allocated to multiple
admin domains in the system, meaning that while the sensor may have been added to
one admin domain, the allocated interface is controlled within the domain to which it
was allocated.

A single sensor can thus appear by name in several places in the Resource Tree;
however, its icon varies depending in which domain the sensor was added.

Physical Sensors
The Physical Sensor icon represents the sensor itself in the admin domain to which it was
added. For example, if SensorA was added to Admin Domain A, then SensorA appears in
the Resource Tree represented with a physical sensor icon under the Admin Domain A
node.

Virtual Sensors
The Virtual Sensors icon represents a parent domain sensor that has had one or more
interfaces allocated to the child domain under whose node it appears. For example, if
SensorA was added to Admin Domain A, but has allocated two interfaces to Admin Domain
B, then SensorA appears in the Resource Tree represented with a virtual sensor icon
under the Admin Domain B node. A Virtual Sensors node is not selectable. You can
configure the real sensor from its Physical Sensor node.

Failover Pair_Name
The Failover Pair_Name icon appears under the Sensors icon and represents two physical
sensors you configured to behave as one Failover Pair. A Failover Pair is labeled with the
name you specify when you create it; for example, FailoverPair1. A Failover Pair consists
of two identical sensors (same model, same software, same configuration) running
entirely in In-line Mode.

Below the failover pair will display the interfaces configured for the sensor pair. For
I-4000 sensors, this will be interface pair 1A and 1B. For I-2600 sensors, this can be 1A
and B, 2A and B, and/or 3A and B. Interfaces are described below.

Member Sensors
The Member Sensors icon appears under the Failover Pair_Name icon, and lists the sensors
comprising the Failover Pair. The Member Sensors node is not selectable; configuration
is performed at the Failover Pair_Name node.

53
McAfee® IntruShield® IPS System 3.1 Working with IntruShield Resources 6
Getting Started Guide Relationship between sensors and resources in the Resource Tree

Failover Sensor
Once you designate a sensor to be part of a Failover Pair, its icon changes to show it is
a Failover Sensor. A Failover Sensor is represented by the name you gave the sensor
when you created it.

Interfaces
Expanding the view of a sensor displays the ports/interfaces available. An Interface is a
representation of a single physical port on the sensor (i.e., 1A), a port pair (i.e., 1A and
1B), or—for asymmetrically routed traffic—logically grouped ports (i.e., 1A & 1B and 2A
& 2B, or 1A and 2A).

Sensor interfaces are represented in the Resource Tree by their port number, and can
be named by the user in VLAN or CIDR scenarios; however, the port number still
appears.

Sub-interfaces
If an interface is connected to a segment that is transmitting VLAN or CIDR traffic, the
interface can be segmented into several smaller groupings called sub-interfaces. One
would normally configure a sub-interface to apply a different policy than what is applied
at the interface level, or to group various unique traffic instances with others that have
common characteristics (namely VLAN or CIDR traffic). You could also create a
sub-interface to protect a specific host that is the target of a DoS/DDoS attack. The
sub-interfaces are listed under the interface they constitute.

Thus interface 1A could, for example, be subdivided into 5 sub-interfaces.

Sub-interfaces are represented in the Resource Tree by their user-specified names or
numbers.

Figure 6-2 Resource Tree with sensor-related resources displayed

Sensor_Name node (physical sensor)

Interface node

Sub-interface node

Sensor_Name node (virtual sensor)

Sensor_Name node (virtual sensor)

Figure 6-3 illustrates how this organization relates to an I-2600 sensor named 2600A.

54
McAfee® IntruShield® IPS System 3.1 Working with IntruShield Resources 6
Getting Started Guide Relationship between sensors and resources in the Resource Tree

Figure 6-3 Relationship between a sensor and the resources

displayed in the Resource Tree

Figure 6-4 illustrates failover pair nodes in the System Configuration tool’s Resource
Tree.

Figure 6-4 Resource Tree with failover pair-related resources displayed

Failover Pair_Name node

Member Sensors node

Failover Sensor node
Failover Sensor node

55
7 Administrative Domains
Admin domains, and how they are represented in the
Manager interface

This chapter explains the concept of administrative domains and how domains are
represented in the IntruShield Manager. For specific instructions on how to configure
admin domains, see the Administrator’s Guide.

What is an administrative domain?

An administrative domain, or admin domain for short, is an organizational tool used
specifically to group IntruShield resources so that management of the resources can
be delegated to specific IntruShield users.

An admin domain can contain other admin domains, sensors, sensor interfaces, and
sensor sub-interfaces. This administrative domain concept enables enterprises to
create a central authority that is responsible for the overall IntruShield IPS, and to allow
this central authority to delegate day-to-day operations of IntruShield security resources
to appropriate entities—business units, geographic regions, IT departments, individual
security personnel, and so on.

Root Admin Domain

The top level admin domain is called the Root Admin Domain. (The icon used to depict
it in the Resource Tree is shown at left.) Users with Super User access to the Root
Admin Domain have complete control over the entire administrative domain and all
resources within it, including any child domains, and thus all security resources in the
system.

For example, suppose your company (which we’ll call My Company) is headquartered
in London, and has satellite offices in New York, Paris, and San Francisco. If your
IntruShield deployment monitors the entire company, your Root Admin Domain could
encompass all four sites and all of the IntruShield system components within the
environment, and you could manage the entire system from London.

Figure 7-1 shows this arrangement in the Resource Tree in the System Configuration
tool of the Manager. The root admin domain is labelled “My Company.”

56
McAfee® IntruShield® IPS System 3.1 Administrative Domains 7
Getting Started Guide Admin domain hierarchy

Figure 7-1 The Root Administrative Domain for My Company

Parent and child admin domains

Perhaps managing “My Company’s” entire IntruShield deployment from London is
impractical. It might make more sense to delegate management of the IntruShield
resources protecting various geographical locations to entities in those locations. To
delegate management functions to each of the four offices, you would create a
subdomain representing each office. These subdomains are called child admin domains
or child domains.

Creating child domains enables you to delegate entities more familiar with the
subdomain’s environment to monitor and/or configure the IPS devices in that
subdomain. You are not required to subdivide your admin domains into child domains;
however, if you want to delegate responsibilities for managing IntruShield resources
among multiple individuals within your organization, you do so by creating child
domains.

To delegate responsibilities, you create user accounts and give each user a role that
defines how the user can interact with the resources in the child admin domain. For
Note
more information on roles, see Managing Users in IntruShield on page 79

You can further break child domains into smaller subdomains. Any domain with child
domains is a parent. A child domain can be parent to other child domains.

You can subdivide your Root Admin Domain into child domains that are large, from a
resource perspective, delegating management of all the IntruShield resources
protecting multiple geographic regions. Or you can create domains that are very
small—a few interfaces on a single sensor, or even a VLAN tag or CIDR address within
a segment of traffic transmitting between two hosts in the protected network.

Admin domain hierarchy

Administrative domains are graphically represented in the Resource Tree as a
hierarchical tree structure. Resources in the IntruShield system are represented as
nodes on the Resource Tree, as illustrated in Figure 7-2.

57
McAfee® IntruShield® IPS System 3.1 Administrative Domains 7
Getting Started Guide Admin domain hierarchy

Figure 7-2 Resource Tree Elements

Root Admin Domain, parent

domain of HR, Engineering and

child domain of My Company

nodes child domain of My Company

child domain of My Company, parent

domain of Payroll and AccountsPayable

child domain of Finance

child domain of Finance

In Figure 7-2, the node at the top of the tree represents the Root Admin Domain.

The structure of the Resource Tree applies to the way the nodes are managed by
system users and not necessarily to any networking or physical relationship between
Note
the resources.

A user’s role determines his/her view of the Resource Tree. Only resources the user is
permitted to view are displayed in the tree. If, using the example in Figure 7-2, a user
is a Super User of the Finance admin domain, the Resource Tree shows the Finance
domain at the top of the tree and all of its children; it does not display any other child
domains, nor the Root Admin Domain.

Nodes
Each item in the Resource Tree is a node and represents an IntruShield resource. A
node can represent a logical entity, like a child domain, or a physical entity, like an
interface on a sensor. A single Admin Domain node can be a parent or child. It can be
a parent to nodes under it, while being a child to a node above it. There might be several
levels of child nodes.

Inheritance
It is important to understand the relationship between parent and child admin domains
because (by default) child admin domains inherit policies from parent admin domains,
and because users are automatically granted the same privileges in the child domains
as those enabled by their roles in the parent domain.

Policy inheritance means that a child takes policies, or inherits them, from the parent.
If you do not specify a policy when you create the child, the child automatically inherits
the policies of its parent. To override policy inheritance from parent, you assign a policy
to the child admin domain that is specific to that child domain.

58
McAfee® IntruShield® IPS System 3.1 Administrative Domains 7
Getting Started Guide Alert and fault notification and forwarding

For more information on policies, see Working with Security Policies on page 60.

User roles work similarly, but with a slight difference. Roles apply within the current
domain and any of its children. Because child domains are essentially contained within
parent domains, if a user is given, for example, a Super User role for a parent domain,
that role also applies to all children of the parent. Thus, to use the domain hierarchy
shown in Figure 7-2 on page 58 as an example, a user assigned a System Administrator
role for the Finance department has that role for the Payroll and Accounts Payable
domains as well.

Note that additional roles can be granted to the user at the child level, but a role granted
at a parent cannot be overridden at a child level.

For more information on roles, see Managing Users in IntruShield on page 79.

Alert and fault notification and forwarding

From the Admin Domain resource you can configure notification and forwarding of
alerts and system faults. Notification enables the IntruShield Management System to
send an email, page an individual, or execute a script upon detection of alert or fault
settings you have configured. Alert and fault forwarding enables you to configure the
Manager to send alert and/or fault data to a specified syslog and/or SNMP server.

59
8 Working with Security Policies
Developing and applying IPS policies for IntruShield

What are security policies?

A security policy, or IDS policy, is a set of rules that governs what traffic is permitted
across your network, and how to respond to misuse of the network. An effective policy
is one that is customized to the network environment being monitored.

Security policies can set rules for protocols (HTTP, UDP), operating systems (NT,
Solaris), and other types of information transmitted across your network. Knowing what
types of traffic cross your different segments will help you determine the types of
policies you will require to efficiently and successfully protect your network against
intrusions and misuse.

IntruShield policies
An IntruShield policy is a set of rules/instructions defining the malicious activity you
want your sensor(s) to detect and how you want to respond if the activity is detected.
Creating a policy enables you to define a set of rules that define the different services,
protocols, and/or product implementations in your network.

The best practice for protecting against misuse is not to apply a one-size-fits-all policy
to the entire network, but to create multiple specific policies which focus on the
specific needs of unique segments of your network. IntruShield enables you to create
policies for your network resources right down to individual sub-flows of network
traffic.

Imagine a network that has Windows and Linux hosts interspersed across it. The best
approach here is to apply a policy that includes attacks for both Windows and Linux on
all ports through which their traffic will flow.

If this network happens to be controlled in such a way that the traffic from all Windows
hosts is flowing through one segment of the network and the traffic from all Linux hosts
is flowing through a different segment, you could connect these different segments to
different monitoring ports. You could then apply Windows-specific and Linux-specific
policies to the respective ports. In doing so, you would minimize the chance of false
positives and reduce the quantity of scanning required on each port.

60
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Policy application

Policy application
Current sensor-based IDS products permit you to apply only one security policy for the
entire sensor. Typically these one-policy sensors also have only one port which cannot
be segmented for more granular policy application. However, if you have multiple
segments to monitor or you need to monitor aggregated traffic—like on Gigabit
uplinks—a multi-port box and more granularity in the inspection process makes for a
much more cost effective and efficient security solution. IntruShield sensor appliances
have multiple ports coupled with multiple policy application options. Thus, IntruShield
offers its Virtualization feature (known as VIDS or VIPS).

VIPS—applying policies at the Interface and Sub-interface level

The VIPS feature enables you to configure multiple policies for multiple unique
environments and traffic directions all monitored with a single IntruShield sensor. The
goal of virtualization is scanning granularity. Virtualization allows you to apply multiple
policies to traffic flowing through a single interface. In this way, a unique scanning policy
can be applied to a single host or group of hosts, when their traffic will not travel
through a unique sensor port.

For example, suppose port 1A of an I-2600 sensor is connected to the SPAN port on a
switch. Port 1A is configured with a specific environment detection policy. The rest of
the ports on the sensor can have policies completely different than the policy on 1A, or
they can use the same policy. Or, each port can be segmented by multiple VLAN tags
or CIDR addresses, each customized with its own security policy.

Sensors
Policy can be applied at the sensor level; however, this policy application is intended to
be inherited by those interfaces of a sensor whose custom-applied policy has been
deleted. For example, you have created a custom policy called Custom1. You apply it to
interfaces 1B, 2A, and 4B on a single I-2600 sensor. After some time, you determine
Custom1 does not work effectively, and you want to delete it. You can apply a different
policy to the sensor that will allow you to delete the custom policy without having to
change the policy at each interface where it has been applied. When you delete the
custom policy, all of the interfaces (1B, 2A, and 4B) enforcing the policy will inherit the
policy applied to the sensor.

Interfaces
Networking professionals often interchange the terms port and interface. In the
IntruShield context, however, there is an important distinction to be made; a port
actually represents the physical component, whereas an interface represents the
logical abstraction of one or more physical monitoring ports on a sensor and all traffic
flowing through the port(s). All sensor interfaces are represented by FE or GE
monitoring ports connected directly or through an external tap, hub, or SPAN port to
network segments.

A simple, yet effective example of the difference between port and interface is with
regard to a “port pair.” When you configure a sensor to run inline, you combine and
manage the two physical ports as a single logical interface.

61
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Policy application

To use an example, suppose you have a Finance parent domain, and it has two child
domains—Payroll and Accounts Payable. Now suppose that the Payroll department
network is comprised entirely of Windows machines, and Accounts Payable is
predominantly Solaris. You have a single I-2600 sensor that is running in internal tap
mode with two peer ports, port pair 1A and 1B, monitoring traffic in the Payroll
department and port pair 2A and 2B monitoring Accounts Payable. You can use the
supplied Windows Server policy and apply it to the Payroll interface and the Solaris
Server policy to apply to the Accounts Payable interface.

Figure 8-1 Deploying security policies

Sub-interfaces
The terms VIDS and VIPS reinforce the idea that virtualization allows you to tailor a
single sensor solution as if it were a multiple-sensor solution. The IntruShield user
interface uses the term sub-interface, and this term better describes the process by
which virtualization is implemented.

IntruShield sensors take port monitoring deeper than the interface-level: you can
segment the security management of an interface and apply policies at a traffic
sub-flow level within the interface. A sub-flow, or sub-interface, is a segment of data
within a traffic flow. This sub-interface is also a VIPS. A VIPS can be defined based one
or more blocks of CIDR-based IP addresses or one or more VLAN tags. IntruShield
sensors can process these data segments and apply multiple traffic policies for the
multiple subnets transmitting across a single wire, right down to policies protecting
individual hosts.

62
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Policy application

Figure 8-2 Policies on sub-interfaces

In Figure 8-2 on page 63, a gigabit uplink between a router and a switch is monitored
in external tap mode by an I-4000. Behind the switch is a corporate network with five
departments: HR, Sales, Payroll, Engineering, and Marketing. The traffic for each of
these departments has been segmented using VLANs with each department’s traffic
tagged with a distinct VLAN ID, represented by the numbers 1-5 in the illustration.

Using peer ports 1A and 1B to tap the full-duplex uplink, the I-4000 can analyze and
process the VLAN IDs in the traffic transmitted between the router and switch. The
security administrator can configure unique policies for each VLAN ID (representing
traffic from the different departments) within the uplink, rather than apply a single policy
across the entire interface. In this scenario, each of the five VLAN IDs from each of the
five departments can have a distinct policy assigned to it, or different combinations of
the VLAN IDs within the uplink can have the same policy applied. Policy application
simply depends on assigning a policy to an interface or sub-interface resource as you
see fit.

DoS policies
It is also worth noting that each interface and sub-interface maintains a unique
Denial-of-Service (DoS) profile. DoS policies can be applied to subsets of a
sub-interface for even more granular security monitoring. These DoS profile instances
are known as DoS IDs. You can monitor DoS attacks to the granularity of individual
hosts. Any deviation from the established normal traffic behavior flags a DoS condition,
even a situation wherein a single host/subnet downstream to a gigabit network link
comes under attack—with even a couple of Mbps of traffic. The sensor’s granular DoS
detection can spot the attack.

Another reason to consider creating a sub-interface for a single host is when that host
tends to have traffic patterns that are significantly different from the rest of the hosts
sharing the interface. An example is an e-commerce Web server as compared to
internal file and print servers; the Web server will no doubt have a different traffic
pattern than the file and print servers. If not isolated from the file and print servers, that
one Web server is potentially skewing the calculations for the entire interface and
therefore creating false positives, or even false negatives, in the DoS analysis process.
By isolating that one host, you allow the sensor to analyze the traffic destined to and
originating from the file and print servers independently of the traffic to and from the
Web server, and therefore increase the likelihood the analysis will be accurate.

63
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Pre-configured policies

Pre-configured policies
McAfee supplies a set of pre-configured policies for immediate application in a number
of different network environments. These policies are available in the Policy Editor, which
is located under the Policies node in the Resource Tree of the System Configuration tool.

These policies are “starting points,” designed to help you get your system up and
running quickly. You can use any of the default scenarios initially, or you can clone and
modify these and apply your new policies. In fact, the Default Inline IPS policy, applied by
default when you add your first sensor, enables you to begin monitoring your network
immediately, and actually begin blocking attacks right out of the box (if you deployed
your sensor in in-line mode). As you tune your IPS, you will modify these policies to best
suit your particular environment.

Each pre-configured policy is designed to address the most common attacks targeting
specific network environments. To provide the most efficient attack detection options,
these policies take into account distinct factors such as protocols (HTTP, SMTP),
services (email, FTP, Web), and implementations (Apache, IIS).

Attacks are classified into four general categories:

„ Denial of Service (DoS) and Distributed Denial of Service (DDoS): all of the
conditions indicative of activities that lead to service disruption, including the
slowing down or crashing of applications, servers, or networks.

„ Exploit: all malicious activities, other than DoS and Reconnaissance, carried out
through specific traffic content. This includes buffer overflows, viruses, and worms.

„ Reconnaissance: all of the conditions indicative of probing, scanning, and OS

fingerprinting activities. These activities are generally in preparation for more
targeted attacks.

„ Policy Violation: all activities for which the underlying traffic content may not be
malicious by itself, but are explicitly forbidden by the usage policies of the
administrative domain. This includes application protocol behaviors that violate
common usage practices.

The pre-formatted policies and their descriptions are listed below.

All provided policies, except for the two All-Inclusive policies, enable attacks with a
minimum Severity of 2 (Low) and a maximum Benign Trigger Probability of 3
Note
(Medium). The Severity and Benign Trigger Probability settings exclude known noisy
signatures in an effort to limit spurious alerts.

Policy Designed to Protect Against

Default Inline IPS All attacks of Low severity or greater, below a Medium benign trigger probability,
with a blocking sensor action enabled for all McAfee Recommended for Blocking
(RFB) attacks.
Default IDS All attacks of Low severity or greater, below a Medium benign trigger probability.
Outside Firewall All attacks except for Reconnaissance category.
DMZ All attack types except for those Exploits using TFTP, Telnet, RIP, NETBIOS, NFS,
and WINS.
Inside Firewall All attack types except for those Exploits using TFTP, Telnet, and RIP.
Internal Segment All attacks except for Exploits using RIP and routing protocol attacks.

64
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Pre-configured policies

Policy Designed to Protect Against

Web Server All Reconnaissance and DoS attacks, generic backdoors, and Exploits using DNS,
HTTP, and FTP protocols.
Mail Server All Reconnaissance and DoS attacks, generic backdoors, and Exploits using DNS,
SMTP, POP3, and IMAP protocols.
DNS Server All Reconnaissance and DoS attacks, generic backdoors, and Exploits using the
DNS protocol.
File Server All Reconnaissance and DoS attacks, generic backdoors, and Exploits using DNS,
NFS/RPC, and NETBIOS/SMB protocols.
Windows Server All attacks where the impacted OS includes Windows.
Solaris Server All attacks where the impacted OS includes Solaris.
UNIX Server All attacks where the impacted OS includes UNIX.
Linux Server All attacks where the impacted OS includes Linux.
Windows and UNIX Server All attacks where the impacted OS includes Windows or UNIX.
Windows and Solaris Server All attacks where the impacted OS includes Windows or Solaris.
Windows, Linux, and Solaris All attacks where the impacted OS includes Windows, Linux, or Solaris.
Server
All-Inclusive without Audit All attacks, including those with known noisy signatures, but omitting
Informational severity attacks. This policy differs from Default as it alerts for every
attack in the IntruShield database, including those with noisy signatures. This
enables expert security personnel to fully analyze their network traffic.
Informational “attacks” are not enabled.
All-Inclusive with Audit Similar to above, with the exception that Informational-level alerts are included.
Null All signatures are disabled by default.This policy is provided for the scenario
where a substream of traffic needs to be ignored by the IPS.

For example, in Figure 8-3 on page 65, an IntruShield 2600 sensor protects three
network areas: outside the firewall, inside the firewall, and the DMZ. You can enforce
a single policy across all three areas, or you can configure individual policies specifically
for each zone.

In this example, the area outside the firewall is best protected by the default Outside
Firewall policy (or one similar to it created by an admin) provided with IntruShield. For
the DMZ area, the provided DMZ policy is the most efficient for that segment. Similarly,
for the area inside the firewall, the provided Inside Firewall policy is best suited for the
traffic in that zone.

Figure 8-3 Deploying security policies

65
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Configuring policies in IntruShield

Configuring policies in IntruShield

You configure policies using the Policy Editor in the System Configuration tool, apply
them to a resource (e.g., an admin domain, an interface, or a sub-interface) and these
policies are then propagated to sensors for enforcement. Although policies are
inherently complex, the Policy Editor facilitates the configuration process with
straightforward, step-by-step configuration screens.

About rule-based policies

IntruShield policies are rule-based. A rule-based policy consists of an ordered list of
attack selection rules, and is somewhat similar to an Access Control List (ACL). A set
of ordered rules are used to determine what attacks or conditions are of interest, and
thus should be monitored. 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. By this process of broadening (includes) and narrowing
(excludes), you can enable detection of just the attacks that impact the intended
environment.

For example, if you view the Default IDS policy rule set, the rule set includes all DoS and
Reconnaissance attacks, includes all Exploit attacks above a level 2 (low) severity, below
a level 3 (medium) benign trigger probability, thus excluding a specific list of attacks that
are not critical enough or contain signatures that are inherently noisy.

Attacks vs. signatures in IntruShield

Note that as you interact with IntruShield policies, you encounter the term attack, not
signature. IntruShield 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. Combined in an attack, the signatures provide for maximum
accuracy and coverage in attack detection.

The IntruShield Policy Editor

The Policy Editor is a tool that enables you to view, create, edit, clone, and delete
security policies. The tool appears in the Resource Tree as the Policies node (shown at
left). You can use IntruShield’s pre-configured policies as is, or use them as a template
for creating custom policies, or you can create new policies.

The following options are available to you in the Policy Editor:

„ Add/create your own policy.

„ Edit a policy you created. (You cannot directly edit provided policies.)

„ Clone an existing policy; that is, copy and customize any existing policy—including
provided policies—under a new name.

66
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Configuring policies in IntruShield

„ Delete any policy you created. (You cannot delete provided policies. You cannot
delete a policy that is currently applied to a resource.)

Creating or customizing a policy

The following steps describe policy creation at a high level.

1 Create a named policy. You can clone (copy) a default policy to use as a template,
edit an existing policy, or create a new one. Your policy should specify all the attacks
you want to detect and the responses to take when a particular attack is detected.

2 Save the policy.

3 Apply the policy to a resource—an admin domain, sensor, an interface on a sensor,

or a sub-interface of a sensor interface. (A newly added sensor will inherit the policy
from its admin domain; thus, all interfaces on the sensor will be protected by the
policy of the domain by default.)

4 If an intrusion event is detected, the sensor sends an alert to the Manager

describing the event, and issues a response if you have configured it to do so. Types
of responses are described in the section Response types on page 70. Examine the
alerts in the Alert Viewer, or in an IDS Report.

5 Over time, you can tune the policy based on the alert data generated. If you see a
lot of alerts that you don’t want to see (i.e., alerts that don’t apply to your
environment, such as Windows attacks against a Solaris environment or other
instances of alerts on events that you do not consider noteworthy), then you might
want to tune your policy rules to see only impacting attacks.

Sensor response without alerting

By default, all of the attacks detected by a policy send an alert upon detection. In cases
were you see the same alert time and time again in your Alert Viewer and wish you
could automatically send a response without having to see the alert again, IntruShield
provides the sensor response without alert feature. For Exploit attacks, you can
disable alerting for any attack while still being able to activate a sensor response upon
detection of the attack. When the attack is detected, the configured response is
executed and no alert is sent to the database.

If you disable alerting for an attack, packet logging is also turned off for that attack. You
must enable the alert to enable packet logging.
Note

Automatic acknowledgement of alerts

Dependent upon the number of attacks a day you experience, you may notice that
several of the same attacks consistently target your network. With your Alert Viewer
open to a Real-time View, you are constantly acknowledging instances of the same
alert over and over, which can take productive time away from analyzing the other
alerts.

IntruShield policy customization enables the automatic acknowledgement of alerts for

any attack in the database. The Notification option Auto. Acknowledge automatically marks
the attack as “Acknowledged” in the database, thus detection of the attack is not
counted in the Unacknowledged Alert Summary (of the Network Console), and can only be
viewed in the Alert Viewer via Historical View queries.

67
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Exporting and importing policies

Reassigning policies across sensors

You can easily easily reassign policies applied to sensors within the current admin
domain or any child admin domains this action without having to search extensively
throughout IntruShield. If you need to reassign a policy on several sensors, you can
search by policy. If instead you want to reassign policies on selected sensors, you can
search by sensor.

For more information, see Chapter 7 of the Administrator’s Guide.

Exporting and importing policies

The ISM system enables you to export and import your custom policies. Exporting
allows you to save a copy of a custom policy from the Manager to your client or other
location. Importing allows you to copy an exported policy back to the Manager.

Exported policies are saved as XML files. Do not attempt to customize the XML
output, or you may have problems when importing the policy back to the system.
Caution

The following three scenarios detail situations where exporting and/or importing policy
is beneficial to your security strategy:

„ Scenario 1: Creating and archiving a policy

You created a custom policy, and you want to back up that single policy for later
reference, editing, or availability. You export the file to your client. You can import
to a test environment to edit the policy, then import back to your live system. Also,
you can import the original policy back to the Manager overwriting the current
record of the policy in the event you aren’t satisfied with changes made to the policy
since a previous export.

„ Scenario 2: Utilize a test environment to create a policy, then import

If you have set up a Manager server in a “test” or non-live environment, you can
create multiple policies on your test Manager for use in your live system. Once
policy creation is complete, export the custom policy to a client machine. Then
connect remotely to your live Manager, and import the custom policy. Once
imported, you can apply the policy to IntruShield resources.

„ Scenario 3: Copying a policy from one live manager to another live manager

If you have a large number of IntruShield sensors deployed, you may decide to split
the sensors between two or more Managers. For the custom policies you create,
you can export the policies from one Manager to a client, then import the policies
to the other Manager(s).

68
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Policy inheritance

Policy inheritance
A policy defined at the admin domain level is inherited by its child admin domains, and
the resources—sensor interfaces and sub-interfaces—within the child domains unless
the policy is explicitly set during resource configuration. If you want to set another
policy for a specific resource, you can select or create a different policy.

The policy inheritance order is shown below.

Type of Policy
Resource/Node Exploit Policy DoS DoS Reconnaissance
Learning Mode Threshold Mode
Policies node „ Define policy „ Define policy „ (Is turned off by „ n/a
default)
Any Admin „ Assign policy „ Assign policy „ (Is turned off by „ n/a
Domain nodes defined at Policies defined at Policies default)
node node
Sensor_Name „ Same policy as „ Same policy as „ Same policy as „ Define/Enforce
nodes that of the Admin that of the Admin that of the Recon. policy (defined
Domain Domain Admin Domain for all the sensor’s
interfaces)
Interface nodes „ Inherit policy from „ Inherit from policy „ Define policy „ n/a
Admin Domain Admin Domain „ Enforce policy
„ Assign new policy „ Modify inherited
„ Enforce policy policy
„ Enforce policy
Sub-interface „ Inherit policy from „ Inherit policy from „ Define policy „ n/a
nodes Interface Interface
„ Enforce policy
„ Assign new policy „ Modify inherited
policy
„ Enforce policy
„ Enforce policy
Individual VLAN „ n/a „ Inherit from „ Define policy „ n/a
ID, CIDR bock Admin Domain
„ Enforce policy
within interface or
„ Modify inherited
sub-interface policy
„ Enforce policy

Suppose you create a policy for use with an admin domain you plan to create. You can
define the policy at the Policies level. It’s then available for any admin domain, and any
sensor in the domain.

When you allocate sensor interfaces to an admin domain (a process that is part of child
admin domain creation), all of the interfaces automatically inherit the admin domain’s
policy. So, as part of the process of creating an admin domain, you assign the policy to
be inherited by the allocated interfaces. If you want, you can then go into each allocated
interface and assign a different policy.

Changing policies at higher levels (e.g., admin domain level) once they have been
applied at a lower level has no effect on the lower levels (e.g., interface level).

A custom policy defined at a child admin domain level can’t be applied to a resource
at the parent admin domain level.
Note

69
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Response management

Response management
When an IntruShield sensor detects activity to be in violation of a configured 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 IntruShield can be customized protect any zone in a network,
knowing what needs to be protected can help to determine the response type. If
monitoring outside of the firewall in In-line Mode, preventing DoS attacks and attacks
against the firewall is crucial. Most other suspicious traffic intended for the internal
network, including scans and low-impact well-known exploits, are best logged and
analyzed as the impact is not immediate and 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 to not set the policies and responses so fine that they
disrupt the flow of traffic and slow down the system; rather, prevent the crippling traffic
from disrupting your network.

Response types
The response types offered by IntruShield sensors and the Manager are as follows:

Sensor response actions

IntruShield sensor actions are responses your sensor enacts or sends through the
network to prevent or deter further attacks.

„ Drop further packets (In-line mode only) — Dropping the specific attack packets is
a key advantage of in-line mode. When detecting in-line (real time), the packets that
trigger signatures and (optionally) all subsequent packets related to that connection
can be dropped before they reach the intended target system. This capability
provides true “intrusion prevention.” This action is also known as “blocking.”

„ Send an alert (default) — When traffic violates a sensor policy, an alert is generated
and sent to the Manager to be viewed using the Alert Viewer. Alerts can be
examined for content and sorted by key fields such as severity level, source and
destination IPs, and so forth. Refer to the Administrator’s Guide for more
information on the Alert Viewer.

„ Firewall action — sensor coordinates with a configured firewall, sending a deny

rule to the firewall for specific source and destination address parameters.

„ Packet log — Sends a log, or copy, of the packet information to the database; this
information acts as a record of the actual flow of traffic that triggered the attack and
can be used for detailed packet analysis. When the data is viewed in the Alert Viewer,
the data is converted to libpcap format for presentation. Tools like Ethereal can be
used to examine the packet log data for more detailed analysis of attack packet data.
The user can specify how many packets should be logged or for what duration. You
can also choose to encrypt the packet log channel via SSL to protect the packet log
data.

70
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Response management

„ TCP reset — For TCP connections only. TCP uses the RST (Reset) bit in the TCP
header to reset a TCP connection. Resets are sent in response to a connection that
carries traffic which violates the security policy of the domain. The user can
configure reset packets to be sent to the source and/or destination IP address.

„ Alert filters — Alert filtering enables you to filter out alerts based on the source or
the destination of the security event. For example, if you know that your IT
department executes vulnerability scans from a particular IP address, you can filter
events originating from that address. The Alert Filter Editor provides a convenient
interface for creating alert filters.

„ ICMP host unreachable — ICMP Host Unreachable packets can be sent in

response to the source of UDP or ICMP attacks.

Recommended For Blocking (RFB)

IntruShield attack definitions contain an attribute that indicates whether an attack is
considered “Recommended for Blocking (RFB)” by McAfee. A flag may be set in any
cloned policy to block on the RFB attacks within the policy.

Manager response actions

There are three notification responses that can be configured to alert users of malicious
activity: email, pager, or script notification. These responses are sent directly to admins
based on either a configured severity level—represented as Low, Medium, or High
severity—or based on the occurrence of a particular attack, regardless of the severity
level.

The Global Attack Response Editor (GARE)

The GARE is essentially a ‘shortcut’ to customizing a particular attack’s response across
all policies containing that attack. Responses configured at the GARE level are then
available for that attack at the rule set and policy level.

We’ve discussed policy inheritance and response actions. To fully understand GARE,
consider a concept that we will loosely call response inheritance.

A new signature set straight from the Update Server contains some default actions
associated with particular attacks. For example, certain attacks are configured to log
packets, and others are configured not to log packets.

When you open an attack in the GARE editor, GARE displays the default attack values
specified by the signature set. GARE thus “inherits” the response actions from the
signature set. Customizing these values in the GARE overrides the signature set’s
values. Regardless of what the signature set suggested as the attack’s response, the
attack now has a custom response as specified in GARE.

The GARE values are then available for customization at the Rule set level. For example,
at the Rule Set level, you inherit all the customizations from the GARE level, but can set
a response action of “blocking” for certain attacks. Now the attack can have the GARE
customization plus the Rule set customization.

Finally, you have the Policy level. All the customizations made at the Rule set level or at
the GARE level are inherited at the Policy level.

71
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Response management

As shown in the following figure, each level inherits response attribute values from
previous level. At each level you can either retain the inherited value for an attack or
customize it by explicitly setting or removing a value.

Figure 8-4 Response Action Hierarchy

T

A signature set contains attacks with

Signature set certain pre-defined values for
response.

Changes made in the GARE override

GARE
default signature set behavior.

The rule set editor inherits GARE

changes; changes made in the Rule
Rule set editor
set editor override GARE
customizations.

The Policy editor inherits all changes

Policy editor made at the GARE and rule set levels;
responses can be changed at the
policy level, as well.

The Policy Editor now displays labels showing at what level an attack was customized:

D – Default IntruShield-supplied

G – GARE – Global attack response editor

R – Rule Set Editor (only blocking action)

P – Policy Editor

For example, suppose you want to create 3 policies that detect the attack “FTP: Attack
Example,” which happens to be a Recommended For Blocking (RFB) attack.

Your requirements are as follows:

„ Policy1: block FTP: Attack Example and log packets

„ Policy2: do not block FTP: Attack Example; log packets.

„ Policy3: block FTP: Attack Example; do not log packets

„ For all three policies, you want to be notified by email if FTP: Attack Example is
discovered.

How to accomplish this?

1 At the GARE level for FTP: Attack Example, configure packet logging and email
notification.

72
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Denial of Service (DoS) modes

2 At the Rule Set level, enable blocking for RFB attacks.

3 At the Policy Editor level, create your three policies. When you choose FTP: Attack
Example for Policy2, disable blocking. For Policy3, disable packet logging.

GARE customization can be imported/exported using the Policy Import/Export

feature.
Note

Denial of Service (DoS) modes

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. IntruShield sensors support both learning- and
threshold-based capabilities for combatting DoS attacks. Since the sensors maintain full
TCP state, it is easy to differentiate the “bad” DoS packets from “good” traffic packets,
and drop the bad packets when running in In-line mode.

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 In-line or Tap mode. When using SPAN or Hub Mode, all traffic is considered
inbound unless distinguished by creation of CIDR blocks; traffic destined to a specified
CIDR block is considered inbound on a SPAN port. Typically inbound traffic is destined
to the protected network, such as an enterprise intranet.

Outbound traffic is that traffic sent a system in your intranet, and is on the port marked
“Inside” (that is, originating from inside the network) in In-line or Tap mode.

There are also Learning Mode attacks that do not have a directional association,
specifically ICMP ECHO Anomaly and TCP Control Anomaly. Due to the nature of these
attacks, the sensor is unable to determine whether the attack occurred inbound versus
outbound. Thus, these attacks are classified as bidirectional.

The ICMP Echo Anomaly and TCP Control Anomaly attacks cannot be blocked, even
when the sensor is in In-line Mode.
Note

When configuring with the Policy Editor, you can customize severities and enable an
admin notification for a number of statistical categories. Report generation and the
Alert Viewer can help to determine the types of statistical information that are affecting
your network’s performance.

Learning mode
In Learning Mode, the sensor monitors the network traffic and develops a “normal”
baseline profile, called a long-term profile, by collecting statistics on a number of traffic
measures over time. The initial learning time for the profile is typically two days. After
that time, the sensor constantly updates these profiles (typically you will have multiple
profiles being processed at a given time), which are kept on the internal sensor flash,
to keep an updated picture of the network. In real time, the sensor develops a
short-term profile, which is essentially a snapshot of the network traffic. The short-term
profile is compared to the long-term profile and an alert is raised if the short-term

73
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Countering SYN floods with SYN cookies

statistics indicates a traffic surge that deviates from the long-term behavior. The
learning and detection algorithms take into account regular traffic surges that are
caused by flash crowds or the like: normally there are no alerts for such surges. (Flash
crowds are surges in traffic due to benign conditions, such as everyone logging in at
9:00am on a Monday.)

Response sensitivity determines how much (volume and duration) a traffic surge is
considered abnormal and if an alert should be raised. Setting the response sensitivity
to “Low” tells the detection algorithm to be tolerant of traffic spikes (that is, because
the network has abundant bandwidth and/or the server has adequate capacity) before
raising alerts, while setting it to “High” makes the system more sensitive to any traffic
surge. The implications of setting a “High” sensitivity are ambiguous: High makes it
possible to detect even small-scale DDoS attacks while at the same time making the
system more prone to false positives—the opposite can be said for “Low” sensitivity.

DoS learning mode is configured during policy creation and is enforced at the interface
and sub-interface levels. Customizations to learning mode profiles can be performed at
these resource levels, and Learning Mode profiles can be reset (re-learned) or reloaded
at the sensor level. This is all performed using the System Configuration tool.

Sub-interfaces and individual CIDR hosts within a VLAN tag or CIDR block being hit with
a denial of service attack can be created and protected with specific learning mode
settings. This is useful in preventing a server in your DMZ or other location from being
shut down by a DoS attack. A separate profile is created for each resource.

Threshold mode
In Threshold Mode, the sensor monitors the network traffic for packet floods, such as
SYN attacks and too many IP fragments, transmitting through from a source to a
destination as detected within a sensor interface or sub-interface. When configuring
with the Policy Editor or customizing at the interface or sub-interface level, you must
specify the count and interval (rate in seconds) for the threshold attacks you want to
detect. The sensor sends an alert when the traffic exceeds the customized thresholds
for an enabled (sought after) attack. You can also enable a notification for an attack if it
warrants special attention.

You must configure the actual thresholds and intervals for each DoS Threshold Mode
attack you want to detect. Default thresholds are not provided since the packet rates
Note
in every network are different. Customization of DoS thresholds works best after
researching the current levels each DoS Threshold attack defends against in order to
determine exactly what counts and intervals best protect your network.

Countering SYN floods with SYN cookies

A SYN flood attack is a series of SYN packets from forged IP addresses targeted at a
specific server. When a server is attacked in this manner, the SYN queue in the server
fills and all new connection requests are dropped. The SYN cookie feature is a
mechanism to counter SYN flood attacks. This feature is an adjunct to the existing
statistical anomaly-based Denial of Service detection. In cases where a DoS attack is
already underway and there is no time for learning a long term profile, IntruShield
provides the ability for the sensor to proxy all inbound three-way handshakes.

74
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Access control lists

With SYN cookies, whenever a new connection request arrives at a server, the server
does not maintain any information about the connection request. Instead it sends back
a SYN+ACK with an ISN uniquely generated using the information present in the
incoming SYN packet and a secret key. If the connection request is from a legitimate
host, the server gets back an ACK from the host.

The sensor will support a configurable threshold for SYN arrival rate, above which the
sensor will begin using SYN cookies to avoid having to maintain state during the
three-way handshake. ISM provides an interface to the user to enable/disable the SYN
cookie feature. It also provides user the ability to configure the threshold values for the
SYN cookies.

For more information, see the Administrator’s Guide.

Access control lists

IntruShield enables the creation of an access control list (ACL) with ordered rules for
permitting and denying traffic from reaching a sensor’s inspection engine and
continuing on through the network. A sensor ACL is useful for maximizing a sensor’s
detection and prevention capabilities by preventing, that is dropping or rejecting,
specified traffic without requiring full inspection.

Most commonly deployed in firewalls, an ACL is a set of ordered rules that governs
what traffic is permitted to pass and what traffic is denied access beyond the device
where the ACL resides. In the case of IntruShield, a sensor ACL checks all traffic to
determine what traffic is allowed to pass to a sensor’s inspection engine and beyond,
and which should be denied, that is either dropped from the network or rejected (TCP
traffic only). Thus, an IntruShield ACL can preemptively drop any traffic by denying
access to the inspection engine and beyond.

IntruShield provides two permit options: “permit and inspect” and “permit and pass
without inspection.” Permit and inspect passes traffic to a sensor’s inspection engine
to check for violations of applied IDS policy. Permit and pass without inspection passes
the traffic back into the network without checking for IDS policy violations.

McAfee recommends permit and inspect rules for complete protection from
potentially harmful traffic.
Note

If you configure multiple ACL rules, note the order as ACLs are executed in top-down
sequence: the rule at the top of the list is checked first, followed in order by subsequent
rules down to the bottommost rule. IntruShield employs a first-match process; the first
ACL rule matched in sequence is enforced.

At the sensor level, you can create rules for the entire sensor as well as those for
specific ports/port pairs of the sensor. Rules created at the sensor level for a specific
port/port pair are inherited by the corresponding interface and, if applicable,
sub-interface(s). In the case of ACLs, an interface is a subset of the corresponding port
or port pair. That is, ACL rules configured for a port/port pair at the sensor level are
inherited by the corresponding interface as well as any sub-interfaces. However, ACL
rules created at the interface level are not inherited by corresponding sub-interfaces
due to the rule of separating interface traffic flows from sub-interface traffic flows
based on the following policy application rule:

75
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide IP spoofing detection

If you apply a policy to a sub-interface that is different than the inherited policy, the
policy enforced at the interface level protects all traffic not specific to the
sub-interface.

Thus, for ACL rules, the rule of inheritance requires you to create global rules at the
sensor or physical port/port pair level: interface rules only apply to interfaces, and
sub-interface rules only apply to sub-interfaces.

You cannot set explicit ACL permit rules for protocols that negotiate ports dynamically
with the exception of the following:

„ FTP

„ TFTP

„ RPC services

Multimedia protocols such as H.323 and services such as instant messaging and
peer-to-peer communication either negotiate the data channel separate from the
control channel or negotiate ports that do not follow a standard. However, you can
configure ACLs to explicitly deny these dynamic protocol instances by denying the fixed
control port.

For RPC services, you can configure explicit allow and deny rules for RPC as a whole,
but not its constituents, such as statd and mountd.
Note

Another option for denying protocols that use dynamic negotiation is to configure
policies to drop the attacks that are detected in such transmissions. IntruShield
Note
detects use of and attacks in such programs as Yahoo Messenger, KaZaA, IRC, and so
forth.

ACL logging
IntruShield provides an optional ACL log feature that will log packets that are dropped
or permitted based on your ACL rule(s). The sensor forwards ACL logs to the Manager,
where they are formatted and converted to Syslog messages and sent to the
configured Syslog server. You can then view the log from a 3rd-party Syslog application.

You can enable logging on a granular level. For example, you can enable logging for
particular rules, or particular Admin Domains. For more information on ACL logging, see
Chapter 5 of the Administrator’s Guide.

IP spoofing detection
IntruShield sensors can detect IP spoofing attacks; that is, attacks that originate from
sources external to your network, but which use your internal addresses as the
attacking source IP addresses. You can apply IP address spoofing detection to any
interfaces that have been previously segmented by CIDR-based addressing. Your
IntruShield sensor keeps a table with your protected CIDR-based addresses; thus,
when a sensor detects an attack that originated from outside your network but contains
an identified internal address, an alert is generated for that traffic.

76
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Decrypting SSL for IPS inspection

For enabling IP spoofing detection on a sensor, see Chapter 9 of the

Administrator’s Guide.

Decrypting SSL for IPS inspection

A disadvantage often cited for NIDS systems is the inability to analyze encrypted traffic.
Encrypted traffic prevents nearly all NIDS from inspecting the packets for attacks or
other unauthorized activity. IntruShield sensors, however, are equipped to decrypt
Secure Socket Layer (SSL) packets for inspection and response in cases of attack.

IntruShield SSL functionality allows a sensor to maintain a copy of a server's private

key, thereby allowing the sensor to properly determine the session key for SSL
sessions terminating on that server. From a client, you download your SSL keys through
the Manager interface to a sensor. The sensor keeps the server key in volatile memory
after receiving it from the Manager. The key is stored on the Manager, encrypted with
a key only the sensor knows. This prevents a single point of compromise.

When a sensor boots up, it requests all of the private keys that the Manager has for
that sensor.

The Manager provides a passthru interface for importing a set of public/private keys to
the sensor. The Manager stores an escrow of the imported keys for sensor recovery
purpose. However, the Manager does not interpret the escrowed keys, nor does it
attempt to recover the keys themselves in case a sensor has lost its key encryption key.
In order to protect the imported keys both in transit and in escrow, the Manager uses
the public key of the sensor’s public/private key pair. The Manager can also push down
new keys when they are imported.

IntruShield supports the PKCS12 format—file suffixes “.pkcs12”, “.p12”, or “.pfx”—with

an RSA private key no longer than 2048 bits. Up to 64 keys can be loaded into a sensor,
and the keys work across all of a sensor’s Virtual IPS (VIPS) instances. The private key
must be a part of the PKCS12 file.

SSL functionality is described in Chapter 9 of the Manager Administrator’s Guide.

Note that there is a performance impact when using the SSL detection feature.
Performance information per sensor can be found in the IntruShield Release Notes.
Note

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

77
McAfee® IntruShield® IPS System 3.1 Working with Security Policies 8
Getting Started Guide Vulnerability assessment

„ 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

„ DES_CBC3_SHA

„ TLS_NULL_WITH_NULL_NULL

„ TLS_RSA_WITH_NULL_MD5

„ TLS_RSA_WITH_NULL_SHA

„ TLS_RSA_WITH_RC4_128_MD5

„ TLS_RSA_WITH_RC4_128_SHA

„ TLS_RSA_WITH_DES_CBC_SHA

„ TLS_RSA_WITH_3DES_EDE_CBC_SHA

„ TLS_RSA_WITH_AES_128_CBC_SHA

„ TLS_RSA_WITH_AES_256_CBC_SHA

Unsupported SSL Functionality

The following SSL functionality is not supported:

„ iPlanet Web servers

„ Diffie-Hellman ciphers

„ Compression in the SSL records (a negotiable option in SSLv3 and TLS)

„ PCT (Microsoft's extension to SSLv2)

Vulnerability assessment
ISM now has the ability to load vulnerability data from the McAfee Foundstone product
and the Nessus opensource vulnerability scanner. The IntruShield Manager will
perform correlation based on common CVE and/or Bugtraq ID. IntruShield can then
display correlations with imported scan data in a separate column in the Alert Viewer
column entitled “Vulernability Relevance”.

If an IntruShield alert shares the same exploit/vulnerability combination as is found in

the Foundstone data, AND the target IP has also been cited by Foundstone as being
vulnerable, the alert will be tagged with a value of '1', indicating that it is relevant. This
information will help prioritize alert data.

You manage the vulnerability assessment feature from the System Configuration tool,
and the view the data from within the Alert Viewer.

For more information, see the Manager Administrator’s Guide.

78
9 Managing Users in IntruShield
Setting up users and roles

This chapter explains the user management capabilities of the IntruShield Manager. The
IntruShield Manager System Configuration tool enables users with Super User
privileges to delegate configuration and monitoring responsibilities of the various
components of the IntruShield system to specific users. This chapter describes user
management and roles at a high level, and describes the application of user roles in
developing a safe and efficient security management environment.

For specific instructions on how to create users and assign roles, see the Manager
Administrator’s Guide.

User management in IntruShield

Security organizations usually are comprised of multiple individuals, and management
of the overall system is generally delegated to different people according to some
logical categorization—by department, by geographic location, by system (i.e., the
email servers, the Web servers), and so on. In IntruShield, you delegate the
management of system components by organizing the components logically into
admin domains and then granting various management privileges for the domains to
your IntruShield users.

The IntruShield Manager enables the creation of multiple users within the system, and
enables Super Users to grant specific privilege rules, called roles, to those users to
allow them to manage an admin domain and any of its children. Within each admin
domain, permission to carry out tasks is limited to only those users with appropriate
roles.

For example, recall that a child admin domain can consist of something as granular as
an interface on a sensor. You use roles to specify who can do what with that interface
in that child domain.

What is a role?
A role is defined as a group of actions that a user is allowed to perform within a given
domain. Roles determine the user’s authorized activities, ensuring the users have
access to only the functions necessary to complete their particular operational
responsibilities.

79
McAfee® IntruShield® IPS System 3.1 Managing Users in IntruShield 9
Getting Started Guide Roles within IntruShield

IntruShield implements role-based authorization, wherein users can perform only those
activities permitted by their role. Roles are always domain based, that is, a role governs
what activities a user can perform within a particular domain. Users never have roles
that are not tied to managing a resource within a specific domain and its children,
although users can exist in the database without being assigned a role.

Roles promote the integrity of security configuration by not allowing universal access
to every security resource deployed in the system. Thus you can create a user with
privileges to manage and configure a single child domain, perform user management
tasks within that domain, generate reports, manage sensors, and so on. You can assign
the least privileges necessary for a user to perform his/her specific job function, and no
more. The user is limited to the specific role functions within the assigned child domain
and its children, and prevents the user from manipulating other domains.

For example, only the Root Admin Domain System Administrator sees the Manager
node in the Resource Tree. System Administrators without privileges at the Root Admin
Domain level are allowed to configure and maintain their child domains within the
system, but do not see the Manager resource.

The Root Admin Domain Super User is able to override the roles of any user.
Note

Creating a user
You create a user using the Manager’s System Configuration tool, and you can assign
the user roles for a particular domain at the time the user is created, or you can assign
roles at a later time. Only users who have Super User privileges can assign or modify
the assignment of user roles, and then only for the domains permitted by their role(s).

Users are stored in the database with their username, an MD5 hash of their password,
their role(s), and their roles in various domains. When the user logs in, the Manager
makes available only those activities permitted by the user’s role.

As most companies now centralize their user management and authentication, the
Manager also supports RADIUS and LDAP (Active Directory) authentication for users.
For either authentication method, you configure the authentication server information,
and then when creating a user, you can choose whether the user is a RADIUS, LDAP
or ISM Local user.

User accounts for the sensor can be centrally stored and authenticated with a
TACACS+ (Terminal Access Controller Access Control System plus) server.

Roles within IntruShield

IntruShield provides five categories of roles. The section Role descriptions on page 81
below, lists the five role types with the applicable description and activities available to
each.

All role types can view the Network Console, and all role types have read-only access to
most actions available in the System Configuration tool. Restricted Users and No Role
users—as their names imply—have the most limited read-only privileges within the
system.

80
McAfee® IntruShield® IPS System 3.1 Managing Users in IntruShield 9
Getting Started Guide Roles within IntruShield

In addtion to IntruShield-provided roles, custom roles can added in order to assign

specific abilities to certain members of an organization.

Role relationships between parent and child domains

Roles apply within the current domain and any of its children. Because child domains
are essentially contained within parent domains, if a user is given, for example,
Operator role for a parent domain, that role also applies to all children of the parent.
Note that additional roles can be granted to the user at the child level, but a role granted
at a parent cannot be overridden at a child level. Using the example above of a user
granted an Operator role at the Root Admin Domain level, suppose you create a child
admin domain. The user with the Operator role inherits that role at the child level;
however, if you wanted the user to have Super User status at the child level, you can
assign the Super User role within that child domain.

IntruShield roles provide a granular level of access within the system. This enables you
to provide very limited responsibilities to a number of individuals, or to assign a single
user multiple roles so the user can accomplish multiple administrative tasks (e.g., grant
System Administrator and Security Expert roles) within the system.

Role descriptions
The following section summarizes the IntruShield-provided user roles.

Super User role

The Super User role (not represented by an icon) enjoys all privileges. Each shipped
IntruShield Manager is configured with one built-in Super User account including a
default password.

The default Super User account username is admin and password is admin123.
McAfee strongly recommends that you change the default password for security
Warning
purposes. (In the System Configuration tool, while logged in as admin, go to Root
Admin Domain > Users > Manage My Account and change the password.

The Super User role provides:

„ all the privileges possible in the current domain

„ all the privileges a Super User has in all the children of the current domain

„ the special privilege to assign (or remove) the Super User role for a user in the
current domain

A Super User can be defined at any level, and the role applies to the current domain
and all of its children, but not for its parent domain or any other “sibling” domains.

System Administrator role

The System Administrator role pertains strictly to administration of the system itself.
Tasks permitted to the System Administrator include managing software and system
performance; creating users and granting roles; adding, deleting, or configuring
sensors; and handling system faults.

81
McAfee® IntruShield® IPS System 3.1 Managing Users in IntruShield 9
Getting Started Guide Roles within IntruShield

Operator role
The Operator is can run and analyze reports, and monitor alerts via the Alert Viewer.
The Operator cannot acknowledge or delete alerts, nor initiate responses.

Security Expert role

The Security Expert role largely pertains to managing intrusion policies. The Security
Expert can create, edit, and delete policies, view alerts, manage software and signature
update downloads, generate reports, manage system faults, and handle security alerts.

Restricted User role

Restricted Users (not represented by an icon) can view the Network Console, and are
limited to read-only access to most areas of the System Configuration tool.

No role
The No Role user cannot perform any actions. This is the state when a user is first
created.

82
10 Working with Alerts
Alerts, and the tools available for analyzing them

What are alerts?

Alerts are asynchronous notifications sent when a system event or attack triggers the
IPS. When a packet violating your enforced security policies is detected by a sensor, the
sensor compiles information about the offending packet and sends the information to
the Manager in the form of an alert. An alert contains a variety of information on the
incident that triggered it—such as the type of attack, its source and destination IP
addresses, its source and destination ports, as well as security analysis information
(performed by the sensor) such as attack severity and type. You can use this information
to perform forensic analysis on the alert—that is, careful investigation to determine its
cause and how to prevent others of its kind.

An attack is a violation of set policy parameters. An alert is one or more attack

instances. In many cases, an alert represents a single detected attack. A multi-attack
alert is generated when multiple instances of identical attacks (same source IP,
destination IP, and specific attack) are detected within a two minute period; data for all
attacks is throttled into one alert instance, however, you can also choose to configure
for how many of each throttled attacks you want to see an individual alert.

IntruShield stores alerts in the Manager server database until you delete them. You can
view your alerts in the Manager using the Alert Viewer or the Report Generator. You can also
correlate of large number of identical alerts into a small number of incidents using the
Incident Generator.

The lifecycle of an alert

Alerts exist in one of three states: unacknowledged/acknowledged, and marked for
deletion. When an alert is raised, it appears in the Manager in an unacknowledged
state. Unacknowledged means that you have not officially recognized its presence by
marking it acknowledged. An alert remains in an unacknowledged state until you either
acknowledge or delete it. Alerts are backed up to the database and archived in order of
occurrence. Deleted alerts are removed from the database.

Unacknowledged alerts display in the Unacknowledged Alert Summary section of the

Network Console and the Real-time view in the Alert Viewer. Acknowledging alerts
dismisses them from these views. Acknowledged alerts display only in the Historical
view in the Alert Viewer and in reports.

83
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide What are alerts?

Figure 10-1 Unacknowledged Alert Summary Display on the Network Console

Deleting an alert both acknowledges it and marks it for deletion. The alert is not actually
deleted until a scheduled File Maintenance takes place. At that time, IntruShield
deletes those alerts marked for deletion and those alerts meeting the deletion criteria
specified in the scheduler—older than 30 days, for example—whether or not they’ve
been manually marked for deletion.

For more information on File Maintenance, see the Administrator’s Guide.

Note

To put an acknowledged alert back into an unacknowledged state or un-delete an alert,

you can use the Historical view in Alert Viewer to show all alerts from the time period
in which the acknowledged/deleted alert took place. You can then locate the alert and
unacknowledge or un-delete it. This alert will not display in the Real-time Alert Viewer
until you have closed and re-opened the Alert Viewer.

Suppressing alerts
Over the course of time, you will become very familiar with your IntruShield alert data
as you perform forensic analysis using the Alert Viewer. At some point, you may even
become tired of seeing some of the same alerts time and again. IntruShield provides
multiple options for suppressing alerts, that is, lessening the number of alerts in either
the Alert Viewer and/or database, so that you can work on your higher priority issues.

The following alert suppression options are available using various actions within the
Manager interface:

„ Disable alerting: During policy creation/modification, you can disable the alert for
one or more attacks. This is not attack detection disabling, just alert disabling.
The sensor still detects the attack and can send an automatic response—if
configured. (If no response is configured, then nothing is done when the attack is
detected.)

„ Auto Acknowledge: Also during policy creation, you have the option of
automatically acknowledging a detected attack. The Auto Acknowledge feature
suppresses the alert from the Real-time View of the Alert Viewer by marking the
alert as acknowledged, thus making the alert viewable only in an Historical View
query.

84
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide About the Alert Viewer

„ Alert throttling: Alert throttling (seen as Response Action Settings in the Manager
interface) enables you to set a suppression limit for a singular Exploit attack, which
originates from one source, targets a single destination IP, and is detected by the
same VIPS (interface or sub-interface) multiple times within a limited time frame.
Exploit throttling limits the number of duplicate alerts that are sent to the Manager
from a sensor. Throttling is very effective against repetitive Exploit attacks where a
source IP address is spoofed and generates a high number of alerts.

Send alert to Send sensor Display alert in Save alert to

Manager response action Real-time View database
Normal behavior Yes Yes Yes Yes
Detection on, No Yes No No
disable alerting
Auto Acknowledge Yes Yes No Yes
Alert throttling1 Yes Yes Yes Yes
1. Throttling bundles multiple identical alerts into one alert upon reaching a configured threshold. Thus, many alerts are
suppressed into one, as all details are identical.

About the Alert Viewer

The Alert Viewer is a powerful forensic analysis tool you can use to examine the alerts
detected by your IntruShield sensors.

The Alert Viewer opens in a separate browser window from that of the Network
Console, providing a concentrated view for alert analysis. When you open the Alert
Viewer, you specify a time frame and type of view—either Real-time or Historical. The
Manager retrieves the alerts that occurred in the specified time frame and displays
them in the Alert Viewer for your analysis. By examining the alerts, you can use the
information your analysis provides to determine your system weaknesses and modify
your defenses.

„ Real-time View. The Real-time View sets the alert filter to display data retrieved
from the alert cache for a configured number of unacknowledged alerts. Once
opened, the Real-time View refreshes frequently to display the alerts that are being
detected by your sensors, thus you can view the alerts as they happen in real time.

„ Historical View. The Historical View sets the filter to retrieve information for both
acknowledged and unacknowledged alerts archived in the database within a
specified time frame. The Historical View does not refresh with new alerts; thus you
can focus on analyzing all alerts within the time you requested.

85
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide About the Alert Viewer

Figure 10-2 Selecting Alerts to View

Once you’ve retrieved alerts either from a particular time period or in real time, the Alert
Viewer interface displays the alerts matching your criteria in three main
views/windows:

1 Time View: This window, at the top of the screen, displays the number of attacks
in time intervals that have been detected either in the last two hours (Real-Time) or
within a specific time frame (Historical). The Time View displays as a bar graph. Each
bar contains information related to the number of attacks and a time frame in which
the attacks were detected. Clicking on a bar displays information on the attacks it
represents in the status bar at the bottom of the Time View window.

Figure 10-3 The Alert Viewer Interface

a b c

2 4
d e

86
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide About the Alert Viewer

2 Consolidated View: The Consolidated View window is below the Time View
window. Its display is split into five panes (categories) for statistical review. Each
pane is a bar graph, and each bar represents several alert (Alert Result Status and
Severity panes) or attack (“Top 10” panes) instances grouped by a specific
parameter. An alert/attack may appear in a bar in more than one pane if that
alert/attack has met the statistical parameters of multiple categories. The categories
are described as follows:

a Alert Result Status: shows the probable result of all attacks corresponding to
the alerts: successful, unknown, failed, suspicious, blocked, or ‘blocking
activated.’

“Blocking activated” applies to DoS traffic and indicates that the sensor has
discovered traffic suspicious in nature and blocking has started, though not all traffic
Note
may be blocked. This is by design; blocking is taking place on packets that are
perceived as bad by the sensor. The sensor works to allow legitimate traffic to flow,
while blocking the traffic that is exceeding its learned threshold or is not recognized
based on its DoS profile. The sensor makes this determination on a packet-by-packet
basis. See the IntruShield Special Topics document on Denial of Service for more
information.

b Severity: lists alerts as High, Medium, Low, or Informational.

c Top 10 Signature Alerts: lists the top detected 10 attacks by count.

d Top 10 Source IP Addresses: lists the 10 most common source IP addresses by

number of detected attacks.

e Top 10 Destination IP Addresses: lists the 10 most-targeted destination IP

addresses by number of detected attacks.

3 Attack Details View: This pane, which is at the bottom of the window, displays all
of the attacks, sorted by order of occurrence, for the selected time span. Attack
details are presented in multiple named columns, known as attributes. The
attributes represent packet fields such as source and destination IP, as well as
sensor analysis fields such as attack severity, attack direction, and attack type.

4 All Alerts View: The All Alerts View, located slightly behind the Consolidated View,
displays all of the various attacks that have been reported with a count by each to
display how many times each attack has been reported (i.e., alerted) within the
parameters of the current query. For example, if there are two reported alerts and
two reported attacks for the “ICMP_ECHO Anomaly” attack, the table displays an
Alert Count of 2 and an Attack Count of2. Thus, the “ICMP_ECHO Anomaly” attack
was detected and reported exactly twice during the queried period. However, if
multiple attacks have been suppressed into a single alert, the Alert Count and Attack
Count display differing values. For example, if “ICMP_ECHO Anomaly” attack was
reported 50 times in a two-minute period, the first five attacks would be sent as
single alerts, while the 45 remaining attack instances would be throttled into one
alert. Thus, in the All Alerts View, the Alert Count would be 6 (5 individual, 1
throttled) and the Attack Count would be 50. If working in a Real-Time View, values
in this view continue to calculate.

87
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide About the Alert Viewer

Drilling down—sorting alerts by categories

The Drilldown option offers several categorical views for all or selected alerts. Drilling
down enables you to focus your view of particular alerts; for example, you might see
from looking in the Consolidated View pane that most High Severity attacks are issuing
from a particular Source IP address, and perhaps you want to see which attacks are
being sent. You can select that source IP, then drill down to see the attacks and
destinations have been issued from the address.

Figure 10-4 Drilling Down Through Alert Categories

For Real-time Views, the drill-down dialog has a Freeze button, enabling you to freeze
the view so you can focus on analyzing current alerts without being interrupted by a
refresh. The Refresh button manually refreshes the view to display the latest alerts.
During a freeze, you can continue to drill down into alert data.

Show the details of a specific alert

You can view the details of a specific alert for a clearer picture of the key information
related to the attack. Different types of attacks produce different alert details. For
example, a Port Scan attack’s alert details show the Source and Destination IP
information, as well as the destination ports scanned in the attack.

The information you learn in the Alert Details can then be used to augment your policy
settings and/or to initiate a response action, such as a TCP Reset. By right-clicking an
alert, you can perform certain actions on the alert, such as viewing or editing a
response, running a script, saving an evidence report, and so on.

88
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide About the Incident Generator

About the Incident Generator

IntruShield provides real-time alert correlation with the Incident Generator and
User-Generated Incident tools. Performing analysis can be quite a task when it means
looking through thousands, tens of thousands, and even hundreds of thousands of
alerts to determine what is happening to your network. IntruShield’s alert suppression
feature helps reduce the number of alerts to wade through, but having an intelligent
resource to correlate and group related alerts—in real-time—greatly facilitates the task.

For example, suppose an attacker, looking for weaknesses, initiates a port scan against
your network. If the attacker successfully locates a vulnerability on a particular machine,
he or she may next perform an exploit against the vulnerability. If the exploit is
successful, the attacker might then compromise the machine and use it as a tool for
initiating other attacks. This one server’s compromise, occurring amidst all the other
alerts indicating other attacks on your network, could go unnoticed for too long because
of the sheer number of alerts to examine.

Imagine, however, if you could see instead that a single incident had occurred—that a
particular server had received too many alerts in a short period of time, that alerts
related to its compromise were being seen, and that attacks were now being initiated
from that server.

Utilizing the Incident Generator

The Incident Generator tool enables you to define how to group a large number of
related alerts into a small number of incidents. An incident is a pre-configured number
of related alerts with commonalities matching a particular scenario.

Using the Incident Generator, you define a scenario, which by default is “more than 100
alerts in fifteen minutes from one source.” A scenario is a sequence of conditions, that,
when met, cause IntruShield to raise an incident. If a situation matching the scenario is
detected followed by a period of inactivity equal to or greater than two minutes,
IntruShield raises multiple occurrences of the incident. For example, the system
detects 100 alerts from the same source in a 10 minute period. There is no activity for
three (3) minutes from the source, but then attacks start again from the noted source
that surpass the 100 alerts threshold in under 15 minutes. Instead of seeing 200+
related alerts from the same source as two incidents, you instead see two occurrences
of a single incident matching the defined scenario.

Configuring Incident Generator scenarios

The Incident Generator tool, which is defined by the configuration of an XML file, runs
on a separate host than the Manager server. Configuring Incident Generator involves
specifying scenarios and customizing parameters in the XML file.

For more information on starting the Incident Generator, see Chapter 6 of the
Administrator’s Guide.
Note

89
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide About the Report Generator

Creating user-generated incidents

The IntruShield Management System also enables you to create your own incidents as
you perform forensic analysis in the Alert Viewer. The User-Generated Incidents option
provides you the ability to select individual alerts from an Attack Details View for
inclusion in a custom incident. No scenario settings need to be met; rather, you select
each alert to include in your incident. Since this feature is independent from the Incident
Generator configuration scenario, you can create an incident with alerts from multiple
source IPs, to multiple destinations, and so forth. There is no minimum number of
alerts to meet, thus you can start an incident with just one alert, and more alerts, as
well as custom occurrences, over time. Once satisfied with an incident, you export it
to the Incident Viewer for further analysis.

For more information on working with the User-Generated Incidents tool, see Chapter
10 of the Administrator’s Guide.
Note

Viewing an incident
Whether you started the IG service or created your own incidents via the
User-Generated Incidents tool, you view the incidents in the Incident Viewer tool,
which is located within the Alert Viewer. Within this tool, you can analyze and manage
incidents, including alert analysis, user assignment, and workflow commentary for
maintaining an incident’s status.

For more information on working with the Incident Viewer, see Chapter 10 of the
Administrator’s Guide.
Note

About the Report Generator

The Report Generator tool enables you to produce a range of reports for both the alert
information reported to your Manager, as well as information pertaining to your
IntruShield configuration settings.

„ IDS reports are summaries of alert information, such as severity, impact category,
source/destination IP, time of alert, alert trends, and so forth.

„ Configuration reports detail information such as the current Manager and sensor
software versions, proxy server settings, policy configuration, and so forth.

„ Scheduled reports generate IDS reports at a configured time, and optionally email
the reports to specific individuals and/or save them for later viewing.

For more information on the Report Generator, see the Administrator’s Guide.
Note

90
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide Alert and packet log archival

IDS reports
The Report Generator’s IDS reports detail the network alerts generated by your
IntruShield sensors. Alert reports are summaries based on specific types of information
such as the source/destination IP of an attack, attack name, or time of alert. IntruShield
includes several pre-formatted reports for simple information gathering, including an
Executive Summary report, which provides a high-level view of alert activity.

These IDS reports provide information on the alerts generated from your installed
sensors. The generated alert information can include source and destination IP of the
attack, time when attack occurred, the sensor that detected the attack, and so forth.
The multiple reports in this category provide various, concentrated views according to
the specific parameters of each report. Each report lists alerts from most to least
common detected.

All IDS reports can be viewed in either HTML or PDF format. The Top N Report can also
be viewed in bar graph or pie chart format.

Configuration reports
Configuration reports provide information on the settings configured using the System
Configuration tool. You can generate reports to view your current software and
signature versions, the status of a sensor, policy and rule set configurations, or your
proxy server settings. These reports provide a snapshot of the system’s current
configuration.

Scheduled reports
Scheduled reports automate IDS report generation for convenient forensic analysis of
the alerts generated by your IntruShield sensors. You can schedule reports to be
generated and emailed on a daily or weekly basis. You create a report template
consisting of the information you wish to be included, save the template, and configure
the scheduler to run either weekly (on a particular day) or daily (at a particular time each
day). You can also specify recipients for the reports. When the scheduled time arrives,
a report is generated based on the template and mailed to specified individuals. Each
report is saved for later review.

Alert and packet log archival

You can copy alerts and packet logs from the database and archive them for later
retrieval and analysis without impacting the performance of your database. Using the
Archival actions provided in the Manager interface, you can archive your alerts and
packet logs on-demand or by a schedule, then restore the archivals on a different
Manager-database instance for further historical analysis.

The archival process copies alerts and packet logs from the database into a zip file on
the source Manager. From the Manager interface, You provide a time range within
which all corresponding alerts and packet logs in the database are copied into the
archival file.

Archived files are saved locally to the Manager, but can be exported to your client.
Note

91
McAfee® IntruShield® IPS System 3.1 Working with Alerts 10
Getting Started Guide Alert and packet log archival

The scheduled archival process is an incremental process. The process preserves the
last archival time and uses it as the start date for the next (current) archival. The end
date is always the current time. You can clear the preserved start date or set it to any
date in the past. If it is cleared, the first process cycle archives all alerts and packet logs
up to the current time, then the incremental process executes.

An archival cannot be executed when database tuning is in process.

Note

The restoration process requires the archival file to be copied over to a directory on the
target Manager or a network directory which the target Manager can access. The
restoration process enables you to filter through the alerts in the archival by severity of
alert, the result status, and start and end times.

To configure the archival process, refer to Chapter 6 of the Administrator’s Guide.

92
SECTION 4

Deployment for Beginner,

Intermediate, and Advanced
Users

Chapter 11, Deployment for Beginner, Intermediate, and Advanced Users

11 Deployment for Beginner,
Intermediate, and Advanced Users

This chapter provides some guidance on how to deploy IntruShield using the most
simple, or out-of-the-box method, and then gear up to more complex scenarios.

Deployment flexibility
IPS deployment can be daunting, and a complex product can be difficult to integrate
initially. IntruShield, while complex, provides great flexibility in deployment so you can
start monitoring your network even while you familiarize yourself with its features and
capabilities and tune your security policies.

IntruShield deployment can be simple or complex, depending on your needs and your
skill with the product. If you’re a Beginner, you can use IntruShield straight out of the
box and get your entire deployment up and monitoring in an extremely short period of
time. An Intermediate approach might be to customize your policies a bit and shift to
another operating mode, such as Tap mode. An Advanced user might use all of the
features available, tracking traffic at extremely granular levels, creating multiple
administrative domains managed by a variety of users with various privileges, tailored
policies and custom responses to detected attacks, and so on.

Deployment scenario for beginners

IntruShield includes a variety of pre-configured security policies targeting different
environments. These policies (defined in Working with IntruShield Resources on
page 50) enable you to start monitoring your network right away. Details on how to
accomplish these tasks, unless otherwise specified, are described in the
Administrator’s Guide.

1 Install the Manager as described in the Manager Installation Guide.

2 The Default Inline IPS policy is specified by default. You can leave this policy in
place or pick the policy that best matches your needs. Sensors you add will inherit
this policy and pass it along to all interfaces of the sensor.

This policy enables blocking for certain attacks; immediately upon in-line deployment
sensors will begin blocking these attacks when they are detected.
Note

94
McAfee® IntruShield® IPS System 3.1 Deployment for Beginner, Intermediate, and Advanced Users 11
Getting Started Guide Deployment scenario for intermediate users

3 Configure the sensor and add it to the Manager as described in the Sensor
Configuration Guide.

4 On the Manager, check the sensor’s port configuration to be sure that it matches the
way you have deployed the sensor. Make changes as necessary.

5 Download and apply the latest sensor software and signature file from the Update
Server.

6 Send all configuration changes to the sensor.

7 If you want, set up alert notification to email or pager by attack severity.

8 Using the Report Generator and the Alert Viewer, examine the resulting alerts for
patterns, to help you tune your policies.

9 Back up your data.

Deployment scenario for intermediate users

The pre-configured policies have an umbrella effect—you’re protected from all attacks
defined in the policy. This enables you to get up and running quickly, but it also may
protect you against attacks you do not care about. For example, if you have an entirely
Solaris environment, you may not care if someone is initiating IIS attacks against the
network, because these attacks are irrelevant to you. Some administrators prefer to see
all network activity, including unsuccessful attacks, to get a complete picture of what
is occurring on the network. Others want to reduce the “noise” generated by irrelevant
attacks. Tuning your policies to delete attacks that do not apply to your environment
reduces the amount of unimportant alerts generated by your sensors.

To tune your deployment, you might do the following:

„ Try a more advanced deployment mode. If you were running in SPAN mode, you
may choose to try another deployment mode, such as tap mode.

„ Take advantage of the sensor’s ability to apply multiple policies to multiple

interfaces. Instead of applying a single policy to the entire sensor, you may try
applying different policies to dedicated interfaces of the sensor. You can go a step
further and segment your traffic into VLAN tags or CIDR blocks, create
sub-interfaces, and apply policies to the sensor’s sub-interfaces.

„ Tune your policies. Pick the policy that best matches your needs and clone the
policy (or create a policy from scratch). Then remove any irrelevant attacks, add any
additional attacks, and configure appropriate response actions to respond to
detected attacks.

„ Generate reports and view alerts. Look at the data generated by the system to
help you further tune your policies, and if necessary, implement more granular
monitoring or delegation of monitoring activities to others.

95
McAfee® IntruShield® IPS System 3.1 Deployment for Beginner, Intermediate, and Advanced Users 11
Getting Started Guide Deployment scenario for advanced users

Deployment scenario for advanced users

An advanced deployment of IntruShield utilizes more of IntruShield’s features to best
tune your system. Once you are more familiar with IntruShield, you might do the
following:

„ Try running in in-line mode. In-line mode enables you to drop malicious traffic and
thus prevent attacks from ever reaching their targets.

„ Split your deployment into multiple Admin Domains. You may want to organize
your deployment by geographical location, business unit, or functional area (i.e., HR,
Finance).

„ Segment your network traffic into VLAN tags and CIDR blocks. You can then
monitor various traffic with distinct policies using the sub-interfaces feature.

„ Create (or clone) policies on a sub-interface basis. Create policies tuned for
specific traffic flows within a network segment, and apply them on an extremely
granular level.

„ Define user roles. Delegate the day-to-day management of the IPS to specific
individuals, providing each person with only enough access to the system to carry
out his/her responsibilities.

„ Define DoS policies. Configure DoS policies for specific hosts or a subset of your
network.

96
Glossary

Access Control List

A list kept by routers to control access to or from the router for a number of services (for example, to prevent
packets with a certain IP address from leaving a particular interface on the router).

Admin Domain
Administrative domain. An organizational tool used specifically to group IntruShield resources so that
management of the resources can be delegated to specific IntruShield users.

Alert
An alert is a notification of a system event, attack, or other incident that triggers the Intrusion Detection
System.

Alert Filter
An alert filter limits the alerts generated for an exploit attack by excluding certain Source and Destination IP
address parameters. If these address parameters are detected in a packet, the packet is allowed to finish
transmission. IntruShield enables you to configure multiple alert filters to filter the alerts from multiple
discontiguous networks for a single exploit attack.

Alert Viewer
A graphical user interface for viewing specific attack information in the IntruShield System. The Alert Viewer
interface is part of the IntruShield Manager, and focuses on alert forensic analysis.

Allocate
Allocation refers to the allotting of resources from a parent admin domain to a child admin domain.

Anomaly Detection
Anomaly detection looks for behavior that deviates from normal system use.

Asymmetric Traffic Flow

A network set up for asymmetrically routed traffic does not send and receive along the same route. Rather,
the routing protocols have been set up to dynamically find the best (least amount of hops) available path from
point A to point B, and vice versa.

Attack
A set of actions performed by an attacker that poses a threat to the security state of a protected entity in
terms of confidentiality, integrity, authenticity, availability, authorization, and access policies.

97
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Attacker
Also hacker, cracker, intruder, misuser. Generic terms for people who try to get into your network. Outside
attackers attack from outside your network in an attempt to attack your external presence (deface Web
servers, forward spam through e-mail servers, etc.), or attempt to go around the firewall to attack machines
on the internal network. Outside attackers may come from the Internet, dial-up lines, physical break-ins, or
from partner (vendor, customer, reseller, etc.) networks linked to your corporate network.
Inside attackers (usually the most common type of attacker) are users that have legitimate reasons to
use/access your internal network, but who misuse privileges or impersonate higher privileged users, and
attack from within the network.

Audit
Any networking event deemed to be of interest to a security analyst. Examples include invocation of
particular applications or use of particular commands in certain applications.

Audit Log
Files containing details of amendments to the system by an individual. It provides a trace of user actions so
that events can be related to the actions of a specific individual, and is a basis of accountability within a
secure system.

Back Door
A program that hides itself from the authorized users/administrators of the system and provides access to a
third party without authorized personnel knowledge.

Brute Force
Brute force attacks are used by programs, such as password crackers, to try many different passwords in
order to guess the proper one.

Buffer Overflow
An attempt to exploit software vulnerabilities where manipulation of buffer spaces can result in overwriting
of unintended memory areas. Such overwriting can have different consequences depending on if the areas
are executable or not. If not, it can cause malfunction of the software, thus denial of service; if yes, it can
lead to execution of arbitrary machine code within the context of the current process which can lead to much
more severe security breach.

Child Admin Domain

A subset or subdomain of the root or a parent admin domain that has been delegated to a user/group for
management.

CIDR
Classless Inter-Domain Routing. A scheme which allocates blocks of Internet addresses in a way that
allows summarization into a smaller number of routing table entries. A CIDR address contains the standard
32-bit IP address but includes information on how many bits are used for the network prefix. For example,
in the CIDR address 123.231.121.04/22, the “/22” indicates the first 25 bits are used to identify the unique
network leaving the remaining bits to identify the specific host. Also, see CIDR Block.

CIDR Block
A CIDR block is a block of Internet addresses assigned to an Internet Service Provider (ISP) by the InterNIC.
See CIDR.

Command Shell
Traffic activities indicating interactive shells under Unix or Windows operating systems, etc.

Countermeasure
An action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by eliminating or
preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action
can be taken.

98
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Covert Channel
Any communication activities that are deemed unintended by the communication channel being monitored.

DDoS
See Distributed Denial of Service.

DDoS Agent Activity

Known DDoS attack tools use various patterns of communication amongst attackers or handlers, and
attacking agents or zombies. Detection of these activities is a good sign that either someone is attempting
to contact DDoS agents, or there may be real attackers or agent processes in the monitored networks.

Dedicated Interface
A dedicated interface monitors all transmissions without regard to network segmentation, i.e. segmentation
by VLANs or CIDR.

Demilitarized Zone
DMZ. In networking, the area between the inside/private and outside/public networks.

Denial of Service
In a Denial of Service (DoS) attack, the attacker attempts to crash a service (or the machine), overload
network links, overload the CPU, or fill up the disk. The attacker does not always try to gain information, but
to simply act as a vandal to prevent you from making use of your machine. Ping floods and Smurf attacks are
examples of DoS attacks.

Design Flaw
A flaw in the design of a system or network which can lead to unintended consequences such as access
without authentication or authorization.

Distributed Denial Of Service

Distributed Denial of Service (DDoS) attacks usually consist of standard DoS attacks orchestrated by
attackers covertly controlling many, sometimes hundreds, of different machines.

DoS
See Denial of Service.

Drilldown
Descending through numerous layers of consolidations, summaries, etc., to reach the really detailed
information at the bottom.

Exploit
This category covers the majority of attack activities that actively seek to compromise systems, gain
unauthorized access to confidential information or services, or tamper normal system operations by
exploiting known or potential system vulnerabilities.

Evasion Attempt
This kind of alert indicates a sequence of packets or bytes in the traffic signifying a specific attempt at evading
an IPS. For example, FTP attacks are known to use escape control character sequences to hide attack payload
and TCP-based RPC attacks may use record format to split up attack payload.

Fail-closed
Operating mode where network traffic is disrupted during system failure; the connection is broken/left open.

99
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Fail-open
Operating mode where network traffic continues to pass through during system failure. The connection
remains closed, or unbroken.

Failover
Automatic switching to a redundant or standby server, system, or network upon the failure or abnormal
termination of the currently-active server, system, or network. Failover happens without human intervention.
This feature is usually built-in to systems which must be available continuously.

False Negative
Misuse that is not detected or alarmed.

False Positive
An alarm that is not misuse.

Fast Ethernet
Fast Ethernet’s (FE) data rate is 100-Mbps Ethernet specifications, which offers a speed increase 10 times
that of the 10BaseT Ethernet specification while preserving such qualities as frame format, Ethernet Media
Access Control (MAC) mechanisms, and MTU.

Fingerprinting
Well-defined sequence of packets, each of which is typically a probe attempt itself, launched against a given
destination IP address, typically aiming at identifying the target OS or host type.

Firewall
A system or combination of systems that enforces a boundary between two or more networks.

Flooding Program
Code which when executed will bombard the selected system with requests in an effort to slow down or
shut down the system.

Full-duplex
A duplex communications channel which carries data in both directions at once. On analog networks or in
digital networks using carriers, full-duplex is achieved by dividing the bandwidth of the line into two
frequencies, one for sending, and the other for receiving.

Gateway
A bridge between two networks.

Gigabit Ethernet
Gigabit Ethernet’s (GE) data rate is 1000-Mbps Ethernet specifications, which offers a speed increase 10
times that of the 10BaseT Ethernet specification while preserving such qualities as frame format, MAC
mechanisms, and MTU.

Granularity
The relative fineness by which a mechanism can be adjusted.

Hack
To attempt (or to succeed) to get into a computer or network.

Hacker
A malicious meddler who tries to discover sensitive information by poking around.

100
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Half-duplex
A communication channel using a single circuit which can carry data in either direction but not both directions
at once.

Host Sweep
Well-defined sequence of packets sweeping through a range of destination IP addresses, typically aiming at
identifying live hosts.
See Reconnaissance.

Impact
When a system vulnerability has been discovered, an attacker can threaten the system with an attack that
impacts the system.

Implementation Flaw
Mostly in the form of a coding error or mistake, this is the most common cause for software vulnerabilities.
For example, most buffer overflow vulnerabilities are caused by a software failure to properly check the
boundary/length of a client request and/or allocate enough memory space (buffer) for it.

In-line Mode
Placing an sensor physically in the path of a network segment for the monitoring of network traffic.

Insider Attack
An attack originating from inside a protected network.

Interface
An interface is a representation of a single physical port on the sensor (i.e., port 1A) or a port pair (i.e., ports
1A and 1B).
An interface also has a logical connotation in that it allows the user to describe how they wish to segment
the traffic flowing through it. A logical interface allows the user to configure it to be dedicated (unspecified,
undefined traffic), VLAN (traffic marked with specific VLAN tags), or CIDR (traffic within a block of specific IP
addresses). You can also logically group interfaces into an interface group to monitor an asymmetric traffic
flow.

Interface Group
An interface group enables multiple sensor ports to be grouped together for the effective monitoring of
asymmetric environments. 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 Resource Tree as a single interface node (icon) under the sensor where it is located. All of the ports that
make up the interface are configured as one logical entity, keeping the configuration consistent.

Intrusion
Unauthorized access to, and/or activity in, an information system. Usually for the purpose of tampering with
or disrupting normal services. See also Attack.

Intrusion Detection
The process of identifying that an intrusion has been attempted, is occurring, or has occurred.

IP Spoofing
An attack whereby a system attempts to illicitly impersonate another system by using its network address.

LDAP
Lightweight Directory Access Protocol. A typical LDAP server is a simple network-accessible database
where an organization stores information about its authorized users and what privileges each user has.

101
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Learning Mode
In Learning Mode, the sensor monitors the network traffic and develops a “normal” baseline profile, called
a long-term profile, by collecting statistics on a number of traffic measures over time. The initial learning time
for the profile is typically two days. After that time, the system constantly updates this profile, which is kept
on the internal sensor flash, to keep an updated picture of the network. In real time, the sensor develops a
short-term profile, which is like an instant snapshot of the network traffic. The short-term profile is compared
to the long-term profile and an alert is raised if the short-term statistics indicates a traffic surge that deviates
too much from the long-term behavior. The learning and detection algorithms take into account regular traffic
surges that are caused by flash crowds or alike, so normally there is no alert for such traffic surges. (Flash
crowds are surges in traffic due to benign conditions, such as everyone logging in at 9:00am on a Monday.)
See Anomaly Detection.

MAC Address
A unique number assigned to every piece of Ethernet hardware that is used by a router in order to direct your
traffic to its intended destination.
The MAC address is 6-bytes long, and must be unique. To guarantee uniqueness, equipment vendors are
assigned a unique 3-byte prefix, and they then assign their own 3-byte suffix. Thus, the first 3-bytes of a MAC
address identifies what kind of hardware you have (3Com, Cisco, Intel, etc.).

MD5 Hash
The message digest function defined in RFC 1321. MD5 is a public one-way hash function that is intended
for digital signature applications, where a large file must be “compressed” in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem.

MTU
Maximum Transmission Unit. Maximum packet size, in bytes, that a particular interface can handle

Network Segment
Network segments are the physical wires (either Fast Ethernet or Gigabit Ethernet) used to link network
devices, facilitating the transmission of traffic across a system.

Non-standard Port
Any traffic activities suggesting that a standard protocol running over non-standard ports according to
specifications. For example, HTTP by default uses Port 80 or 8080, a sensor reading a packet with Port 80 or
8080 attempts to decode that traffic as HTTP traffic. However, if a user is running HTTP on Port 4568, it is
recommended that the user add Port 4568 to the non-standard port parameter for HTTP traffic. Also known
as a rogue port.

Notification
The method by which users are contacted when the system triggers an alert requiring attention. Users can
be alerted by email, text pager, or through script execution when an alert is raised that matches a selected
severity or a specific attack.

Over Threshold
Any of the well-defined traffic thresholds has been crossed. Examples include ICMP packet rate, IP fragment
rate, etc.

Parent Admin Domain

The entire network domain protected by an IntruShield Manager and sensor resources. Users with root
access can configure the parent admin domain; this access allows configuration of all security resources in
the system since all security resources report to the Manager, which is in the parent admin domain. Within
the parent admin domain, the management functions of the IntruShield Manager can be divided into
protected subdomains, called child admin domains. Also known as root domain, and called parent domain
for short.

102
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Policy
A user-configured security rule that determines the permission of traffic across a network. Policies can set
rules for protocols (HTTP, UDP), machines (NT, Solaris), operating systems (Unix), and other types of network
information. A policy also defines what actions should be taken in the event of non-permissible activity.

Policy Violations
All activities for which the underlying traffic content may not be malicious by itself, but are explicitly forbidden
by the usage policies of the network as defined by a security policy. These can include “protocol violations”
wherein packets do not conform to network protocol standards. (For example, they are incorrectly structured,
have an invalid combination of flags set, or contain incorrect values.) Examples might include TCP packets
with their SYN and RST flags enabled, or an IP packet whose specified length doesn’t match its actual length.
A protocol violation can be an indication of a possible attack, but can also be triggered by malfunctioning
software or hardware.

Port
A single interface on an internet working device, such as a router or IPS sensor.

Port Cluster
See Interface Group.

Port Mirroring
Refers to SPAN mode operation. SPAN mirrors the traffic at one switched segment onto a predefined SPAN
port. A network analyzer, such as a sensor, attached to the SPAN port can monitor traffic from any of the other
ports on the switch.

Port Scan
Well-defined sequence of packets sweeping through a range of destination ports on a given IP, typically
aiming at identifying open ports on the target host.
See Reconnaissance.

Privileged Access
Privileged access indicates the most serious type of successful exploitation, where unauthorized access to
privileged accounts has been obtained. For example, a successful buffer overflow on a Unix server may open
a root shell for the attacker. Alternatively, the attacker may have achieved successful privilege elevation from
a legitimate user account, or from a remote access compromise. Privileged access allows the attacker to
potentially take complete control of the compromised system.

Probe
Probes of specific service or host, typically based on specially constructed packets, e.g. unusual flag settings.

Protocol Violation
Unusual application protocol behaviors, including invalid field values or invalid command sequences, and so
forth.

RADIUS
Remote Authentication Dial In User Service. RADIUS is a server for remote user authentication and
accounting.

RDBMS
Relational database. Allows the definition of data structures, storage and retrieval operations, and integrity
constraints. The data and relations between them are kept in organized tables, which are collections of
records and each record in a table contains the same fields.

103
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Read Exposure
With a successful attack, this suggests that a breach of confidentiality has occurred. Examples include
directory traversal, dump of file content such as CGI script, or read of other sensitive data files such as
password and database records.

Recommended for Blocking (RFB)

An attribute in an IntruShield attack definition that indicates whether an attack is considered “Recommended
for Blocking (RFB)” by McAfee. McAfee considers certain attacks—such as worms—as dangerous or
destructive enough to recommend automatically for blocking.
A flag may be set in any cloned policy to block on the RFB attacks within the policy.

Reconnaissance
This type of activities is for the purpose of intelligence gathering to prepare for further attacks; for example,
a port scan or probe conducted to enumerate or identify services and possible vulnerabilities. These include
host sweeps, TCP or UDP port scans, host sweeps, e-mail recons, and possibly indexing of public Web
servers for the purpose of intelligence gathering—to find CGI holes or other system vulnerabilities that might
later be exploited.

Remote Access
Remote access indicates a potentially successful exploitation where unauthorized access has been obtained.
For example, a successful buffer overflow on a Windows server may open a Windows command shell for
the attacker. The remote access does not have to be for a privileged user to begin with, but an attacker may
be able to perform further attacks to achieve privilege elevation once remote access is obtained.

Resource
In IntruShield, a resource refers to any physical or logical element within the administrative domain, i.e.,
sensors, the Manager, interfaces and sub-interfaces, the parent admin domain, or child admin domains.

Restricted Access
Any activities related to using any network resources that are explicitly forbidden. For example emails to/from
particular addresses and browsing of specific URLs.

Restricted Application
Any activities related to running network applications that are forbidden by policy. Examples include running
an IRC or music share server on the corporate network without authorization.

Rogues
See Non-standard Ports.

Roles
A class of user privileges that determines the authorized activities of the various users in the system.

Root Admin Domain

The entire network domain protected by an IntruShield Manager and sensor resources. Users with Super
User access in the root admin domain can configure all of the security resources in the system since all
security resources report to the Manager, which is in the root admin domain. Within the root admin domain,
the management functions of the IntruShield Manager can be divided into protected subdomains, called child
admin domains.

Sensitive Content
Any content keyword matches that are deemed to indicate transmission of sensitive information, e.g.
document with “Company Confidential” marking.

104
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Sensor
The sensor is a network device containing the intrusion detection engine. It analyzes network traffic,
searching for signs of unauthorized activity.

Shellcode Execution
This kind of alert indicates the most severe form of buffer overflow attacks, i.e., a buffer overflow attack
carrying shellcode payload. Shellcode is a general term used for a piece of executable code that, upon
successful execution on the target system, will modify the target's configuration or behavior for malicious
purposes.

Signature
Activities or alterations to an information system indicating an attack or attempted attack, detectable by
examination of audit trail logs.

Signature Detection
The use of specific signatures that look for traffic from specific tools or particular exploits, and general
signatures that just look for anomalies in traffic.

SPAN Mode
One of the monitoring modes available for an IntruShield sensor. Functions by mirroring the packet
information on a switch or hub and sending the information to a sensor for inspection, while continuing the
transmission of traffic with negligible latency. SPAN mode is typically half-duplex, and works through a
connection of a sensor to a port on a hub or the SPAN port of a switch.

SPAN Port
Switched Port Analyzer. On a switch, SPAN mirrors the traffic at one switched segment onto a predefined
port, known as a SPAN port.

Statistical Attack
An attack that registers outside of the normal traffic baseline built by your Learning Mode profile. See
Anomaly Detection.

Statistical Deviation
Indicates that a significant change was detected in the packet rate for a particular traffic measure. For
example, if in your normal flow of traffic, TCP SYN packets make up between 23-28% of the traffic, then a
short-term measure of TCP SYN traffic at 40% may indicate a DoS attack.

Stealth Mode Interface

An interface having no IP address or TCP/IP stack to respond to IPS detection threats, rendering it completely
invisible to intruders.

Sub-interface
A segment of data within a traffic flow being monitored by a sensor interface. The segments of data
recognized by IntruShield sensors are VLAN tags and CIDR blocks. Also known as a sub-flow.

TACACS+
Short for Terminal Access Controller Access Control System. TACACS is an older authentication protocol
common to Unix networks that allows a remote access server to forward a user's logon password to an
authentication server to determine whether access can be allowed to a given system. A later version of
TACACS is XTACACS (Extended TACACS). TACACS+ is based on TACACS, but incorporates authentication
and authorization. TACACS+ makes use of the TCP/IP protocol.

Tap
A tap is hardware device that passes traffic unidirectionally from a network segment to the IPS. Traffic is
mirrored as it passes through the tap. This mirror image is sent to the IPS for inspection. This prevents traffic
passing from being directed at the IPS.

105
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Tap Mode
One of the monitoring modes available for an IntruShield sensor. Functions by mirroring the packet
information and sending the information to a sensor for inspection, while continuing the transmission of
traffic with negligible latency. Tap mode works through installation of an external wire tap, a port on a hub,
the SPAN port of a switch, or through an internal tap when deploying the I-600. Also known as passive
monitoring mode.

Threshold Mode
In Threshold Mode, the sensor monitors the network traffic for packet floods, such as SYN attacks and too
many IP fragments, transmitting through from a source to a destination as detected within a sensor interface
or sub-interface. When configuring with the Policy Editor or customizing at the interface or sub-interface
level, you must specify the count and interval (rate in seconds) for the threshold attacks you want to detect.
The sensor sends an alert when the traffic exceeds the customized thresholds for an enabled (sought after)
attack. You can also enable a notification for an attack if it warrants special attention.

Throttle
Alert throttling limits the number of duplicate alerts that are sent to the Manager from a sensor. Throttling is
very effective against flooding attacks where source IP addresses are spoofed generating a high number of
alerts.

Trojan Horse
A computer program that has a useful function, but which also contains additional hidden, typically malicious
functions.

Unassigned
This category is for attacks that fall outside the scope of the known subcategories in the IntruShield
environment. For example, if an attacker comes along a Van Eck device and starts conducting Tempest
attacks, “unassigned” would be the description.

Unauthorized IP
Any traffic activities suggesting existence of IP addresses that are not known to be authorized for the
protected network.

VIPS
See Virtual IPS.

Virtual IPS
An IntruShield feature that enables you to logically segment a sensor into a large number of virtual sensors,
each of which can be customized with its own security policy. Virtual IPS (VIPS) are represented in the
IntruShield Manager as interfaces and sub-interfaces.

Virus
A program, typically malicious, that spreads through the exploitation of system implementation or design
flaws. Virii can typically only be activated by an authorized user, that is, someone opening an email.

VLAN
Virtual Local Area Network. A logical grouping of two or more nodes which are not necessarily on the same
physical network segment, but which share the same network number. This is often associated with
switched Ethernet networks.

Volume DoS
Large volume of traffic, which could be perfectly valid from the perspective of application content, that can
overwhelm processing element along the path to the target including switches, routers, firewalls, target
servers etc.; this will cause a DoS effect on other legitimate traffic.

106
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

Vulnerability
Any characteristic of a computer system that will allow someone to keep it from operating correctly, or that
will let unauthorized users take control of the system.

Worm
A Worm is a program that propagates itself over a network, reproducing itself as it goes.

Write Exposure
With a successful attack, this suggests that a breach of integrity and/or authenticity of data has occurred.
Examples include creation/removal of files and modification of files for system configuration or user
passwords. With write exposures, there is often more severe indirect impact, e.g. breach of access control
by adding an illegal user account records.

107
Index

A dongles modes of Sensor

acknowledged alerts, 83 fail-closed, 42 deployment, 15
admin domains SPAN or Hub mode, 46 pre-deployment
considerations, 33
child domains, 57 optical bypass switch, about, 42
SPAN/hub operating mode, 17,
overview, 56 child domains 45
parent domains, 57 inheritance from parent, 58 tap mode, 43
Root Admin Domain, 56 overview, 57 detection
Root Admin Domain node, 56 user roles, 81 methods IntruShield uses, 8
administrative domains CIDR blocks methods of, 5
See admin domains for use with sub-interfaces, 62 dongles
advanced users components fail-closed, 42
deploying IntruShield, 96 of the IntruShield IPS, 10 DoS
Alert Filter editor, 71 Configuration Reports DoS modes
Alert Viewer overview, 90 about, 73
overview, 13, 85 Configuration tool learning mode, 73
alerts creating users, 80 threshold mode, 73
acknowledged, 83 overview, 13 DoS detection
Alert Viewer tool, 13, 85 Resource Tree, 51 overview, 5
details of an alert, 88 configuring drilling down
drilling down, 88 overview of System details of an alert, 88
Incident Generator tool, 89 Configuration tool, 13
lifecycle of, 83 policies, 66 E
overview, 83 System Configuration tool, 13 event forwarding, 13
anomaly detection users, 80 exporting
overview, 5 contacting policies, 68
asymmetric traffic technical support, vi external tap mode
monitoring with interface creating shifting to in-line mode from, 45
groups, 48 users, 80
F
attack signatures
D fail-closed functionality
scheduling updates of, 15
database about, 42
attacks
how users are stored, 80 cabling
detecting, 5
using with Manager, 13 dongles, 42
detecting with IntruShield, 8
deployment dongles, about, 42
overview, 3
about, in-line mode, 16 fail-open functionality
preventing, 16, 40
deploying the I-2600, external about, 42
types of, 4 tap mode, 44 cabling
authorization deploying the I-2600, internal tap optical bypass switch, 42
role-based authorization, 80 mode, 44
fail-open vs. fail-closed, 42
deploying the I-4000, external
B tap mode, 45 failover protection
beginners for advanced users, 96 about, 41
deploying IntruShield, 94 for beginners, 94 Fast Ethernet
for intermediate users, 95 fail-closed
C
in-line mode, 40 cabling, about, 42
cabling
ports on the I-1200 sensor, 11

108
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

full duplex connection shifting to in-line mode from, 45 monitoring sub-interfaces

overview, 18 Internet Explorer assigning policies to, 62
full-duplex version required by the MySQL database
about, monitoring in, 39 Manager, 12 using with Manager, 13
IntruShield
G roles, 80 N
generating reports system components, 10 Network Console
Reporting tool, 13 IntruShield 1200 sensor overview, 12
Gigabit Ethernet See I-1200 sensor nodes
fail-open IntruShield Manager of Resource Tree, 58
cabling, 42 See Manager O
H IntruShield Sensors Operator role
half-duplex See Sensors description, 82
about, monitoring in, 39 IntruShield Update Server optical bypass switch
hardware requirements See Update Server about, 42
Manager server, 12 intrusion Oracle database
hub operating mode overview, 3 using with Manager, 13
deploying, I-1200, 46 intrusion detection overview
overview, 45 overview, 3 admin domains, 56
Intrusion Detection System alerts, 83
I See IPS anomaly detection, 5
I-1200 sensor Intrusion Prevention System attack, 3
deploying in SPAN/hub operating See IPS
mode, 46 child domains, 57
IPS components of IntruShield, 10
device specifics, 11
overview, 6 detection methods, 5
I-4000 sensor
deploying in in-line mode, 16 L DoS detection, 5
IDS Reports learning mode full duplex connection, 18
overview, 90 about, 73 IDS, 6
importing inheritance, 58
M in-line mode deployment, 16, 40
policies, 68
management port IntruShield detection
Incident Generator
communicating with the methods, 8
overview, 89 Manager, 12 intrusion, 3
incidents Manager intrusion detection, 3
overview, 89 Alert Viewer, 13, 85 IPS, 6
inheritance browser requirements, 12 Manager, 11
overview, 58 components of, 11 to 12 parent domains, 57
roles, 59 database, 13 policies, 60
in-line mode Incident Generator, 89 policy inheritance, 58
deploying Sensors in, 40 Network Console, 12 resources, 51
overview, 16 overview, 11 roles, 79
shifting to, from tap mode, 45 Report Generator, 90 Root Admin Domain, 56
interface groups Reporting tool, 13 security policies, 60
about, 48 software description, 12 Sensor deployment, 15
interfaces System Configuration tool, 13 Sensor responsibilities, 10
creating policies to Manager server
monitor, 61 to 62 Sensors, 10
hardware description, 12 signature updates, 14
Interfaces node, about, 54
Manager software signature-based detection, 5
overview, 61
updating, 15 SPAN port, 17
Interfaces node
monitoring SPAN/hub operating mode
about, 54
full-duplex, 39 deployment, 17, 45
intermediate users
half-duplex, 39 tap mode deployment, 43
deploying IntruShield, 95
monitoring interfaces tap mode deployment,
internal tap mode external, 44 to 45
assigning policies to, 61
deploying the I-2600 in, 44

109
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

tap mode deployment, description, 71 SPAN port

internal, 44 roles overview, 17
taps, 18 Operator, 82 SPAN/hub operating mode
Update Server, 14 overview, 79 deploying the I-1200 in, 46
P relationship between parent and dongles, use of, 46
child domains, 59, 81 overview, 17, 45
parent domains
Restricted User, 82 sub-interfaces
assigning roles to users, 81
role-based authorization, 80 assigning policies to, 61
inheritance, 58
Security Expert, 82 creating policies to monitor, 61
overview, 57
Super User, 81 defining, 62
Policies
System Administrator, 81 overview, 62
importing and exporting, 68
types of, 81 Sub-interfaces node, about, 54
policies
Root Admin Domain Super User
configuring, 66
overview of, 56 description, 81
overview, 60
Root Admin Domain node System Administrator role
Policies node, about, 66
about, 56 description, 81
policy creation, 67
policy inheritance, 69 S System Configuration tool
Policies node Scheduled Reports overview, 13
about, 66 overview, 90 System Health Viewer
policy inheritance scheduling description, 12
order of inheritance, 69 signature updates, 15 T
overview, 58, 69 Security Expert role tap mode
port clustering description, 82 external, deploying the
about, 48 security policies I-2600, 44
ports overview, 60 external, deploying the
available on the I-1200, 11 Sensor deployment I-4000, 45
monitoring, full-duplex, 39 deploying redundantly, 41 internal, deploying the
I-2600, 44
monitoring, half-duplex, 39 external tap mode, 44 to 45
overview, 43
privileges in-line mode, 16, 40
shifting from tap mode to in-line
See roles internal tap mode, 44 mode, 45
pre-deployment taps
R considerations, 33
Recommended for blocking overview, 18
redundant deployment for
description, 71 failover protection, 41 technical support
redundant deployment SPAN/hub operating mode, 17, contacting, vi
about, 41 45 threshold mode
Report Generator tap mode, 43 about, 73
overview, 90 Sensors
U
Reporting tool communicating with the
Manager, 12 unacknowledged alerts, 83
overview, 13 Update Server
deploying in SPAN/hub operating
reports mode, 17, 45 overview, 14
Reporting tool, 13 deploying in tap mode, 43 updates
Resource Tree deploying, in external tap about the Update Server, 14
Interfaces node, 54 mode, 44 to 45 scheduling, 15
nodes, 58 deploying, in internal tap user privileges
overview of, 51 mode, 44
See roles
Policies node, 66 modes of deployment, 15
user roles
Root Admin Domain node, 56 overview, 10
description of, 81
Sub-interfaces node, 54 responsibilities of, 10
users
resources signature updates
creating, 80
overview, 51 overview, 14
managing in IntruShield, 79
Restricted User role scheduling, 15
privileges of, 79
description, 82 signature-based detection
RFB overview, 5

110
 ® ®
McAfee IntruShield IPS System 3.1
Getting Started Guide

V
viewing
alerts, 13, 85
configuration information, 13
system health, 12
unacknowledged alerts, 12
VIPS
description, 61
Virtual IPS
description, 61
VLAN IDs
for use with sub-interfaces, 62

111